Role-based access control decides what a user can do based on who they are. Attribute-based access control (ABAC) decides based on the data itself. When the rule depends on a value in the record, not the user’s role, ABAC is the right tool.
The Two Rules Behind ABAC
Pega gives you two rules under the Security category: Access Control Policy and Access Control Policy Condition. The policy defines what action you control and on which class or properties. The condition defines the attribute logic that decides when access is permitted.
The condition must be attribute-based. You cannot fall back to a simple when rule here, and that is by design.
Six Actions You Can Control
Four actions work on a full instance: Read, Update, Discover and Delete. Discover acts as an exceptional read. If a Read policy blocks certain records, a Discover policy on the same class can still expose a limited set of values, which is useful for reporting gadgets.
The other two actions work on individual properties. Property Read lets you mask a sensitive value in the UI while the real value stays in the database. Property Encrypt encrypts the value at rest, but it requires platform encryption or a custom encryption setup, otherwise you will hit errors.
A Practical Example
The video uses a passenger list on a flight claims case. When a booking comes through an airline broker, the customer email should never display. A Property Read policy fully masks the email field, and the condition permits access only when “booked via broker” is false.
Limitations Worth Knowing
Masking happens on the presentation side, so the clipboard and UI show masked values while the database keeps the original. Node-level data pages may not apply the mask, so test your data page scope before relying on it in production.
Watch the Full Walkthrough
The video shows the full configuration of both the masking and the instance-level Read policy on a live case.
Use role-based access when the decision depends on the user. Use attribute-based access when it depends on the data.
