Change Management

Strategies for safely building, staging, and rolling out policy rulesets without unexpected provisioning changes.

Staged Rules

When you create a Rule for a Ruleset, either when the Rule is first created or after the Ruleset is already in use, it will be in a staged state. This means that it is a draft and is not in effect yet, so no users that qualify for this Rule will be included as Policy Users. This allows you to take your time to add multiple Conditions to the Rule and evaluate the preview of users.

If the Rule was prematurely activated, you could encounter a race condition with group/resource member sync. In other words, the first Condition that you add could add a lot of users unintentionally (ex. all users in a department), before you added the second or third Condition that refined the rule (ex. users with specific job title).

Staged vs Policy Users

When working with Rulesets, Rules, and Conditions, you will see different lists of users:

• Staged Users: This is a “conditional” preview of all users that would be included if the Ruleset and all Rules are in an active state.
• Policy Users: This is the “production” actual list of users who are currently included in sync jobs with any groups or resources (ex. Google Group or Okta Group) that are attached to this Ruleset.

Day-to-Day Strategies

The prime directive is to not provision or deprovision a large number of users unexpectedly.

With staged rules, you can see the expected users that are included in the Ruleset, compare it to the existing vendor resource users (from the vendor API), and show you which users will be provisioned and deprovisioned before making changes prematurely.

This is the opportunity to refine your Rulesets, Rules, and Conditions to get the users that you want.

This also provides an opportunity for your internal change management processes to preview/test the policy before going live.

There are two popular strategies for building Rulesets in day-to-day operations.

Everyone at Once

You will create all Rules with their Conditions so the final list of users looks good before activating each Rule.

This is common when working with a smaller number of users that need access.

Iterative Rollout

You will create your first Rule with the conditions for that Rule. You can then activate the Rule. Your first set of users will be provisioned during the next sync job.

You can create additional Rule(s) (that are in a staged state by default) and add Condition(s) for each.

You can activate each Rule when you are ready for that audience of users to be provisioned.

This is common when rolling out access to a large number of users and you want to have an initial set of users be beta testers, or roll out to a few teams or departments at a time. You can also use this approach for rolling out to specific groups of users on specific dates by activating the Rule during your change window that you announced to your employees.

We’ve seen this useful in the real world to grant access to beta testers during “week 1”, then engineering team members during “week 4”, and finally sales team members on the second week of the new quarter. This allows engineers to find the bugs, and avoids disrupting sales productivity with end of quarter activities if something goes wrong.