> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alfiz.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Federating Applications for Cross-App Authorization
> Federation moves the org root to Alfiz Cloud, unlocking cross-application role composition, a shared catalog registry, and provisioned integrations.
Federation is the step for organizations with more than one application, or for anyone who needs provisioned integrations with third-party systems. It moves the org root from your Application to Alfiz Cloud, making organizational-domain data centrally authoritative and shared across every member application: groups, roles, the reporting hierarchy, global grants. Instance-scoped grants, ancestry resolution, and runtime checks stay strictly local, in every application, always.
## What federation means
When you federate, your Application connects to Alfiz Cloud as its org-root authority. That relationship has a precise shape:
* Your Application **publishes its catalog** to the Alfiz Cloud registry, where it becomes a versioned, namespaced contract.
* Your Application **syncs organizational data down** (groups, roles, global grants, the reporting hierarchy) and evaluates it locally exactly as it did when standalone.
* Your Application **keeps instance-scoped grants, ancestry resolution, and runtime checks strictly local**. Alfiz Cloud never receives resource-shaped data, never evaluates scoped checks, and never needs to.
Your `alfiz` client continues to attach to your local `Application`. Nothing about client construction or check call sites changes when you federate. The Application absorbs the upstream relationship and surfaces it through the same provider contract the Client has always used.
## One authoritative writer per data domain
Federation does not create two writers. Alfiz Cloud becomes the org root and the authoritative home for organizational-domain data. Each Application syncs that data down and evaluates it locally, exactly as it did when standalone, and rejects local org-domain writes. There is no reconciliation problem and no conflict resolution, because there is only one writer for any given piece of data.
Instance-scoped grants such as `docs.doc:123` and `billing.invoice:456` go the other way: they live in the owning Application and never leave it. Alfiz Cloud cannot evaluate scoped checks because it cannot see your application's resource tables. That is the design guarantee that keeps enforcement local and keeps the check path off Alfiz Cloud entirely.
## What federation unlocks
Define a role like "Project Lead" that grants both `docs.files.*` and `zoom.host` in a single assignment. A standalone Application can already do this: declare the foreign slice as an [import](/catalog/imports) and both patterns go in one role. What federation adds is the **registry** behind it: a published, versioned source for that foreign vocabulary, ownership enforcement so no application defines another's keys, and drift reports when a role still references a tombstoned key.
Each application's namespace is published as a versioned contract. The registry enforces namespace ownership (no application can define another's keys), tracks additions and tombstones, and makes published permission trees consumable across your organization.
An org-wide approvals inbox that spans all federated applications. Approvers see and decide requests from every member application in one place, with decisions still written back through each application's own enforcement.
For external systems that will never call `can()`, such as Zoom and Slack, a provision-and-reconcile integration continuously converges that system's actual state toward what your grant store says, with drift detection when state changes outside Alfiz.
## Provision-and-reconcile
For third-party systems that have no ability to call `can()` at runtime, Alfiz Cloud operates a **reconciler** on your behalf:
1. An integration adapter publishes the external system's contract as a versioned namespace catalog, for example `zoom.*` for Zoom's API.
2. The reconciler continuously converges the external system's actual state (seat assignments, host rights, room access) toward what your grant store says.
3. **Drift**, meaning state changed directly in the external system's own admin panel, is detected and reported. You decide whether to accept or revert it.
An approved access request targeting a provisioned role (for example, `zoom.host`) writes the same grant row a direct admin action would. The reconciler enacts it in the external system on its next run.
Provision-and-reconcile and gate-at-runtime have different enforcement guarantees. Runtime checks are enforced within the cache staleness bound: 30 seconds for subject closures and 60 for object chains by default, or one revalidation window with the event log on. Provisioned permissions are enforced at reconcile cadence with drift detection. State both guarantees explicitly to your users.
When an integration publishes a new contract version, the adapter tombstones the old version. The registry produces a drift report: "Role X references 3 permissions no longer published by any application." Old grant rows are not silently rewritten. You review and migrate them.
## Promoting from linked to federated
If your Application is already linked to Alfiz Cloud, promotion to federation is the typical path, because the connection is already established and promotion adds only the authority transfer. The [promotion runbook](/cloud/promotion) walks the full sequence, including merges and demotion.
During promotion, your Application's organizational-domain data (groups, roles, global grants, the reporting hierarchy) is imported into Alfiz Cloud and validated before the transfer completes. Authority transfers **atomically**: after the transfer completes, your Application syncs that data back down and rejects local org-domain writes.
Pending access requests with management-layer approval stages survive promotion untouched. Stages reference "2 layers up in the reporting hierarchy," not resolved approver identities, so they resolve correctly against the promoted hierarchy.
If you are federating a second application that also carries local org-domain data, Alfiz Cloud surfaces any conflicts for human resolution before the merge completes. Positive access data (groups, role definitions, global grants) unions safely, because union-only inheritance means unioning only widens. Reporting hierarchies do not auto-merge, because a user cannot have two managers; conflicting trees are surfaced explicitly.
## Alfiz Cloud is not a dependency of your request path
Federation moves the org root. It does not move enforcement, and it does not put Alfiz Cloud between your application and a check:
* Runtime checks run in-process in each Application against local data, with the same call sites, the same tuple, and the same latency as standalone.
* Alfiz Cloud cannot add latency to a check, throttle one, or fail in a way that stops one. A federation-wide outage leaves every member application still enforcing.
* Check volume is not a billing dimension and will not become one.
* Hard spending caps are configurable per dimension; crossing one degrades hosted polish (relay cadence, retention ingest, reconciler frequency) and never any locally-running capability.
## Pricing
Federation pricing reflects the central infrastructure and cross-application vantage it genuinely requires.
**From \$900 / month.** Includes the org root, catalog registry, cross-namespace role composition, cross-application request aggregation, and audit aggregation.
**\$150 / application / month** for each federated member application (beyond the first, which is included in the base).
**\$90 / connector / month** for each provision-and-reconcile integration. Billed per operating reconciler, not per seat or per action.
**\$20 / seat / month**, the same as the linked tier. Admin seats carry over; you do not pay again for seats you already have.
Annual billing takes two months off hosted seats and federation.
An organization that needs a provisioned third-party integration (Zoom, Slack) but has only one application still federates, at the minimum topology of one member application. The Application retains its zero-dependency promise for everything it owns.
## Who federation is right for
Federation is the right step when:
* **You have two or more applications** and want a shared org structure (groups, roles, reporting hierarchy) without maintaining it separately in each.
* **You need cross-namespace role composition**, a role that bundles permissions from more than one application.
* **You need provisioned third-party integrations**, such as Zoom seats, Slack channel access, or any system that does not call `can()` itself.
* **You want org-wide request aggregation**, a single approvals inbox spanning all member applications.
Not ready to federate? The full feature set is available standalone, free, with no external dependency.
Linking is the typical first step. It adds the hosted dashboard and establishes the Alfiz Cloud connection that promotion to federation builds on.