Skip to main content

Table of Contents

Securing an activity


Only available versions of this content are shown in the dropdown

You can better protect your application by limiting how an activity can be run and who may run it by configuring activity-specific access control.

In most cases, the standard Authentication in Pega Platform is sufficient to secure your application.

To alter the Activity-specific access control settings, use the Restrict access section of the Security tab, as shown in the following figure.

The Security tab of an activity
The Security tab of an activity

Three security fields are available in the Restrict access section:

  • Allow invocation from browser
  • Require authentication to run
  • Privileges (Privilege Class and Privilege Name)

Allow invocation from browser

Select the Allow invocation from browser check box when your activity meets one or more of the following criteria:

  • You need to be able to call this activity directly from JavaScript code in a non-autogenerated Section or non-autogenerated Control or Text File rule.
  • You need to be able to call this activity from a URL Mappings rule.
  • You need to use the deprecated List Views or Summary Views and you need to call an Activity in the Content field. To access these deprecated views:
    • In the panel of Dev Studio, click Record Deprecated: Summary view Format tab . Then, right-click Smart info settings, and then click the Content field.
    • In the panel of Dev Studio, click Record Deprecated: Summary view Format tab . Then, right-click Smart info settings, and then click the Content field.
Allow invocation from browser is not selected by default. If you select Allow invocation from browser check box, you must add a privilege to the activity.

For more information, see Setting a privilege to secure an activity.

One use case where you should not select the Allow invocation from browser check box is when you are configuring an external system to call this activity by URL. Instead, create a Service REST rule.

Beginning with Pega Platform 7.1.5, there is no longer a requirement to select the Allow invocation from browser check box for activities called by Service rules.

Require authentication to run

Require authentication to run is selected by default. In most cases, do not change this selection.

Clear the Require authentication to run check box to allow guest users to run this activity if they meet other security and access criteria. Guest users — unauthenticated requestors — typically have access to rules in the RuleSets in the PRPC:Unauthenticated access group. In many instances, clients overwrite this with their own unauthenticated authentication group. Therefore, your unauthenticated access group might have another name, similar to <application name>:Unauthenticated.

A session remains unauthenticated until the user signs in by using credentials, unless you are using an anonymous authentication service. For more information, see:

If you clear the Require authentication to run check box and select Allow invocation from browser, any person with access to your server can execute this activity. The default Authorization model stops unauthenticated users from having read and write access, so it is important to consider if your activities do something other than read and write.

Privileges: Privilege Name and Privilege Class

Privilege inheritance simplifies the process of defining privileges and access settings that are relevant in multiple classes.

Use privileges to differentiate the capabilities of different groups of users within your application. The privilege form defines only the existence (name and Applies To class) of a new privilege. It contains no other information and conveys no capabilities by itself.

Privileges has two fields that you can enter information into, the Privilege Name field and Privilege Class field.

A privilege is an application-specific access control element associated with a class and access role. A privilege rule only names a privilege; it does not convey the privilege to anyone. A privilege has two parts: the privilege class and the privilege name.

To have access to a privilege, a requestor session must "hold," in the access role list, at least one of the access roles that grant access to the privilege. The association between access roles and privileges is defined by instances of the Rule-Access-Role-Obj rule type.

Using privilege rules in an application is optional, but they can offer finer control over access than using access roles alone.

The Privilege Class field contains the auto-generated rule classes that are associated with the privilege.

The Privilege Name field contains the auto-generated list of privilege names.

Standard privileges

The following tables list the most common end-user and administrative privileges.

Standard end-user privileges are shown in the following table.

Privilege Privilege class Role names Comments
AllFlows @baseclass




Use this privilege during case processing. You would not normally use this privilege because most users already have it.

If, however, you created an Access Group and Role only used for reporting purposes, users with that access group should not do any flow processing.

You can add AllFlows to your activities to ensure that reporting users cannot run those activities.

UpdateLimitedForm @baseclass PegaRULES:WorkMgr4 Use this privilege for rules visible for non-Dev Studio users. Rule delegation uses this privilege.
pxViewLimitedForm @baseclass PegaRULES:ViewerCollaboratorVarious DecisionManager Roles Use this for read-only rule forms, not in Dev Studio.
Perform Work-



Restricts the ability to take action on an assignment. This privilege allows a user to perform an assignment on another individual's list (including workbaskets). Without this privilege, you can take action only on cases assigned to you.
WorkUpdate Work-



WorkReopen Work-



PerformBulk Work-



AccessAuditTrail Work-




Standard administrative privileges are shown in the following table.

Privilege Privilege class Role names Comments
OpenDeveloperForm @baseclass PegaRULES:SysAdm4 Restricts anything related to rule form usage in Dev Studio. This is the most generic Dev Studio privilege. It is often used with UpdateLimitedForm and pxViewLimitedForm privileges. Rule delegation can also use this privilege.
clipboardViewer @baseclass PegaRULES:SysAdm4 Allows the user to see details in memory data called clipboard pages.
ActionEditAttachment Work- PegaRULES:SysAdm4 Runs EditAttachment or ActionEditAttachment flow actions.
ReviewPolicyOverrides Work- PegaRULES:SysAdm4 Performs assignments on a suspended work object.
PerformanceTools Code-Pega- PegaRULES:SysAdm4 Allows administrators to do specific expensive performance-related analysis. By default, this privilege is not available in a production environment.

Using privileges to control access

Most access control is granted through authorization, which controls many common use cases around creating, updating, and deleting cases and data. However, when using privileges, consider the following two areas:

When to use a privilege

In some cases, you must add a privilege to an activity to keep your application secure, for example:

  • If an activity performs a task that only specific access groups or access roles should perform.
    • For example, a bulk processing activity for administrators should have a privilege so that users cannot run the activity.
  • When Allow invocation from browser is selected, a user must have a privilege.
  1. Setting a privilege to secure an activity
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