Technical evaluation
Architecture and technical viability
The reference architecture, identity and data flows, integration boundary, deployment shape and questions a technical evaluator should resolve before committing.
Reference model
Orbit is delivered as a static React web application. In the standard live deployment, the static host serves application assets but does not act as the customer’s service-data store. The signed-in browser uses Microsoft Entra ID and tenant-approved Microsoft APIs to work with data held in SharePoint Online.
A per-tenant overlay supplies branding, service catalogue, forms, content and non-secret configuration. That keeps the reusable product source independent of a customer’s identity, URLs and business literals.
- React, TypeScript and Vite produce the static application bundle.
- For customer Orbit SPA deployments, Cloudflare Pages is the documented global edge-hosting pattern; another approved static host can be selected during solution design.
- MSAL handles Microsoft Entra sign-in and delegated token acquisition.
- Microsoft Graph and SharePoint REST provide the tenant data path.
- SharePoint Lists are the standard system of record for service data.
- Power Automate is an optional tenant-managed automation layer.
Components and responsibility boundary
The reference model deliberately separates presentation, Microsoft tenant services and any optional server-side enforcement. This matters when reviewing hosting, data residency, audit scope and operational ownership.
| Component | Primary role | Default boundary |
|---|---|---|
| Static host | Serves versioned Orbit assets | No tenant service records stored by Orbit |
| Cloudflare edge services | Static delivery, TLS and optional perimeter controls | Deployment option; configured and operated per customer |
| Microsoft Entra ID | Authentication, consent and Conditional Access | Customer tenant |
| Graph + SharePoint REST | Delegated API access | Acts under the signed-in user |
| SharePoint Online | Lists, permissions, records and attachments | Customer tenant |
| Power Automate | Selected email, approval and notification workflows | Optional; customer Power Platform environment |
| Authenticated control service | Strict write authorization or notification delivery | Optional deployment component when the risk model requires it |
Edge hosting and optional Zero Trust controls
Cloudflare Pages is the documented reference pattern for serving the Orbit static application globally. This public product site uses a Cloudflare Worker, while customer Orbit deployments remain static-host designs selected and approved for that environment.
Cloudflare Access, WAF, rate limiting and related Zero Trust services are deployment-layer controls. When selected, the deployment owner configures, tests, monitors and evidences them independently of the Orbit SPA and the customer’s Microsoft Entra sign-in flow.
- Use the customer’s approved custom domain, TLS and DNS ownership model.
- Treat an Access pre-authentication gate as a separate identity integration with its own confidential-client registration.
- Validate Entra redirect URIs, sign-in behaviour and support recovery paths through every edge policy.
- Define ownership for WAF rules, rate limits, logs, alerts, retention and incident response.
Identity and authorization
Orbit uses delegated access for the interactive application: API calls are made for the signed-in user. The Microsoft tenant’s consent settings, SharePoint permissions, site membership, item-level access and Conditional Access policies remain authoritative.
Role-aware page guards and client-side checks improve the experience, but they are not a security boundary. Sensitive read and write paths must be enforced through SharePoint permissions or an authenticated server-side control designed for that operation.
Data model and integration
Core service records cover tickets, comments, service catalogue entries, approvals, assets, user-lifecycle work, knowledge and operational telemetry. The canonical schema and provisioning artefacts are versioned in the sterilised source.
The implementation uses indexed SharePoint queries and deliberately supports both Microsoft Graph and SharePoint REST because the APIs have different capability and query characteristics. Optional integrations are selected per deployment rather than assumed for every customer.
- Review expected list volumes, indexing and retention before production.
- Map each enabled module to its required Graph and SharePoint permissions.
- Define attachment scanning, DLP and records-management ownership.
- Treat inbound email and background publication as separately consented app-only workloads.
Viability questions for a deployment review
A technical suitability review should answer the questions below with tenant-specific evidence, not generic product assumptions.
- Does SharePoint Online meet the required record volumes, query patterns, retention and residency position?
- Can the organisation approve the delegated and any app-only permissions required by selected modules?
- Which writes require server-side enforcement beyond SharePoint ACLs?
- Are guest access, cross-tenant use or Conditional Access policies in scope?
- Which flows need Power Automate, who owns them and what connector classification applies?
- Who owns monitoring, backup, recovery, access review, release approval and incident response?