Skip to content

Approvals, risk and emergencies

Edition: Community and Enterprise

How many approvals a fix needs depends on three things: the environment's policy, the risk of this particular fix, and whether it was declared an emergency.

flowchart LR
    P["Environment policy<br/>roles, counts, order"] --> A["Approvals this fix needs"]
    R["Risk rules<br/>matched by the dry run"] -->|"can only raise"| A
    E["Emergency declared"] -->|"one technical approval before,<br/>the rest owed after"| A
    classDef in fill:#E9EEF6,stroke:#23407A,color:#13202D
    classDef out fill:#DCE3EE,stroke:#13202D,stroke-width:2px,color:#13202D
    class P,R,E in
    class A out

The environment's policy

Each environment names the roles that approve, and optionally how many approvals each gives and in which order.

One approval per role, in sequence. This is what most installations need.

policies:
  prod:
    approvals: [dba_reviewer, business_approver]
    ticket_required: true
  non_prod:
    approvals: [dba_reviewer]

Two DBA approvals and one business approval, given in any order.

policies:
  prod:
    approvals:
      order: parallel        # or sequential (the default)
      require:
        - { role: dba_reviewer, count: 2 }
        - { role: business_approver, count: 1 }
    ticket_required: true
  • Sequential: the DBA reviewers approve first, then the business.
  • Parallel: anyone whose approval is still needed may approve, in any order.

Counts go from 1 to 5. A technical (dba_reviewer) approval is always required, and in sequential order it comes first.

Without a policies section, production needs a DBA reviewer, a business approver and a ticket; non-production needs a DBA reviewer.

Risk rules

A risk rule raises the approvals for fixes that match it, judged on the dry run: many rows, several statements, a sensitive column, a disabled trigger. A rule can add approvals or cap the rows, never remove an approval.

policies:
  prod:
    approvals: [dba_reviewer, business_approver]
    risk_rules:
      - name: large-change
        tier: 2
        when: { min_rows: 1000 }
        require:
          - { role: dba_reviewer, count: 2 }

The request page shows the tier the fix was assessed at and how many approvals each role still needs.

Signed approvals

An environment can require that every approval is signed with the approver's passkey (signed_approvals: required). The approver compares a short approval code on their screen with the one their authenticator shows, then confirms with one touch. A signed approval proves the approver, not their session alone, agreed to this exact fix.

Approvals expire

Approvals are valid for a limited time (defaults.approval_ttl_h). An approved fix that is not executed in time goes back for review.

Emergency changes

For a change that cannot wait for every approval, an administrator can allow emergency changes on an environment (emergency.enabled: true). They are off until then, and where no environment allows them, no page shows anything of them.

sequenceDiagram
    actor R as Requester
    actor D as DBA reviewer
    participant S as sealfix
    actor B as Business approver
    R->>S: Declare an emergency, with a reason
    S-->>D: Tell the approver roles at submit
    D->>S: Technical approval
    R->>S: Execute
    S->>S: Run, as any fix
    Note over S,B: The skipped approvals are now owed<br/>within review_within_h (default 24 h)
    B->>S: Approve or reject after the fact
    S->>S: The executor checks the decision<br/>and completes the review or records the rejection
  • The requester declares it when creating the request, with a reason. The category is fixed from then on.
  • It runs on one technical approval, never on none and never on the requester's own. Everything else still applies: sealing, checks, the dry run, one transaction, before-images and who may approve.
  • It may run outside the execution windows, but not during a blackout unless that blackout allows emergencies.
  • The skipped approvals are owed within review_within_h hours of the execution (1 to 72, default 24). The people who owe them find the request first in their review queue and on their home page, and approve or reject it on its page as usual.
  • Everyone who may see the request sees that it is an emergency, why, and the state of its review: owed, overdue, rejected, rejection acknowledged, or complete.
  • The approver roles are told when it is declared. When it ran, they and the auditors are told that its review is owed, and the approver roles are reminded once at half of the time. An overdue or rejected review reaches the administrators too. No notice carries the reason or who rejected it.
  • A rejected review rolls nothing back: an administrator acknowledges it, and a rollback is a request of its own. A requester with an overdue review, or a rejected one not yet acknowledged, cannot declare another emergency.
  • Every step is in the audit log, without the reason. The alert rules that come with sealfix raise one while a review is overdue.