Approval workflow

What it does

Adds a distinct Approve step that a different admin must complete before a change can be scheduled or applied. Until approval, the change cannot update the customer's Entra tenant. Critical changes require this second-admin step even when the workspace-wide setting is off.

The workflow is workspace-wide: flip it on once in MSP settings and every tenant under that workspace inherits the two-admin gate.

When to use it

• Compliance frameworks (SOC 2, ISO 27001) that mandate dual control on production identity changes.
• Internal policy that no single admin should be able to push CA writes alone.
• Higher-trust customer tiers where you want to add an audit checkpoint without forcing a separate runbook.

If you're the only admin in the workspace, leaving require_approval off is the simpler choice - the four-eyes rule below means a single admin literally cannot apply anything.

Enabling it

1. Sign in as Owner.
2. Settings → Workspace → toggle Require approval on change requests.
3. Save. The setting is checked whenever a preview runs. An existing preview keeps its current state until it is re-run.

The toggle is the msp.require_approval boolean - the same column the server uses to decide which apply path to follow.

The new state machine

Without approval (require_approval = false):

draft → preview passed → apply → applied

With approval (require_approval = true):

draft → awaiting approval → approved → schedule or apply → applied
                         ↘ cancelled

The preview's 30-minute clock keeps running while approval is pending. Approval unlocks the normal schedule and apply controls but does not update Entra by itself.

The four-eyes rule

The same admin that created the change cannot also approve it.

This is enforced server-side: the approve action rejects with cannot_self_approve if auth.uid() = change_request.created_by. Owners are not exempt - even an Owner who created the change must hand it to another admin.

Step-by-step: requester

1. Tenant detail → Changes → Propose change, same as before.
2. Fill in the payload and click Run preview.
3. Review the diff and warnings. A passing preview moves the change to Awaiting approval.
4. The change appears under Changes awaiting approval on the workspace dashboard for the other admins.

Step-by-step: approver

1. From the dashboard's Changes awaiting approval card (or a notification channel link), click into the change.
2. Review the diff, warnings, creator, and preview expiry time.
3. If the diff matches expectations, click Approve. Policytab records the approver and unlocks the schedule and apply controls.
4. Apply immediately or choose a future time. If something looks wrong, use Cancel change and tell the requester why.

What the audit log records

The audit log records the change proposal, preview, approval, and eventual schedule or apply events separately. Each entry includes the acting user and change resource, so reviewers can distinguish the requester, approver, and operator who completed the change.

Troubleshooting

• The page says you cannot self-approve. You created this change. Ask another admin to take it.
• Approve button missing entirely. Your role is readonly. Approval requires admin or owner.
• The preview expired while waiting. Open the change and click Re-run preview. A re-run clears the previous approval state, so a different admin must review the fresh result.
• I toggled the setting off but a change is still awaiting approval. Re-run its preview to evaluate it against the current workspace setting. Critical changes still require approval.
• Apply fails after approval. Use the same recovery as any failed apply; see Troubleshooting. Re-running the preview requires fresh approval.

Combining with scheduled changes

Approval and scheduling compose. After approval, an admin can schedule the change for a future apply time. Scheduled changes use an extended preview window of up to 7 days; immediate apply keeps the 30-minute preview window. See Scheduled changes for details.