Policies & Rules

Every group or resource that Provisionr integrates with has a 1:1 mapping to a policy that defines the conditions about which users are granted access to that group or resource. Policies are not reusable so no group or resource shares the same policy.

Separate Policies per Group — Each group has a 1:1 relationship with a policy.

Policy Rulesets

A policy can have one or more Policy Rules, also known as a set of rules that we refer to as a Policy Ruleset.

A ruleset with rules and conditions — A ruleset holds rules, and each rule holds conditions.

Throughout the documentation, we use Policy, Ruleset, and Policy Ruleset interchangeably. They all refer to the same thing, and the official name is Policy Ruleset, however we often just say Policy or Ruleset for short.

Imported Attribute Rulesets

When you connect an integration and import groups or resources, Provisionr automatically creates a Policy Ruleset for each group or resource that you imported.

Count of Imported Attributes

{
    "Cost Center": 3,
    "Division": 8,
    "Department": 28,
    "Title": 131,
}

You will see the Policy Ruleset ID on every Attribute and every Group or Resource record in Provisionr.

IT Department Attribute Data

{
    "id": "dratr_01kgstavxctryyfg46k2dnepqc",
    "workspace_integration_id": "wsitg_01kgst0661n7j9natpk42xp12v",
    "directory_dimension_id": "drdim_01kgst085d5jr6pq2mvzxa9hae",
    "directory_attribute_id_successor": null,
    "policy_ruleset_id": "poset_01kgstavy0q6s4bkbsj08n25ts",
    "type": "integration",
    "profile_value": "IT",
    "blueprint_signature": null,
    "name": "IT",
    "handle": "it",
    "metadata": [],
    "conditions_enabled": true,
    "created_at": "2026-02-06T15:50:05.000000Z",
    "updated_at": "2026-02-06T15:50:06.000000Z",
    "activated_at": "2026-02-06T15:50:05.000000Z",
    "expires_at": null,
    "deleted_at": null,
    "state": "active",
}

Policy Ruleset for IT Department Attribute

{
    "id": "poset_01kgstavy0q6s4bkbsj08n25ts",
    "type": "directory_attribute",
    "resource_id": "dratr_01kgstavxctryyfg46k2dnepqc",
    "is_authoritative": true,
    "sync_enabled": true,
    "expires_after_days": 30,
    "created_at": "2026-02-06T15:50:06.000000Z",
    "updated_at": "2026-02-06T15:50:06.000000Z",
    "deleted_at": null,
    "state": "managed",
    "policy_rules_count": 1,
    "policy_users_count": 27,
    "policy_conditions_count": 1,
}

The ruleset includes one rule by default.

A single rule with one condition for an attribute

Policy Rule for IT Department Attribute

{
    "id": "porul_01kgstavz1ckwq4jv3pcef3pwk",
    "policy_ruleset_id": "poset_01kgstavy0q6s4bkbsj08n25ts",
    "policy_role_id": "porol_01kgsszte9w7zj8at8zar2man8",
    "is_imported": true,
    "description": "Imported rule from integration profile attribute",
    "expires_after_days": 30,
    "priority": 88,
    "created_at": "2026-02-06T15:50:06.000000Z",
    "updated_at": "2026-02-06T15:50:06.000000Z",
    "activated_at": "2026-02-06T15:50:06.000000Z",
    "expires_at": null,
    "deleted_at": null,
    "state": "active",
    "policy_conditions_count": 1,
    "manifest_users_count": 27,
    "expires_after_days_inherited": true,
}

The imported rule is created with a single Identity Condition to match the string value found in user profile data. This becomes your single source of truth (SSOT) when using that attribute. You can attach this attribute to any group or resource, and if the attribute value changes in the future, you can update it in one place and all of the groups and resources that are using that attribute ID so everything automagically works without renaming the string matching rule everywhere.

Policy Condition for IT Department Attribute Rule

{
    "id": "pocon_01kgstavzzfnydfpjscr3c1t5z",
    "policy_ruleset_id": "poset_01kgstavy0q6s4bkbsj08n25ts",
    "policy_rule_id": "porul_01kgstavz1ckwq4jv3pcef3pwk",
    "directory_attribute_id": null,
    "manager_id": null,
    "workspace_integration_id": "wsitg_01kgst0661n7j9natpk42xp12v",
    "directory_user_id": null,
    "is_imported": true,
    "type": "identity",
    "description": "User Demo identities where department equals IT",
    "profile_key": "department",
    "profile_operator": "equals",
    "profile_value": "IT",
    "created_at": "2026-02-06T15:50:06.000000Z",
    "updated_at": "2026-02-06T15:50:06.000000Z",
    "deleted_at": null,
}

Policy User Lifecycle

A Policy Ruleset has a list of Policy Users — a many-to-many mapping to Directory Users. This list is recalculated on a recurring schedule so new users with matching conditions are added and users that no longer match are deprecated. When a User is attached to a Ruleset, the relationship is stored in the Policy Users database table. The benefit of having a dedicated relationship table is lifecycle tracking that provides valuable data for auditability:

When the user was added — created_at
When a user’s metadata changed and disqualified them — expires_at is set for a graceful transition
When the user is scheduled to be removed — expires_at
When the user was removed — deleted_at
The current relationship state — state
Which rule they qualified for — rule_id

Policy Conditions

A Policy Ruleset can have an unlimited number of Rules, and each rule can have an unlimited number of Conditions. This allows you to create custom rulesets with as much granularity as you need. A Condition is similar to an equation where we evaluate the left and right side with an operator and determine if the result is true (matched) or false (not matched). If a user matches every condition in a rule, they are considered a qualified user. In other words, this and that. If a user matched in the past but no longer matches, they are considered a disqualified user. Any user that doesn’t match all conditions is ignored. A user can qualify for any one of the Rules to be added as a Policy User. In other words, this or that.

A ruleset with multiple rules — Rules combine with or — a user who matches any rule qualifies.

There is no deny or except precedence between rules. Once a user qualifies through one rule, adding a second, more restrictive rule never removes them — it only pulls in anyone new who matches it. The benefit of multiple conditions is that you can improve least privilege and get better granularity with a smaller set of users that qualify, and avoiding the sprawl of role-based access control strings.

Typical ruleset with multiple rules and conditions

Take the imported Sales division. A custom Sales Region dimension can narrow it further: a US Country Sales Team attribute uses a single rule with two conditions, both of which must match.

identity   division     {equals}  Sales
identity   countryCode  {equals}  US

Each condition added to a rule tightens the result. A California Sales Account Executives attribute pins the audience down to one team with four conditions, all of which must be true.

identity   division     {equals}  Sales
identity   countryCode  {equals}  US
identity   state        {equals}  CA
identity   title        {equals}  Account Executive

There is no hard limit on the number of conditions in a rule; in practice a handful is enough to isolate almost any team.

A sales team rule with several conditions — Each additional condition narrows a rule to a more precise audience.

Identity Conditions

An Identity condition is used for string matching values in the integration identity profile data from a vendor’s API response. When you create an Identity Condition, you will choose an existing Integration and specify the key that you want to evaluate (ex. department). You will choose which operator to use (ex. equals) and provide the string value that you are looking for (ex. IT). You have already seen how we imported the profile data from the integration API and created Dimensions and Attributes based on the keys and values in that profile data. Each of those imported rules uses an Identity Condition. During each background sync job, Provisionr will look at all Identities (user data from a specific Integration) and return all users that have a metadata key with the corresponding value based on the operator evaluation logic. In other words, if {this} {equals} {that} then evaluate as true.

Condition Operators

We support several condition operators for string evaluation.

equals
not (equal to)
- division {not} Finance
empty (null)
- title {empty} (null or empty string)
exists (not null)
- employeeNumber {exists} (not null and not empty string)
greater (than or equal to)
- created_at {greater} 2026-01-01
less (than)
- expired_at {less} 2025-12-31
prefix (starts with)
- title {prefix} Senior or title {prefix} Sr.
- title {prefix} VP
- title {prefix} Vice President
suffix (ends with)
- email {suffix} @example.com
- email {suffix} [email protected]
- email {suffix} @vendorcorp.com
- title {suffix} Manager
contains (keyword)
- title {contains} Engineer
- title {contains} Manager

Real World Example for Identity Conditions

In the example above, we have a rule for the IT Applications team where the title {contains} IT Applications. This means that any user that has a job title with the keyword “IT Applications” will match this condition. Remember that they have to match all of the other conditions for the rule as well.

Directory Identity Data

{
    "id": "dridt_01kgst84tp97hr59ed28cvn3yh",
    "workspace_integration_id": "wsitg_01kgst0661n7j9natpk42xp12v",
    "directory_user_id": "drusr_01kgst84wc8ak0a5ng6snvtw1n",
    "vendor_id": "14d480e7",
    "email": "[email protected]",
    "profile": {
        "costCenter": "G&A",
        "department": "IT",
        "division": "Finance",
        "email": "[email protected]",
        "employeeNumber": "fcf70a5d",
        "firstName": "Ian",
        "handle": "isanford",
        "lastName": "Sanford",
        "managerId": "e31f9013",
        "reportsTo": "IT Applications Manager",
        "title": "IT Applications Engineer"
    },
    "provisioned_at": "2020-01-13T14:47:36.000000Z",
    "profile_changed_at": "2020-01-13T14:47:36.000000Z",
    "last_authenticated_at": "2026-01-28T14:46:36.000000Z",
    "deprovisioned_at": null,
    "created_at": "2026-02-06T15:48:36.000000Z",
    "updated_at": "2026-02-06T15:48:36.000000Z",
    "deleted_at": null,
    "state": "active"
}

Considerations for String Matching

Only use Identity Conditions for partial matches (e.g. contains). For exact equals matches, use an Attribute Condition, Manager Condition, or User Condition instead.

Identity string matching is a raw string evaluation with no lifecycle management. If the value is renamed in the Integration, the condition silently breaks with no visibility to admins or end users. If you reuse the same logic in multiple places or the value is predictable, use an Attribute Condition instead. This gives you a single source of truth and a selectable menu of choices rather than repeated raw strings.

Your policies are mapped to the ID instead of the string value, so if the value changes, you can update the attribute’s display name and all of the policies that reference that attribute will automatically be updated.

Each Attribute has its own lifecycle management, so you can track changes over time and have a clear audit trail of what happened when, and why. Attributes have successor and predecessor relationships so we can easily handle remappings as the names of your attributes change over time. Renaming an attribute’s display name or handle in Provisionr is always safe, because the relationships are tied to the ID. A different value arriving upstream is the case the lifecycle handles: when a value is renamed at the source — say Commercial Sales becomes Mid-Market Sales — the next sync detects the new value and creates its attribute, while the old imported condition stops matching because no user carries the old value anymore. Rather than silently dropping access, Provisionr surfaces the affected users for review and hands them to the deprecation lifecycle, which grants a grace period before any access is removed — enough for a role change that needs a few days of overlapping access. You can also use expires_at to set a date for when the attribute should be automatically deprecated and no longer used in policies, and any users that were attached to that attribute will be automatically detached after the expiration date is reached.

Attribute Conditions

Attribute conditions are the most powerful and flexible condition type for defining rules based on user attributes in a single source of truth location. Since each Directory Attribute has its own ruleset with rules and conditions, it acts as a reusable ruleset that allows you to define string matching in a single source of truth for your organization logic, and reuse that Attribute in different rules across your groups and resources without repeating your string matching logic in multiple places. You’ve already seen how we imported the profile data from the integration API and created Dimensions and Attributes based on the keys and values in that profile data. Each of these attributes are now usable in any rule as an Attribute Condition. You can create additional custom Directory Dimensions and Attributes that each have a Ruleset that you can add Rules and Conditions to that is reusable for attaching to various groups and resources. This is useful for granular dimensions that are now available in your HRIS that you want to use across multiple groups and resources. For example, you could create a Team dimension and create an Attribute for each team in your organization. Then you can use that attribute in any rule for any group or resource. This is also useful for special projects, sales regions, or who should have access to data about a specific customer. If you’re use to creating a Google group and adding everyone to that Google Group, you want use a Provisionr attribute instead and then use that attribute in your group rulesets. This allows you to have a single source of truth for who should have access to that customer or project, and you can use that attribute across multiple groups and resources without having to manage the membership of a Google Group, Google Drive folder, Slack channel, etc. Now that you have a database record for each Attribute, you can use that record’s ID by selecting it from a dropdown menu when creating a condition instead of having to remember the exact string that you need to match.

Manager Conditions

You can choose a manager and all users that report to this person will be added. A rule can mix condition types. Pairing a manager condition with an Identity Condition keeps only the reports that also match a profile field. A NorCal Account Team rule might combine the two:

manager    reports to   Wren Odell
identity   title        {equals}  Account Executive

Drop the identity condition to include everyone who reports to the manager, or keep it to narrow the team to a single job title. New hires that report to this manager are automatically added. If a user’s manager changes, the ruleset that they qualified for will consider them to no longer be qualified. This is handled by the lifecycle deprecation process so their access to groups and resources will expire after X days based on the respective ruleset’s expires_after_days.

Manager conditions only include direct reports, not the manager themselves. You need to create an additional rule for the manager if you want them to be included as well, based on the manager’s job title (if it’s unique to that person) or a User rule with the specific User ID .

User Conditions

If you have a corner case where a user does not have one or more attributes that qualify them for a rule, you can select one of your Directory Users from the drop down list.

Use User conditions for exceptions, not as a primary method for granting access. If you use User Conditions extensively, you lose the benefit of job roles having predefined access. You will need to manually add rules for each user during onboarding and remove them if they change job roles. By using Attribute and Manager conditions instead, all of the logic is based on their profile attributes rather than their email address (in essense).

Rule Priority

When you have multiple rules in a ruleset, you can assign a priority from 1 (evaluated first) to 99 (evaluated last), similar to firewall rule or access control list (ACL) priority. The default priority for custom rules if not set is 42 and the default priority for imported attribute rules is 88. And yes, both of those are easter egg pop culture references. The reason for the default priority for imported attribute rules is that we want to encourage you to use custom rules with higher priority (lower number) to override the imported rules if needed, rather than having to edit the imported rules directly. Rules with the same priority are evaluated based on the greatest number of users matched, from highest to lowest. This is designed to ensure that rules that apply to entire departments are evaluated first before rules for a smaller team. It allows you to keep your rule sprawl to a minimum and allows you to see which rules don’t have any effect. A user may qualify for multiple rules. They are associated as a Policy User based on the Policy Rule that they qualify for that has the lowest priority value. For example, if they qualify for Rule X with Priority 10 and Rule Y with Priority 42, their Policy User relationship is associated with Rule X. Rule qualification happens during each scheduled sync or on-demand for a specific group. If they no longer qualify for Rule X, their Policy User relationship will be deprecated and scheduled for expiration based on the expires_after_days value. An administrator can always change the expiration date to be sooner or extend it to be later, or deactivate them immediately if needed. When their association with Rule X expires, a new Policy User with Rule Y will be created. Since this happens during the sync job, this is only for audit log purposes to show timestamps of when they qualify for each. Unless the role associated with each Rule is different, the user will not notice any disruption or changes.

Short-Term Access

When you want to add a rule with conditions that are only valid for a short period of time, you can set the expires_at value. After the expires_at value has passed, the rule and associated conditions are automatically soft deleted, and any users that previously matched the rule’s conditions will be detached from the attribute. The expires_at value is useful for temporary access, such as a contractor that only needs access for 90 days, a special project, vacation coverage that only needs access for a few days or weeks, or access for an employee that has changed job roles and is supporting the old team for the next few weeks or months while transitioning to the new role. You do not need to worry about manually removing the rule or conditions after the access is no longer needed, and you can have confidence that there will not be any lingering access after the expiration date has passed. The expiration is evaluated during each sync for any expires_at values that have passed, not at the exact moment that the expires_at value is reached. This means that there will be a delay between when the rule expires and when the users are detached. The maximum delay is based on your sync frequency: with daily sync the maximum delay is 24 hours, with hourly sync it is 1 hour, and with 15-minute sync it is 15 minutes.

Policies define who qualifies — but how do those qualifications get applied to actual groups? Let’s look at the groups and resources those policies are applied to. Continue reading: Groups & Resources →

Introduction

Architecture Concepts

Workforce Identity Foundations

Policy Rulesets

Imported Attribute Rulesets

Policy User Lifecycle

Policy Conditions

Identity Conditions

Condition Operators

Real World Example for Identity Conditions

Considerations for String Matching

Attribute Conditions

Manager Conditions

User Conditions

Rule Priority

Short-Term Access

​Policy Rulesets

​Imported Attribute Rulesets

​Policy User Lifecycle

​Policy Conditions

​Identity Conditions

​Condition Operators

​Real World Example for Identity Conditions

​Considerations for String Matching

​Attribute Conditions

​Manager Conditions

​User Conditions

​Rule Priority

​Short-Term Access

Policy Rulesets

Imported Attribute Rulesets

Policy User Lifecycle

Policy Conditions

Identity Conditions

Condition Operators

Real World Example for Identity Conditions

Considerations for String Matching

Attribute Conditions

Manager Conditions

User Conditions

Rule Priority

Short-Term Access