Safety limits

Safety limits put a deliberate pause between an unexpected change and the system it could affect. They are not a health score and they do not make a bad change safe. They stop a planned write, name the condition that fired and give an administrator the evidence needed to fix, reset or release it.

Two controls share this work:

• Sync circuit breakers judge the proposed difference before an import or synchronization applies it.
• Provisioning caps count write operations over a time window and stop, throttle or alert when a configured ceiling is reached.

A rule is not a trip

A circuit-breaker rule defines what to watch and where: its thresholds, object kind, system scope, priority and action. A trip records one system breaching that rule during one run.

That distinction is load-bearing. A tenant-wide rule can protect every system, but a breach pauses only the system whose proposed change crossed the threshold. The same rule remains armed for the rest of the estate. Resetting one system's trip does not silently release another system.

The trip leads with the condition that actually fired — for example, “change 88.4% exceeded the 20% limit” — and carries the actual value for every other configured condition. It never presents a generic list of possible causes as though each were equally likely.

What a breaker can watch

A breaker judges one kind of change, or every kind when no narrower kind is selected:

Kind	The proposed difference it judges
Identities	People or workforce identities arriving from a source
Business objects	Governed context records such as departments or projects
Object memberships	Membership edges between those records
Accounts	Accounts in a connected target system
Entitlements	Groups, roles or comparable access objects
Grants	Assignments between an account and an entitlement

Each kind is measured against its own baseline. The platform does not blend a large stable account population with a small but completely replaced entitlement set and call the combined percentage safe.

Breakers can use percentage thresholds or absolute ceilings for creates, updates, deletions and total change. Per-attribute conditions can narrow the question further: a run that blanks department for hundreds of identities is different from one that changes hundreds of unrelated fields. Membership and grant edges have no attributes, so the editor does not offer field conditions that could never fire.

Which rule wins

One effective rule answers the safety question for a system and object kind. Resolution is first-match-wins, in this order:

1. A rule naming the object kind outranks an all-kinds rule.
2. Within that, a system-specific rule outranks the tenant-wide fallback.
3. Priority orders rules with the same specificity.
4. A stable business identifier breaks a remaining tie.

This makes two necessary shapes possible at the same time: a tenant-wide safety floor and an explicit exception for a system with legitimate high churn. The coverage view names which rule is effective and flags an exception that is looser than its fallback. “Covered” alone would hide the decision that matters.

Provisioning caps

A provisioning rule carries a list of independent caps. Each cap states:

• what it counts — every write, a class such as create or revoke, or one specific operation such as account disable or grant;
• over which window — so one rule can express both a short burst ceiling and a sustained daily ceiling;
• per what — the whole system, one identity, one account or one entitlement;
• whether it applies only to privileged operations.

Breaching several caps reports all of them. Reporting only the first would invite an administrator to raise the wrong ceiling and retry. A cap that cannot identify its configured subject is skipped rather than widened silently to the whole system.

First sync and intentional release

A connector's first baseline sync does not trip a change breaker: there is no prior connector state to protect, and a 100% net-new difference is expected. The exemption belongs to that connector's first run, not to the tenant's total record count.

For a later held run, release is deliberately reviewable:

1. Inspect the condition that fired and the stored proposed difference.
2. Correct the source, mapping or threshold when the change is wrong.
3. Reset and run again, or issue a one-shot release when the change is intended.
4. Record a non-empty reason for the release.

A one-shot release is consumed once. It is not the same as disabling the rule, and every other safety limit continues to apply. If an old trip has no stored preview, the portal says so instead of inventing one; the trip can still be released, but never without an audit reason.

Known boundaries

• A safety limit judges the difference the connector and mapping produced. It cannot prove that the source data itself is correct.
• An alert-only action reports a breach without pausing the connector. The rule's configured action therefore matters as much as its threshold.
• A first-sync exemption means initial population must be reviewed through the onboarding and preview controls rather than treated as breaker evidence.
• Disabling a rule is configuration, not a one-run exception. It removes that protection until somebody enables it again.

---

Further reading: Reconciliation · Imports and schedules · Failed Jobs Queue · Operating rhythm