Scheduled Sync

How and when Provisionr evaluates policies and syncs changes to your connected systems.

Everything you’ve learned — integrations, users, dimensions, policies, and groups — comes together during the scheduled sync. This is when Provisionr evaluates policies and makes changes in your connected systems.

We want changes to happen during a change window that is best suited for your business hours.

Disabling Sync for a Group or Resource

When a group or resource is in a MONITORING 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.

You can choose the time of day that is best for your organization when changes should go live for predictability. The sync will be dispatched at the start of your preferred time window, and if there is an issue with the sync, it will retry during the secondary time window.

We do not allow syncs between 18:00 to 21:00 UTC that is reserved for maintenance and upgrade windows for Provisionr infrastructure.

UTC	US Central Winter (UTC-6)	US Central Summer (UTC-5)
00:00 to 03:00 UTC	6pm to 9pm	7pm to 10pm
03:00 to 06:00 UTC	9pm to 12am	10pm to 1am
06:00 to 09:00 UTC	12am to 3am	1am to 4am
09:00 to 12:00 UTC	3am to 6am	4am to 7am
12:00 to 15:00 UTC	6am to 9am	7am to 10am
15:00 to 18:00 UTC	9am to 12pm	10am to 1pm
18:00 to 21:00 UTC	N/A (Reserved for Maintenance Window)	N/A
21:00 to 24:00 UTC	3pm to 6pm	4pm to 7pm

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).

   BREAK

   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.

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 use groups 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

   UnmanagedMonitoredManaged

   Fetch existing groups from the vendor API.

2. Update {Vendor} Groups Current State

   UnmanagedMonitoredManaged

   Check for new groups (importing Groups), deleted/missing groups, and any name or metadata changes.

3. API Group Member Current State

   MonitoredManaged

   Fetch existing group members (attached users) for each group from the vendor API.

4. Group User Changes

   MonitoredManaged

   Import 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

   Managed

   We calculate which users match all conditions for each rule and update the database table of qualified users for each rule.

6. Group Ruleset Manifest

   Managed

   We 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

   Managed

   We 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

   Managed

   The 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-AuthoritativeAuthoritative

   Provision any Policy Users in the vendor API that do not exist already.

10. Deprovision Policy Users in API

    ManagedNon-AuthoritativeAuthoritative

    Remove 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

    ManagedAuthoritative

    If 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