Category: User Provisioning

Provisioning Rule

Also known as: Role Provisioning Rule, Provisioning Connector Rule

Simply put

A provisioning rule is a configured piece of logic in an identity system that governs how user accounts and access are created, changed, or granted in a target application or system. For example, a rule might automatically assign a role to a user based on their identity attributes, or carry out specific technical steps needed to set up an account. Provisioning rules automate access administration tasks that would otherwise be done manually.

Formal definition

A provisioning rule is a configurable logic component within an IGA or provisioning framework that determines or executes account and entitlement changes against a target source, typically in response to a provisioning plan (an account request specifying an operation on an identity's account in a given source). Provisioning rules span two broad functions depending on vendor and deployment: assignment-oriented rules that automatically grant roles and privileges based on identity attributes (for example, Oracle's Role Provisioning Rule), and connector or execution-oriented rules that translate provisioning plan actions into concrete operations against a target (for example, SailPoint's JDBC Provisioning Rule, which issues SQL commands over a supplied JDBC connection). Related lifecycle hooks such as after-provisioning rules can trigger side effects, for instance, notifying a target user on success or an application owner on failure. Exact rule types, triggers, and execution semantics vary by product; this entry does not cover runtime access enforcement (PDP/PEP evaluation), which is a distinct concern from lifecycle provisioning.

Why it matters

Provisioning rules are the automation layer that turns identity governance policy into concrete account and entitlement changes across target systems. Without them, access administration falls back to manual account creation and role assignment, which is slower, inconsistent, and error-prone. By encoding logic that assigns roles based on identity attributes or executes the technical steps to set up an account, provisioning rules help organizations enforce consistent access outcomes and reduce the operational burden of onboarding, transfers, and offboarding.

Because these rules directly determine what accounts exist and what privileges they carry, misconfigured provisioning logic can have significant consequences. An assignment rule keyed to the wrong attribute can grant excessive access, while a faulty connector rule can leave accounts in an inconsistent state in the target system. Lifecycle hooks such as after-provisioning rules help surface these problems, for example, by notifying an application owner when a provisioning action fails, so that failures do not go unnoticed and can be remediated.

It is worth keeping provisioning rules in their proper scope. They govern the lifecycle creation and change of accounts and entitlements, not the real-time evaluation of whether a principal may perform an action at access time. That runtime enforcement is a separate concern handled by policy decision and enforcement points. Treating the two as interchangeable can lead to gaps where governance assumes provisioning-time controls will do the work of runtime authorization, or vice versa.

Who it's relevant to

IGA Engineers and Administrators

Those who configure identity governance and provisioning frameworks author and maintain provisioning rules directly. They decide whether a rule assigns roles based on identity attributes or executes connector-level operations against a target, and they wire in lifecycle hooks such as after-provisioning rules to handle success and failure notifications.

Identity Governance Leads

Governance leads care about provisioning rules because they translate access policy into automated outcomes across target systems. They rely on assignment-oriented rules to enforce consistent role and privilege grants, while keeping in mind that these lifecycle controls are distinct from runtime access enforcement.

System and Application Administrators

Administrators who own target applications are affected by how provisioning plans are executed against their systems, for example, when a JDBC provisioning rule issues SQL commands to create or change accounts. They may also be the recipients of after-provisioning failure notifications and are typically responsible for remediating provisioning errors on their side.

Security Architects

Architects designing IAM systems need to place provisioning rules correctly within the overall architecture, distinguishing lifecycle provisioning from runtime authorization. Understanding where rules sit helps them avoid assuming that provisioning-time logic covers enforcement concerns that belong to policy decision and enforcement points.

Inside Provisioning Rule

Trigger Condition

The event or state that initiates the rule, such as a joiner, mover, or leaver event, an attribute change in an authoritative source (for example an HR system), or a group membership change. In most IGA deployments this is the entry point that determines when the rule evaluates.

Matching Criteria

The attribute-based or filter logic that selects which identities the rule applies to, typically expressed as conditions over source attributes such as department, job code, location, or employment status. This scopes the rule to a target population.

Target System and Entitlements

The downstream application, directory, or service where accounts or access are granted or revoked, along with the specific entitlements, roles, or group memberships involved. Provisioning may reach these targets via connectors, SCIM, or LDAP, depending on configuration.

Action Type

The operation the rule performs, such as create, update, enable, disable, or deprovision an account, or assign and remove entitlements. Deprovisioning actions on leaver events are a common component.

Assignment Model Basis

The access control model the rule leverages, for example RBAC role assignments driven by role membership, or ABAC-style logic driven directly by attributes. The rule expresses which model determines the resulting access rather than being tied to one universally.

Approval and Governance Hooks

Optional linkage to approval workflows, exception handling, or segregation-of-duties checks before the provisioning action executes. These situate the rule within IGA lifecycle governance rather than runtime enforcement.

Common questions

Answers to the questions practitioners most commonly ask about Provisioning Rule.

Is a provisioning rule the same as an access control policy that enforces permissions at runtime?

No. A provisioning rule is an identity governance and administration (IGA) construct that determines how accounts and entitlements are created, updated, or removed during the identity lifecycle. It operates during provisioning events rather than at the moment of an access request. Runtime enforcement is handled separately by components such as a policy decision point (PDP) and policy enforcement point (PEP). Conflating the two blurs lifecycle management with real-time access enforcement, which typically remain distinct concerns in most deployments.

Does a provisioning rule authenticate a user or decide who they are?

No. Provisioning rules do not perform authentication or identification of a principal at access time. They act on identity data, often attributes or role assignments, to grant or revoke accounts and entitlements as part of administration. Verifying who a principal is (authentication) and determining what that principal may do at request time (authorization) are separate steps handled by other parts of the identity architecture, not by provisioning logic.

How do attribute-based provisioning rules typically differ from role-based ones?

In role-based provisioning, entitlements are typically granted based on a user's assigned role, aligning with an RBAC model for the resulting access. In attribute-based provisioning, rules evaluate identity attributes such as department, location, or job code to decide what to provision. Depending on configuration, deployments often combine both approaches. The distinction affects how rules are authored and maintained, but neither approach is universally superior; the choice depends on the environment and governance requirements.

How do provisioning rules commonly interact with SCIM?

SCIM is a provisioning protocol used to communicate identity and entitlement changes to downstream systems. In many deployments, provisioning rules determine what should change, and SCIM operations carry those changes to target applications that support it. The rule logic and the transport mechanism are separate: the rule decides the intended state, while SCIM is one common way to express create, update, or deactivate operations against a target. Behavior varies by vendor and by how each application implements SCIM.

What role can provisioning rules play in segregation of duties (SoD) controls?

Provisioning rules can be designed to avoid granting combinations of entitlements that would violate segregation of duties, and in some deployments they are paired with SoD checks that flag or block conflicting assignments. However, SoD enforcement, access reviews, and certification are typically distinct IGA functions; a provisioning rule is one place controls may be applied, not the sole mechanism. The extent of SoD integration depends on the platform and configuration.

How are deprovisioning conditions usually handled within provisioning rules?

Provisioning rules often cover the full lifecycle, so the same rule logic that grants access based on a role or attribute typically drives removal when that role or attribute no longer applies, such as on a role change or termination event. Depending on configuration, deprovisioning may deactivate rather than delete accounts, and timing may depend on triggering events from an authoritative source. The exact behavior varies by vendor and deployment, so the removal path should be validated as carefully as the grant path.

Common misconceptions

A provisioning rule authenticates users or controls access at runtime.

Provisioning rules are an identity governance and administration (IGA) lifecycle concern that create, update, or remove accounts and entitlements. They do not authenticate principals or make real-time access decisions; runtime enforcement is handled separately by components such as a PDP and PEP validating tokens or evaluating policy at access time.

Provisioning rules and role definitions are the same thing.

A provisioning rule expresses when and how access is granted or removed and can operate on RBAC role assignments, but it can also apply access based on attributes (an ABAC-style approach) without a defined role. The rule is the automation logic; the role, if used, is one possible basis for what the rule assigns.

Once a provisioning rule grants access, ongoing correctness is guaranteed.

Rules automate grants and revocations at defined triggers, but drift, orphaned accounts, and stale entitlements can still occur depending on source data quality and configuration. Periodic access reviews and certification remain necessary IGA controls alongside automated provisioning.

Best practices

Drive provisioning rules from an authoritative source of identity data (such as an HR system) so that joiner, mover, and leaver triggers reflect accurate, current attribute values.

Pair automated provisioning with segregation-of-duties checks and, where risk warrants, approval workflows before high-privilege entitlements are granted.

Ensure leaver and mover events reliably trigger deprovisioning or entitlement removal to reduce orphaned accounts and access creep.

Choose the assignment basis deliberately per rule (for example RBAC role membership versus attribute-driven ABAC logic) rather than defaulting to one model for all cases, and document the rationale.

Complement rules with periodic access reviews and certification campaigns, since automated provisioning does not by itself guarantee ongoing entitlement correctness.

Test rule matching criteria against representative identity populations before enabling them in production to avoid unintended over- or under-provisioning, recognizing behavior varies by connector and target system configuration.