Skip to main content

Table of Contents

More About Access Deny rules


Only available versions of this content are shown in the dropdown

Learn about when access deny rules take effect and see an example.

When effective

After you save an Access Deny form, active requestor sessions on the current node that are associated with that rule are immediately updated. Requestors at other nodes in a cluster are updated when the next system pulse occurs on their node.


Assume an application includes classes named Data-Refund-Basic, Data-Refund-Silver, and Data-Refund-Gold, all derived from the Data-Refund- abstract class, and two access roles named Refund:Worker and Refund:Super.

You want both types of users to be able to work on all three classes, except that users with the Refund:Worker role may not delete Data-Refund-Gold data instances.

You can accomplish this with three rules:

Rule type Key class Access role Description
Access of Role to Object Data-Refund- Refund:Worker Grant full access to all three classes.
Access of Role to Object Data-Refund- Refund:Super Grant full access to all three classes.
Access Deny Data-Refund-Gold Refund:Worker Deny Delete access to this class for workers; no change for others.

You can achieve the same results without any Access Deny rules, by granting needed Data-Refund-Gold access capabilities one-by-one. However, using one Access Deny rule in this situation is simpler and easier to understand and maintain.

Did you find this content helpful?

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Ready to crush complexity?

Experience the benefits of Pega Community when you log in.

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us