Attribute-driven rules
Base entitlement on the data you already maintain — department, job code, location, employment type.
Access that follows the role, automatically
Access granted and revoked automatically as attributes and group membership change.
Most access is predictable: a role, a department and a location largely determine what someone needs. Policy-based access encodes that, so the baseline is granted automatically when an identity qualifies and removed when it no longer does — leaving requests and approvals for the genuine exceptions.
How Birthright & Policy-Based Access works
The mechanics behind the capability — what the platform does, and where it does it.
Granted and revoked
The policy works in both directions, so qualifying grants access and ceasing to qualify removes it.
Group membership as policy
Membership changes flow through to the access that membership implies, without a separate provisioning step.
Exceptions stay visible
Anything outside the baseline is a request with an approver attached, which makes the exceptions easy to review.
What it changes
Who feels the difference once Birthright & Policy-Based Access is in place, and how.
Identity teams
Less request volume
Automating the predictable majority leaves people to spend approval effort on the cases that deserve thought.
End users
Nothing to ask for on day one
New joiners start with their baseline in place rather than discovering gaps through failure.
Security
Creep reverses itself
Because the policy removes as well as grants, access tracks the current role instead of the accumulated history.
Governance
Consistent by construction
Two people in the same role get the same access, which is difficult to guarantee when each is provisioned by hand.
See Birthright & Policy-Based Access in context
It works because the other capabilities share the same identity fabric. The quickest way to judge that is to watch it run against your own use cases.