Implementation path
Deployment and readiness
The customer-owned prerequisites, delivery sequence, configuration boundary, assurance gates and handover artefacts for a controlled Orbit deployment.
Baseline prerequisites
The exact bill of materials is agreed during solution design. A standard live deployment starts with the following customer-owned services and decisions.
| Area | Baseline requirement | Owner |
|---|---|---|
| Microsoft tenant | Microsoft 365 licensing that includes SharePoint Online | Customer licensing administrator |
| Identity | Single-tenant Entra app registration, redirect URIs and consent review | Customer identity team |
| Data | Approved SharePoint site, provisioned lists, indexes and permission model | Customer M365/platform team |
| Hosting | Approved static web host and production domain; Cloudflare Pages is the documented reference pattern | Customer or agreed delivery party |
| Automation | Power Platform environment, connections and flow ownership if selected | Customer Power Platform team |
| Operations | Named service, security, release and support owners | Customer management |
Controlled delivery sequence
Orbit uses a sterilised product baseline with a reviewed per-instance overlay. That overlay contains non-secret customer configuration and brand material; deployment systems supply environment values and credentials.
- Confirm scope, modules, data classification and control requirements.
- Agree Microsoft licensing, identity permissions and Power Platform design.
- Provision the SharePoint schema, indexes, permissions and test data.
- Create the Entra application registration and record approved consent.
- Configure the customer overlay, catalogue, forms, brand and host allowlists.
- Build a release candidate and run automated source and bundle checks.
- Validate functional, authorization, accessibility, recovery and operational scenarios.
- Promote the same approved artefact through staging to production with evidence.
Configuration and secrets
Browser configuration is intentionally public to users of the deployed application. Tenant IDs, client IDs, SharePoint URLs and enabled feature settings are configuration—not secrets. Client secrets, certificates, deployment tokens and app-only credentials must stay in approved secret stores and must never be bundled into the static application.
Production and staging use explicitly separated hostnames, app redirect URIs, data paths and deployment controls. Any host that is not explicitly authorised should fail closed to a non-production behaviour.
Production readiness gates
A release is ready when the customer can demonstrate the agreed technical and operational controls in its own environment.
- Approved permission and admin-consent record for each application identity.
- Positive and negative ACL tests for representative roles and sensitive records.
- List-index, volume and attachment tests against realistic workloads.
- DLP, malware, retention, backup and recovery decisions with named owners.
- Flow ownership, connection references, failure handling and run-history access.
- Release manifest, checksums, change approval, rollback and support handover.
- Accessibility, browser, mobile and Conditional Access validation.
Handover artefacts
The handover pack should be sufficient for service management, security and future maintainers to operate the deployment without relying on undocumented knowledge.
- As-built architecture and data-flow record.
- Application registrations, permissions, owners and consent evidence.
- SharePoint schema, permissions, retention and recovery runbooks.
- Flow inventory, connection ownership and licensing validation.
- Release evidence, support model, escalation path and known limitations.