Disabling Sync for a Group or Resource
When a group or resource is in aMONITORING or MANAGED state, each ruleset has a sync_enabled = true value by default.
You can temporarily (or permanently) disable the sync for a specific group or resource by changing the sync_enabled value to false on the ruleset. This will prevent any changes from being made to that group or resource during the sync, and any users that match the rules and conditions will not be added or removed from the group or resource in the integration.
You can re-enable the sync at any time by changing the sync_enabled value back to true, and any changes that should have been made during the disabled period will be applied during the next sync based on the latest calculation of the Policy Users for the ruleset.
This allows you to have more control over when changes are made to your groups and resources, and avoid any unexpected changes during a critical time. This is useful if you are encountering errors, have a planned data migration, or otherwise just want to freeze the data in the current point in time. This is also useful for groups or resources that are in an archive or deprecated state and you simply are not actively managing them anymore.
Sync Change Window
Provisionr caches data from each vendor API on a recurring basis based on the frequency that is included with your subscription plan and the sync window that you choose. To avoid hourly API rate limits and conserve CO2, we use a 3-hour time window instead of a 1-hour time window for syncs. The frequency of the sync is determined based on your subscription plan.- Baseline Plan: Weekly sync. Choice of day of week and the preferred and secondary time window.
- Growth Plan: Daily sync. Choose the preferred and secondary time window.
- Scale Plan: Sync every 3 hours.
These times align with US Standard Time from November to March and Daylight Savings Time from March to November.Each scheduled sync performs a user sync, two attribute syncs, followed by a group and resource sync.
User Sync
1
API User Current State
Fetch users from the vendor API.
2
Identity Changes
Check for new users (importing Identities), deprovisioned users, and any profile data changes.
3
Dimension Changes
Check for any new, changed, or missing dimensions (profile keys) in the Identity profile data and create, update, or deprecate Directory Dimension database records accordingly.
4
Attribute Changes
Check for any new, changed, or missing attributes (unique profile values) in the Identity profile data and create, update, or deprecate Directory Attribute database records accordingly. Any newly imported Attributes include an Imported Attribute Ruleset.
5
New Directory Users
If a new user appears in your primary integration (usually your IdP), we create a new Directory User that is used for qualifying for rules for Attributes, Groups, and Resources.
6
Deprovisioned Directory Users
If an existing user is deactivated in your IdP, we deactivate the User in Provisionr and they are removed from the Attributes, Groups, and Resources.
7
Manager Sync
We re-calculate manager relationships based on the integration field matching that you have configured.
Attribute Syncs
A rule can have an Attribute Condition. We run the Attribute sync twice in a row to cover the use case of a user that qualifies for an attribute, and needs to also qualify for a rule that requires a user to be associated with an Attribute. The first sync will qualify the user for an Attribute based on Identity, Manager, or User conditions. The second sync will qualify users for rules that use an Attribute condition.1
Attribute Rule Qualification
We calculate which users match all conditions for each rule and update the database table of qualified users for each rule.
2
Attribute Ruleset Manifest
We look at all of the qualified users for each rule and create the list of unique users based on the rule priority
3
Create or Deprecate Attribute Policy Users
We compare the Manifest Users to the current Policy Users for each Ruleset, and add missing users or deprecate ones that no longer qualify.The expiration period for the deprecation is based on the
expires_after_days that is inherited from the Ruleset or Rule (if overridden).BREAKAn administrator can always override the expires_at value for any individual Policy User or immediately deactivate them once they are in an EXPIRING state. If a user re-qualifies for the same Rule before the expires_at date, the Policy User will become ACTIVE again and the expires_at will be removed.This provides a grace period for changes (ex. department or team renames) without creating unnecessary disruption to the user if backoffice attributes or rules are changing but the user still has a business need to be a member of the group (or resource).If a user re-qualifies for the same Rule after the expires_at date, the Policy User will have already expired. A new Policy User record will be created. This shows the lifecycle of both qualifications.Group and Resource Sync
After we have updated user data, and we have requalified users for Attribute conditions, we can qualify users for the Rules for Groups and Resources. For documentation clarity, we usegroups for this explanation, however the concept is the same for resources (ex. GitLab Project, Google Drive Folder, Google Doc, Slack Channel, etc).
1
API Group Current State
UnmanagedMonitoredManagedFetch existing groups from the vendor API.
2
Update {Vendor} Groups Current State
UnmanagedMonitoredManagedCheck for new groups (importing Groups), deleted/missing groups, and any name or metadata changes.
3
API Group Member Current State
MonitoredManagedFetch existing group members (attached users) for each group from the vendor API.
4
Group User Changes
MonitoredManagedImport pre-existing group members that are not a Provisionr Policy User in
UNMANAGED state. Any existing users in Provisionr database that no longer appear in vendor API response are changed to DEPROVISIONED state. This provides an audit trail of users managed outside of Provisionr.5
Group Rule Qualification
ManagedWe calculate which users match all conditions for each rule and update the database table of qualified users for each rule.
6
Group Ruleset Manifest
ManagedWe look at all of the qualified users for each rule and create the list of unique users based on rule priority.
7
Create or Deprecate Policy Users
ManagedWe compare the Manifest Users to the current Policy Users for a Ruleset, and add missing users or deprecate ones that no longer qualify.The expiration period for the deprovision is based on the
expires_after_days that is inherited from the Ruleset or Rule (if overridden). An administrator can always override the expires_at value for any individual Policy User or immediately deactivate them once they are in an EXPIRING state.If a user re-qualifies for the same Rule before the expires_at date, the Policy User will become ACTIVE again and the expires_at will be removed. This provides a grace period for changes (ex. department or team renames) without creating unnecessary disruption to the user if backoffice attributes or rules are changing but the user still has a business need to be a member of the group (or resource).If a user re-qualifies for the same Rule after the expires_at date, the Policy User will have already expired. A new Policy User record will be created. This shows the lifecycle of both qualifications.8
Remove Expired Users
ManagedThe Policy Users that were deprecated in a previous sync have an
expires_at date. If that date is in the past at the time of the sync, the Policy User state is updated to EXPIRED and the database record is soft deleted. This effectively removes the user from the manifest list of users that will be synced with the vendor API in the next steps, and they will no longer be considered a member of the group in Provisionr.This allows us to maintain an audit trail of the user lifecycle and qualifications over time, and also allows administrators to have a grace period to fix any issues with rules or attributes that may have caused users to be deprovisioned before they are fully expired and removed from the group in the vendor API.9
Provision Policy Users in API
ManagedNon-AuthoritativeAuthoritativeProvision any Policy Users in the vendor API that do not exist already.
10
Deprovision Policy Users in API
ManagedNon-AuthoritativeAuthoritativeRemove any users that no longer match the policy. For non-authoritative groups, this applies only to users that are not in an
UNMANAGED state. This ensures that pre-existing users are not removed in this step. For authoritative groups, any users that do not match the policy are removed int the next step.11
Deprovision Unmanaged Users in API
ManagedAuthoritativeIf a group is in an authoritative state, you have granted Provisionr the authority to be the source of truth for who should have access to that group. Any pre-existing user or user that is granted access outside of Provisionr (with click ops or other automation) is a risk for least privilege access. To mitigate this risk, any users that were added outside of Provisionr and/or do not match the current policy are removed during each sync to maintain least privilege access.If a user is in an
UNMANAGED state, they are not qualified for any rules, and they are still a member of the group in the vendor API, we change their state to DEPROVISIONED in Provisionr and remove them from the group in the vendor API. This ensures that any users that were added outside of Provisionr are removed to maintain least privilege access.Remove any users that no longer match the policy that are not in an UNMANAGED state. This ensures that pre-existing users are not removed.Data Retention Duration
Provisionr has a configurable retention policy for how long we keep personally identifiable information (PII) for deprovisioned users in the database after they are deprovisioned in the vendor API. In other words, after X days of an employee leaving the company, we will scrub their PII data and replace it with a Ghost User and null values where appropriate, while still maintaining the same user ID and vendor ID for any existing log records that are associated with that user. You can choose the number of days that works best for your organization’s internal processes and compliance requirements. How: When fetching users from the API, users that were deprovisioned more than# days ago are not imported or synced. Any existing log records are mapped to the same user ID, however the PII data is scrubbed and replaced with a Ghost User and null values where appropriate.
Why: This solves for personally identifiable information (PII) and GDPR compliance since we do not have a business need for role-based access control (RBAC) after we have verified that a user has left the company and their access deprovisioning processes are completed and audited.
Config: The default value is set to 90 for new integrations. You can modify any of your existing integrations and decrease it or increase up to 1095 (3 years). It is technically possible to lower this value down to 1, however you may encounter data integrity issues with eventually consistent background API sync jobs. The lowest reasonable number should be 10 days to allow time for all deprovisioning lifecycle tasks and your organization’s internal processes to occur.
Impact: If the value is increased, the users that previously were exempt will be imported during the next sync. If the value is decreased, the users that previously were included will be archived and PII will be scrubbed. If the value is re-increased, previous users are matched to their vendor_id and their PII is restored on the existing database records. All changes are logged and will trigger event transactions for impacted users.
You’ve completed the Concepts learning path. For deep-dive reference on any topic, explore the other sections of the Architecture docs:
- Users & Identities — User identities, state mapping, and sync flows
- Dimensions & Attributes — Dimension and attribute management
- Policies & Rules — Rulesets, conditions, and rule priority
- Integrations — Vendor support, workspace integrations, and configuration