Governing automations

Each automation you govern gets one small ControlLayer check. The default is always enforce - an automation is only suppressed while an active window explicitly lists its object.

How the check works

ControlLayer maintains one enforcement setting per category - vControl__c (validation rules), fControl__c (flows), tControl__c (triggers). Each holds a semicolon-wrapped list of bypassed object API names (e.g. ;Account;Contact;), resolved through the org → profile → user hierarchy. Your check tests for the object's exact token. The wrapping semicolons make matching safe: ;Account; can never false-match Account_Plan__c. Matching is case-sensitive - use the exact API name.

Validation Rules

Wrap the rule's own logic in an AND() whose first clause is the ControlLayer check. The token is the object the rule lives on - it's the only per-rule variation.

AND(
    NOT(CONTAINS($Setup.vControl__c.Objects__c, ";Account;")),
    ISBLANK(Phone)   /* the rule's original logic, unchanged */
)

Footprint: one merge field and one function call (~73 compiled characters of the 3,900 limit).

Record-triggered Flows

Add the same clause to the flow's entry condition (formula). When a bypass is active the flow never starts - zero elements consumed.

AND(
    NOT(CONTAINS({!$Setup.fControl__c.Objects__c}, ";Lead;")),
    /* the flow's own entry logic */
)

Autolaunched & Screen Flows

Where entry-condition formulas aren't available, use the packaged invocable action "Is Automation Bypassed" (action category ControlLayer) followed by a Decision element at the top of the flow.

Input / output	Value
Input: Category	`Validation Rule`, `Flow`, or `Trigger`
Input: Object API Name	e.g. `Lead`
Output: Is Bypassed	Boolean - route to an early exit when true

Apex Triggers

One guard line at the top of the handler:

if (AutomationBypass.isObjectBypassed('Trigger', 'Account')) {
    return; // ControlLayer: governed automation exits before doing any work
}

isObjectBypassed(category, objectApiName) resolves the running user's hierarchy via the platform's cached settings access - no SOQL, safe at any trigger volume. An unknown category string throws an exception on purpose: a typo should fail loudly in your first test run, not silently enforce forever.

Behaviors worth knowing

Inside Apex tests, governed validation rules and flows do not block. Formula-based checks read a per-transaction snapshot that test isolation hides, and the platform skips the formula entirely - so your test suites are never blocked by governed rules. Apex-governed triggers remain enforced in tests. This is platform behavior, documented so it never surprises you.
Namespace: in managed-package installs, formula references are namespaced ($Setup.CL__vControl__c.CL__Objects__c) and the Apex class is CL.AutomationBypass.
Never edit the enforcement settings directly. They are recomputed from active windows and reconciled every cycle; manual edits are corrected automatically.
Adopt incrementally. Ungoverned automations are completely unaffected. Start with the rules that block data work most often.