Federation Engine
Federation Engine connects many independent ServiceCore tenants and companies under one orchestrator layer without merging their data. Each tenant keeps its own users, service catalogue, processes and SLAs and operates exactly as it would standalone, while a central hub gains consolidated visibility and group-wide governance across all of them. It is built for hub-and-spoke realities — a holding company and its subsidiaries, an MSP and its customer tenants, or a federation of regions and departments — where you need one place to oversee the whole estate but cannot collapse it into a single shared instance.
Built for the way federation engine should work
Federation Engine connects many independent ServiceCore tenants and companies under one orchestrator layer without merging their data. Each tenant keeps its own users, service catalogue, processes and SLAs and operates exactly as it would standalone, while a central hub gains consolidated visibility and group-wide governance across all of them. It is built for hub-and-spoke realities — a holding company and its subsidiaries, an MSP and its customer tenants, or a federation of regions and departments — where you need one place to oversee the whole estate but cannot collapse it into a single shared instance.
Inside ServiceCore the engine adds an orchestrator hub on top of the same shared data model every module already uses. The hub maintains a realm directory of all connected tenants — type, version, contract, owner team and health — and rolls up live operational data from each one. Tickets, requests and changes raised in any tenant can be surfaced in a single consolidated view, and an operator can jump from any row straight into the originating tenant. Because the data model is shared, an incident, problem or change record means the same thing in every realm, so roll-ups, cross-tenant comparisons and trend analysis line up without reconciliation work.
Sharing across tenant boundaries is deliberate, not automatic. Federated routing rules (by skill, location, customer or category) can hand a ticket from one tenant to another while preserving the source tenant's data-visibility rules; shared and private fields are governed by separate policy, the data scope is documented per record for KVKK/GDPR purposes, and the customer follows the whole chain under one tracking number. Policies and service-catalogue standards authored centrally — priority matrices, approval chains, SLA templates, confidentiality rules — are version-published down to federated tenants, where local teams keep their own catalogue extensions on top of a guaranteed common core.
Federation Engine sits in the Enterprise Service capability group and leans on the rest of the platform rather than duplicating it. It federates Identity & Access so SAML, OIDC and SCIM from a central provider apply across tenants; it feeds Reporting & Dashboards with cross-tenant roll-ups; it reuses Service Catalogue, SLA Management and the approval/change modules as the units it distributes and governs; and every federation action — policy publish, tenant handover, exception decision, ticket transfer — is written to an immutable audit trail for external audit and certification.
- Multi-tenant orchestration
- Cross-tenant sharing
- Tenant data isolation
- Federated authorization
- Consolidated oversight
- Group governance
What you can do with it
Hub-and-spoke orchestration
Connect independent tenants — subsidiary, customer, region or department — to one orchestrator hub that manages policy distribution, escalation routing and consolidated oversight while each tenant keeps its own data boundary.
Realm and tenant directory
List every federated tenant in a single directory with type, version, contract, owner team, user count, last sync time and health status, with one-click drill-down into any tenant.
Cross-tenant ticket transfer
Hand incidents, requests and changes from one tenant to another using federated routing rules, with shared and private fields governed by separate policy and the data scope documented per record.
Policy and catalogue federation
Author priority matrices, approval chains, SLA templates and service-catalogue core items centrally, version-publish them to tenants, and let local teams add their own extensions on a guaranteed common core.
Identity federation
Apply a central SAML, OIDC and SCIM provider across all tenants so users sign in once to the realms they are authorised for and role changes propagate from the centre.
Federated audit trail
Record every federation action — policy publish, tenant handover, exception decision, ticket transfer — in an immutable ledger that exports as an evidence chain for audit and certification.
Why teams adopt it
Group-wide visibility
See open incidents, SLA performance, mean time to resolve and satisfaction for every tenant on one console, with tenant benchmarking and cross-region cuts that need no manual reconciliation.
Independence preserved
Each company keeps its own users, processes, catalogue and SLAs and is never forced into a shared instance, so federation adds oversight without disrupting how local teams already work.
Consistent governance
A version-controlled common core of policy and standards reaches every tenant, while exceptions are logged with justification and expiry, keeping the group compliant without freezing local flexibility.
Faster onboarding
Adding a new subsidiary or customer tenant to the federation auto-syncs policies, catalogue and roles in minutes instead of rebuilding governance per instance.
Where it fits
Holding and subsidiaries
A parent company oversees several subsidiaries' service operations from one hub, distributing group policy and SLA templates while each subsidiary runs its own ITSM independently.
MSP managing customers
A managed service provider federates each customer as an isolated tenant, routing tickets across boundaries when needed while keeping every customer's data separated and the chain auditable.
Multi-region operations
A global organisation federates regional tenants with data residency labelled per realm, so cross-tenant flows respect regional boundaries and data only moves to the hub when policy allows.
Department federation
Independent business units run their own catalogues and approval chains as separate tenants, yet share a common incident and change model and roll up to one executive dashboard.
Common questions
No. Each tenant stays fully independent with its own users, service catalogue, processes and SLAs. The orchestrator hub adds consolidated visibility and governance on top, and data crosses a tenant boundary only when a federation rule or policy explicitly allows it — every such transfer is documented per record and written to the audit trail.
Part of these solutions
See Federation Engine in action.
Book a demo and we'll show federation engine working alongside the rest of the platform — on one shared data model.