Policies & Rules

How rulesets, rules, and conditions determine which users get access to which groups and resources.

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.

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.

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.

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:

1. When the user was added — created_at
2. When a user’s metadata changed and disqualified them — expires_at is set for a graceful transition
3. When the user is scheduled to be removed — expires_at
4. When the user was removed — deleted_at
5. The current relationship state — state
6. 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.

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.

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} [e-mail]
  • 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": "[e-mail]",
    "profile": {
        "costCenter": "G&A",
        "department": "IT",
        "division": "Finance",
        "email": "[e-mail]",
        "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.

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.

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 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, so if you are on the Growth Plan, the maximum delay is 24 hours, and if you are on the Scale Plan, the maximum delay is 3 hours.

Learn more in the Building Policy Rules tutorial.

---

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 →