Designing an Operations Assurance Platform for a Growing Managed Services Organization

Growing technology organizations often reach a point where the problem is no longer whether individual engineers can complete the work. The problem becomes whether the organization can consistently determine what work must be done, who owns it, when it is due, whether it was completed, and whether there is evidence that the obligation was actually fulfilled.

I encountered this problem in a growing managed-services environment. As the customer base expanded, engineers increasingly had to work across multiple customer ticketing systems, documentation platforms, identity providers, VPNs, maintenance schedules, project requests, and internal workflows. Client onboarding created additional uncertainty because new customers introduced new applications, access models, service commitments, and recurring responsibilities.

There was no single legacy system to replace. The larger issue was that important operational responsibilities were distributed across spreadsheets, email, calendars, customer systems, documentation, and tribal knowledge. That made it difficult to answer seemingly simple questions:

• What services are we responsible for delivering to this customer?
• What recurring work follows from those services?
• Who is responsible for each task?
• Does the engineer have the access and context required to perform the work?
• Was the work completed?
• Can we demonstrate that it was completed?

I saw those issues as symptoms of a broader systems problem rather than a collection of isolated workflow problems. I proposed and began building an operations assurance platform intended to connect service obligations, onboarding, project governance, patch operations, access verification, and engineering work into a common operational model.

The Architectural Goal: Bring the Work to the Engineer

One of the most important design principles became:

The objective was not to replace every authoritative system. Customer ticketing systems could remain ticketing systems. Documentation platforms could remain documentation platforms. Calendars could remain calendars. The architecture instead normalizes operational responsibility into a common work queue so that engineers have one place to see the work assigned to them.

Client Onboarding -----------\
Service Obligations ----------\
Project Governance ------------\
Patch Operations ---------------> Normalized Work Queue -> Engineer
Access Verification ------------/
Maintenance Activities --------/
Other Operational Work -------/

This distinction is important. Centralization does not always mean data consolidation or platform replacement. In this design, upstream systems can remain authoritative for their own domain while a normalized work model presents actionable responsibility to the engineer.

Requirements and Constraints

The platform was designed for an organization supporting more than thirty customers and roughly eighty to ninety employees distributed across multiple departments and technical teams. The immediate requirement was not hyperscale transaction processing. The requirement was to reduce operational ambiguity while creating a platform that could support continued business growth without forcing the organization to rely increasingly on memory, spreadsheets, and manual coordination.

The major requirements included:

• Centralize engineer work without replacing every upstream system.
• Translate service commitments into recurring operational tasks.
• Track ownership and completion status.
• Capture evidence for work where evidence is required.
• Standardize new-client onboarding and access verification.
• Give managers visibility into onboarding, project, and service-delivery status.
• Support human approval where commercial or governance judgment is required.
• Use existing Microsoft 365 and Azure investments where practical.
• Avoid unnecessary server infrastructure and its associated security and maintenance burden.
• Keep incremental cloud infrastructure cost extremely low.

Cost was an explicit architectural consideration. The organization already had Microsoft 365 and Azure capabilities available, so I intentionally favored existing SaaS/PaaS services and consumption-based Azure components over a conventional always-on application stack.

The initial design goal was to keep incremental Azure infrastructure cost below approximately $5 per month. During the platform's early operational period, Azure consumption for the custom cloud components has remained below approximately $1 per month, excluding licenses the organization already owned.

Why I Did Not Start with a Traditional Application and Database

A conventional architecture could have used a custom web application, an API tier, background workers, a relational database, and a dedicated application runtime. That architecture would provide greater control over relational modeling, transactions, evidence storage, complex querying, and application behavior.

Custom Web Application
        |
        v
Application/API Tier
        |
        v
Relational Database
        |
        v
Background Workers / Schedulers

It would also introduce additional cost and operational responsibility. Someone would have to deploy, secure, patch, monitor, back up, recover, and maintain those components. For the actual workload and maturity of the platform, that complexity was difficult to justify.

The current architecture therefore makes extensive use of technologies already available in the environment:

• SharePoint Lists for lightweight operational data and configuration.
• Power Apps for manager and engineer workflow interfaces.
• Power Automate for business workflows, approvals, recurrence evaluation, and system integration where appropriate.
• Azure Functions for custom application logic, provisioning, and integrations that are a poor fit for low-code workflows.
• Azure Storage Queues where asynchronous processing is appropriate.
• Microsoft Entra ID for identity and application access control.
• Azure Key Vault for secrets required by external integrations.
• Managed Identities for Azure workload authentication where supported.
• Azure App Configuration for non-secret application configuration.
• Azure Monitor / Log Analytics for monitoring custom Azure components.
• Azure DevOps for source control and deployment of the Azure Function code.

SharePoint is not a relational database, Power Automate is not a general-purpose distributed workflow engine, and Power Apps does not provide the flexibility of a fully custom application. Those limitations are real. The architectural question was whether those limitations prevented the system from meeting the current business requirements. At the current scale, they did not.

Choosing a more sophisticated platform simply because it would look more architecturally impressive would have increased cost and operational burden without delivering proportional value.

Service Assurance: From Commitment to Evidence

One of the central problems was recurring service delivery. Selling a service does not guarantee that the work required to deliver that service will consistently occur.

The platform models the relationship conceptually as:

Service
   |
   v
Customer Obligation
   |
   v
Recurrence
   |
   v
Operational Work
   |
   v
Assigned Engineer
   |
   v
Completion
   |
   v
Evidence

Managers select the services applicable to a customer during onboarding. Those selections and their recurrence requirements are written into an operational service-obligation model. Scheduled Power Automate workflows evaluate those obligations and generate work at the appropriate interval, such as weekly or monthly.

The resulting work is normalized into the same central work queue used by other operational workflows.

Where evidence is required, the engineer supplies a URL pointing to an existing artifact, typically a ticket or change record. The goal is to preserve traceability between the obligation, the resulting task, and evidence of execution.

This changes the question from:

"Did someone mark the task complete?"

to:

"Can the organization demonstrate that the service it committed to providing was actually delivered?"

The current evidence model intentionally contains some trust. The platform does not yet validate whether every submitted URL represents sufficient evidence. A user could technically submit an incorrect or meaningless link. At the current maturity of the system, manual review remains the control for that scenario.

That is a known limitation rather than something I would hide. A future version could introduce direct integration with authoritative ticketing systems, evidence validation, richer artifact storage, mandatory approval for selected services, or stronger reconciliation between required obligations and completed work.

Client Onboarding as Structured Operational State

Client onboarding previously relied heavily on spreadsheets and distributed documentation. The challenge was not merely knowing that an engineer needed access. The engineer also needed to know which application to test, where to find it, what role they should receive, when the customer was ready for access testing, and how to connect.

The onboarding workflow turns that process into structured state.

New Customer
     |
     +----------------------+
     |                      |
     v                      v
Service Selection      Application Inventory
     |                      |
     v                      v
Recurring Work         Access Requirements
                            |
                     +------+------+
                     |             |
                     v             v
               Role Defaults   Exceptions
                     \             /
                      \           /
                       v         v
                       Access Matrix
                            |
                            v
                     Manager Readiness
                            |
                            v
                     Engineer Testing
                            |
                            v
                    Completion Visibility

A manager completes a custom onboarding form that captures generalized customer information, support-team assignments, relevant platform URLs, identity providers, ticketing and documentation systems, and additional applications requiring access.

The form also builds an access matrix. Role recommendations can be prepopulated for common infrastructure and identity platforms based on operational responsibilities, while the manager retains the ability to override those defaults or select individual employees.

This is an important design choice: automation recommends; management remains accountable for access decisions.

After submission, access-verification work is staged for managers. When the customer indicates that access is ready to test, managers release the appropriate tasks to employees. Engineers then see those tasks in their personal work queue, while managers can track completion in a separate onboarding view.

Connection context can travel with the task. Instead of telling an engineer to "test access" and forcing that engineer to search elsewhere for the VPN process or application URL, the assignment can include the relevant operational notes.

Reducing that information-discovery cost is a small architectural decision with large operational consequences.

Provisioning and External Integrations

Onboarding also triggers supporting provisioning. Depending on the selected configuration, automation can create internal resources required for customer operations and create records in third-party systems used for time tracking or other operational processes.

Where supported, Azure workloads authenticate using managed identity. When an external service requires an API credential, the secret is stored in Azure Key Vault and the Azure workload identity is granted the minimum access required to retrieve it.

Azure Function
      |
      | Managed Identity
      v
Azure Key Vault
      |
      | Authorized secret retrieval
      v
External API Credential

The onboarding process is not currently a distributed transaction. If one downstream provisioning action succeeds and another external API operation fails, the system does not attempt to roll back every previous action.

That is a conscious maturity tradeoff. At the current workload and business criticality, the engineering effort required to implement transactional compensation across multiple SaaS and Microsoft 365 systems would exceed the operational value.

Failures are surfaced through monitoring and can be corrected manually. If the platform becomes responsible for substantially higher-volume or business-critical provisioning, that failure model should be revisited with retry, idempotency, reconciliation, and compensating-action strategies.

Project Governance with AI-Assisted Analysis

The platform also supports project requests. Customers sometimes request work where the first question is not technical implementation but whether the work is included in an existing service agreement or should become separately funded project work.

Project managers can submit the request along with contextual information such as ticket content, meeting notes, or supporting documents. AI reviews the request together with the relevant agreement context and produces comments or recommendations for management.

Customer Request
       |
       v
Project Submission
       |
       +---- Ticket / Notes / Documents
       |
       v
AI-Assisted Review
       |
       v
Comments / Recommendation
       |
       v
Human Management Review
       |
       +---- Included Work ----> Assignment
       |
       +---- Project Work -----> Commercial Process

The AI is intentionally advisory. It does not receive authority to make the commercial decision.

Management reviews the AI output and decides whether the request should proceed under an existing commitment or move through a paid-project process. If approved, the assignment is again normalized into the engineer's work queue.

Patch Operations as a Coordination Problem

Patch management is another area where execution is only one part of the problem. Successful maintenance requires coordination among scheduling, staffing, access, known-issue research, change management, readiness checks, execution, on-call awareness, and reporting.

The platform uses maintenance scheduling information to create operational work and identify potential staffing conflicts. If an engineer assigned to a patch window is scheduled to be unavailable, management can be notified so responsibility can be reassigned before the maintenance window.

Pre-patching checklist work can be generated for assigned engineers. Known Windows Update issues and vendor security advisory information are centralized so every engineer does not independently repeat the same research.

The goal is not simply to automate patch installation. The goal is to reduce operational uncertainty surrounding the entire patch process.

Identity, Authorization, and Data Minimization

Microsoft Entra ID is the human identity provider for the applications, and access is controlled through group assignments. Operational interfaces are designed around role and responsibility rather than exposing unrestricted access to all employees.

The employee-facing work application filters the normalized queue to show work assigned to the authenticated user. Managers and administrators have broader access appropriate to their responsibilities.

The system deliberately avoids becoming a credential repository. Work items contain operational context and references, but not customer passwords, secrets, private keys, MFA seeds, tokens, or other credentials.

For workload authentication, managed identities are preferred where possible. Secrets that cannot be eliminated are stored in Azure Key Vault instead of source code or ordinary application configuration.

This serverless/SaaS-heavy model also reduces infrastructure that must be directly patched and maintained. It does not remove security responsibility, but it reduces unnecessary attack surface and operational ownership.

Observability: Technical Failures vs. Business Correctness

The current platform uses Azure monitoring and workflow failure notifications to identify many technical failures. Azure Function code is maintained in Azure DevOps and the onboarding application has separate development and production deployment paths for testing changes.

The next observability problem is more interesting: technical execution monitoring is not the same as business-level assurance.

A workflow can report that it ran successfully without proving that every expected work item exists.

For example, assume forty recurring obligations should generate tasks on a given day. A stronger assurance capability would independently reconcile expected work against actual work:

Expected Work:       40
Generated Work:      40
Missing:              0
Duplicates:           0
Generation Failures:  0

That type of reconciliation is a logical future improvement because it detects silent inconsistencies that normal execution monitoring may miss.

The architecture is young, and I consider this distinction important enough to document explicitly rather than present the system as more mature than it is.

Known Tradeoffs and Technical Debt

Several limitations are intentionally accepted in the current architecture:

• SharePoint Lists provide limited relational behavior compared with a dedicated database.
• Power Automate recurrence and workflow behavior is adequate for current volume but is not a substitute for a sophisticated orchestration platform.
• Evidence URLs are not currently programmatically validated.
• Some external provisioning operations do not automatically retry or compensate for partial failure.
• User-facing functionality is constrained by Power Apps capabilities.
• Integration with newer Microsoft Planner capabilities is currently limited.

These are not reasons to rewrite the platform immediately. They are conditions to monitor.

A major part of architecture is knowing the threshold at which today's pragmatic design becomes tomorrow's bottleneck.

How I Would Evolve the Architecture

If the organization substantially increases customer count, transaction volume, relational complexity, evidence requirements, reporting needs, or integration depth, I would consider introducing a more conventional application and data tier.

Potential future components could include:

• A relational database for stronger integrity and more complex relationships.
• A dedicated application/API layer.
• More durable asynchronous messaging for selected workflows.
• Formal retry, idempotency, poison-message, and reconciliation patterns.
• Stronger evidence storage and validation.
• Business-level assurance dashboards.
• More automated integration with authoritative ticketing and change-management systems.
• Containerized application services where the additional flexibility justifies the operational cost.

I would not make those changes merely to produce a more fashionable architecture. I would make them when measurable requirements justify the complexity.

What This Project Changed

The most important outcome is not a particular Azure service or Power App. The platform is creating an operational model the organization can grow into.

New clients can enter a standardized onboarding workflow instead of beginning as an ad hoc spreadsheet exercise. Service selections can become recurring work. Access readiness can become visible state. Managers can release verification tasks when customers are ready. Engineers can see assigned work in one place. Project requests can be reviewed and approved through a consistent governance workflow. Patch operations can account for readiness, staffing, and shared intelligence.

The broader goal is to reduce the probability that organizational growth outpaces the processes required to deliver services reliably.

That matters because technical scale is only one type of scale. A business may be able to add customers long before its operating model is able to support them consistently.

Lessons Learned

• Operational problems are often systems problems before they are technology problems. Automating individual tasks helps, but sometimes the real opportunity is creating a common model connecting them.
• Centralization does not require replacing every authoritative system. Normalize responsibility while letting specialized systems remain authoritative for their own data.
• Low-code, SaaS, and serverless technologies are architectural tools. Their value depends on whether their constraints align with the workload.
• Evidence changes task tracking into service assurance. Completion state alone may not demonstrate that a commitment was fulfilled.
• AI should support accountability, not replace it. Advisory analysis can be automated while business and governance decisions remain human-owned.
• Operational context should travel with the work. Assigning a task without the information required to execute it simply transfers the discovery burden to someone else.
• Cost is part of architecture. A system that solves the problem for almost no incremental infrastructure cost may be better than a technically elegant platform whose complexity is not yet justified.
• Monitoring execution is not the same as validating outcomes. Business-level reconciliation is a future control worth designing for.
• Architecture should evolve with requirements. The correct platform at thirty customers does not have to be the correct platform at three hundred.

Final Thoughts

The questions that ultimately drive this architecture are straightforward:

What are we responsible for?
        |
        v
What work follows from that responsibility?
        |
        v
Who owns the work?
        |
        v
What information do they need to execute it?
        |
        v
Was it completed?
        |
        v
Can we demonstrate that it was completed?
        |
        v
What happens when reality differs from expectation?

Those are not Azure questions. They are not Power Platform questions. They are not specific to managed services.

They are architecture questions.

The technology exists to support the operating model. The real engineering work is translating business responsibility into a system that can be executed, observed, governed, secured, and evolved.

Tags: Cloud Architecture, Azure, Microsoft 365, Power Platform, Power Automate, Power Apps, Azure Functions, Serverless, Service Assurance, Governance, Automation, Security Architecture, Platform Engineering

Published: August 26, 2026
Author: Robert H. Osborne