Operating model
Operations and ownership
The customer, platform and product responsibilities needed to keep an Orbit deployment supported, controlled and useful after go-live.
Responsibility model
Orbit is operated inside the customer’s Microsoft and service-management environment. The support agreement defines the exact split, but the baseline responsibility model keeps tenant and business decisions with the organisation that controls them.
| Role | Typical ownership |
|---|---|
| Customer service owner | Service scope, catalogue, priority model, metrics and continual improvement |
| Customer M365 administrator | SharePoint, Entra, permissions, retention and Microsoft service health |
| Customer Power Platform owner | Flows, environments, DLP, connections, capacity and licensing |
| Customer security/privacy owner | Risk acceptance, access review, incident response and compliance evidence |
| RME Solutions Technology | Orbit product defects, source updates, documentation and agreed support scope |
Recommended service rhythm
An Orbit deployment benefits from a small, explicit operating rhythm rather than ad hoc maintenance.
- Daily or event-driven review of failed flows, delivery errors and priority incidents.
- Regular queue, SLA, knowledge and service-catalogue health review.
- Scheduled access, app-consent, service-account and connection-owner review.
- Periodic capacity, list-index, retention, backup and recovery validation.
- Controlled product update assessment with regression evidence and rollback plan.
Support boundary
Customer first-line support should establish the user, record, time, tenant condition and reproducible symptoms. Microsoft 365, Entra, SharePoint, Power Platform, hosting and network faults remain with their respective service owners. Reproducible Orbit product defects and agreed implementation support are escalated to RME Solutions Technology under the support agreement.
Change and release control
Product updates should be assessed against customer extensions, enabled modules, permissions and operating controls before promotion. Build the sterilised baseline and customer overlay into a traceable release candidate, validate it in staging, then promote the approved artefact rather than rebuilding an unverified variant for production.
- Record source revision, product version, overlay revision and build checksums.
- Run functional, authorization, bundle-boundary and regression checks.
- Document customer-specific impact, approval, deployment and rollback.
- Update the as-built record and support knowledge after release.