Policy operations — change · impact verification · staged rollout

Lesson 4 authored your first policy. This lesson covers the operational flow when you change that policy. This is the spot where permission incidents happen most often, and the one that most often falls back to manual inspection.

The 3-step operational flow for policy changes

As an organization grows, a single policy change shifts the visible slice for dozens of users at once. Wrapping a single change in 3-step operations prevents almost all incidents.

Step 1: Make the change intent explicit

Before opening the policy editor, write three lines (in the commit message or change ticket).

• Which user group's slice changes how?
• Why is this change needed? (Source: security team · business unit · compliance)
• Reversion criteria. (Specific date · specific condition)

Once written down, this body becomes the baseline for post-change impact verification and rollback.

Step 2: Impact verification — pre-change simulation

Portal's policy editor includes a Change Simulation feature (upper-right of the editor: Impact preview). It shows you the state after the change is applied before the actual application.

Check three numbers.

• Affected user count — Before vs after. If it differs from intent by even one order of magnitude, stop.
• Affected datasets/resources count — One policy may attach to multiple datasets.
• Affected row count — For row-filter policies, how many rows are newly hidden or newly revealed. Confirm the delta matches intent.

If the three numbers match intent, proceed.

Step 3: Staged rollout

If the impact is large, don't apply broadly at once. Two staged-application patterns.

• Group-level isolation — Apply the change to a small pilot group (e.g. 5 members of IT Operations) before going wide. After a week without issues, expand.
• Collection-level isolation — If the policy attaches to multiple collections, apply to lower-risk collections first. Analyst sandbox → analytical datasets → production datasets, in that order.

Rollback — reverting as the operational default

Policies record a change history automatically. The policy detail's History tab makes revert to N versions ago a one-click action.

Early in operations, treat the 24 hours after any policy change as the monitoring window. If missing-permission · over-permission reports come in during that window, roll back immediately, strengthen Step 1's change intent body, and retry.

The one-line rule for incident prevention

The most frequent line you'll hear from year-one admins — "never change a policy on a Friday afternoon". The flow of intent → verification → staged rollout → rollback monitoring requires time + attention, and when a permission incident hits over the weekend, manual response stalls until Monday morning.

What you should be able to do after this lesson

• The 3-step operational flow of policy changes (intent → verification → staged rollout)
• The three numbers on the change simulation (users · resources · rows)
• 24-hour monitoring window + one-click rollback from policy history

Next lesson

Audit trails — who · did what · when across resources via the Recents screen.