Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.provisionr.io/llms.txt

Use this file to discover all available pages before exploring further.

Now that you understand how policies work, you can start to think about the groups and resources that you want to manage with Provisionr.

Managing Existing Groups and Resources

When you connect an integration to Provisionr, we import a list of all of the groups and resources that are available in the integration API and create a placeholder policy for each one in an unmanaged state. This allows you to have a single source of truth for all of the groups and resources that are available across all of the connected integrations, and you can choose which ones you want to manage with Provisionr. We do not make any changes until you explicitly choose to manage a group or resource by changing the policy state to managed. Once a group or resource is changed to the managed state, you can start adding rules and conditions to the policy, and any users that match those rules and conditions will be added to the group or resource in the integration. Rules are created in a STAGED state so you can design and configure them before they are activated. When you activate the rule, any users that match the rule’s conditions will be added to the group or resource in the integration.

New Groups and Resources

You can create groups and resources from Provisionr in a STAGED state to allow you to design the rules and conditions to see the list of users that are qualified. When you activate the group or resource in Provisionr, the group or resource will be provisioned and any users that qualify for the rules and conditions will be added.

Unmanaged Groups

When a group (or resource) is detected and imported into the Provisionr database, it is created in an UNMANAGED state. We know that the group exists and can show the ID, name, and description in a list, however we do not perform API calls to get details about that group including the members assigned. We only fetch group members (attached users) from groups that are in a MONITORED or MANAGED state in Provisionr.
The intent of UNMANAGED groups is to provide opt-in functionality so Provisionr cannot read your data unless you give express permission.

Monitored Groups

If you want to use Provisionr to provide read-only visibility to your groups, group members, and track the changes over time for audit events and observability, you can change any group to a MONITORED state, or set monitoring_enabled = true on the integration to enable it by default on all groups when they are detected. If monitoring is enabled, Provisionr will fetch the list of members and their role from each group (or resource) during the sync. Any new users, removed users, or changed roles are logged in the workspace event log. This allows you to have comprehensive reporting of who has access without Provisionr managing the policy.
Many customers prefer monitored over unmanaged groups to provide insights into where their biggest manual provisioning pain points are at so they can determine which groups they should create Provisionr policies for first. For security reasons, we just need you to opt-in to this behavior instead of assuming that it’s okay to read your data.

Managed Groups

When a group is in a MANAGED state, Provisionr is responsible for provisioning and deprovisioning users in that group based on the rules and conditions that you have configured. If a user is added to a group outside of Provisionr, the Policy User is in an UNMANAGED state. If the ruleset is authoritative, any users that are in an UNMANAGED state are removed from the group during the sync to maintain least privilege access. If the ruleset is not authoritative (default), any users that are in an UNMANAGED state are not removed from the group during the sync. This ensures that any pre-existing users that were added outside of Provisionr are not removed, and the policy is only applied to users that are in an ACTIVE state. In other words, the policy is not the source of truth for who should have access to the group, but it is still providing value by ensuring that any users that match the policy are added to the group (a.k.a. additive). You can change a group to authoritative later after you have rules and conditions in place, and you have given your team time to adjust to the new provisioning process. This allows you to gradually transition to using Provisionr for all of your groups and resources without causing disruption to your users.

Control Plane Considerations

Over time, you can choose to use Provisionr for your single pane of glass for provisioning groups and resources, and restrict the number of administrators that have access to create groups and resources directly in the integration. This allows you to have better control and visibility into the groups and resources that are being created, and ensure that they are being created with the appropriate policies and access controls in place.
With groups configured and policies defined, the last piece is understanding how and when Provisionr actually syncs these changes to your connected systems. Continue reading: Scheduled Sync →