Time Based Provisioning

Time based provisioning policies allow you to override source statuses and defaults by either:

• Activating users a configured number of days before their specified start date.

• Deactivating users a configured number of days after their specified end date.

For Identity Hub implementations, there are default policies set per role that immediately apply any changes to a user's status or start and end dates. In cases where an early activation or delayed deactivation is needed, a policy can be customized to reflect the specific need. These policies can be set at the role level or more granularly by adding a rule to the policy.

Time based policies require a start or an end date to be assigned to a user, which is used to calculate the time offset for the policy. These dates can be mapped from a source or they can be automatically populated by Identity Hub when an account appears or disappears from the source data.

Activation policies are applied based on the following attributes:

• idautoPersonStartDate for students

• idautoPersonStaffStartDate for teachers and staff

• idautoPersonContractStartDate for sponsored

Deactivation policies are applied based on the following attributes:

• idautoPersonEndDate for students

• idautoPersonStaffEndDate for teachers and staff

• idautoPersonContractEndDate for sponsored

Additionally, time based policies generate a modification for the idautoDisabled attribute to enable or disable users.

Both types of policies accept an optional day offset for applying the changes. For example, time based provisioning allows you to activate a newly hired teacher the week before their start date but provision them in mid-summer after their position acceptance. This can be done with an activation policy to enable the user four days before their start date listed in the source data. You could also keep a graduated student active for 180 days after their commencement with a deactivation policy.

When customizing a time based policy, a rule is required during configuration. This rule functions as a filter that determines what users should be affected by the policy. For custom policies that should apply to all accounts in that role, add a Account Type contains {role} rule. You can add additional rules to further filter out the users who are affected by the policy.

Activation policies only apply if the end user has a start date set via a mapping from the source or the start date is set when the user is added to the source data feed and the user has an activation policy that applies to them. Deactivation polices only apply if the the end user has an end date set via a mapping from the source or the end date is set when the user is removed from the source data feed and the user has a deactivation policy that applies to them.