Window lifecycle

A bypass window is a record with a lifecycle. Status is written by the engine - you create windows and (when needed) deactivate them; everything else is automatic.

Statuses

StatusMeaningEnforcement effect
Scheduled Created with a future start time; waiting for the engine to activate it. None yet - automations enforce normally.
Active The window is live. Immediate submissions start here; scheduled windows arrive here at their start time. Listed objects are bypassed for the window's scope.
Retrying A transition hit an error and the engine is automatically retrying. Depends on the failed transition; the engine converges to the correct state.
Error Retries reached the configured ceiling; the window waits visibly for an admin. Surfaced on the dashboard and engine-health banner for attention.
Expired The end time passed and the engine closed the window. Enforcement restored. Terminal.
Deactivated An admin ended the window early. Enforcement restored. Terminal.

Terminal records are never reused or deleted - the next bypass event is a new window, and closed windows remain as audit history. Start and end times are preserved after activation and expiration as historical facts.

Timing rules

  • Immediate windows (no start time) are created directly in Active status and enforcement recomputes at submission.
  • Scheduled windows activate when their start time arrives, on the engine's next pass (cycles run every five minutes - a 1:23 pm start goes live by ~1:25 pm).
  • Indefinite windows (no end time) are allowed only if org policy permits. If a maximum duration is configured, the engine stamps an end time automatically at activation; if end dates are required with no default duration, indefinite requests are rejected at creation. See Org defaults.
  • Expiration occurs on the first engine pass after the end time.

Scope resolution while Active

Enforcement resolves through Salesforce's native settings hierarchy: organization → profile → user. A populated narrower scope masks broader scopes for the users it covers - a user-level window defines that user's bypass state entirely while active, and users with no narrower row inherit the org state.

Error recovery

  1. A failed transition moves the window to Retrying; the engine re-attempts on subsequent cycles.
  2. Each attempt increments the window's retry count (visible on the record).
  3. At the configured retry ceiling (default 3), the window rests in Error until an admin resolves the cause. It is prominently surfaced - an Error window is never silent.

Audit trail

Status changes are tracked with field history on the window record, the record page's history panel lists lifecycle events with actors, and the reason entered at creation persists forever. See Reporting & audit.