Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Securing an activity

Updated on June 30, 2021

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 RecordDeprecated: Summary viewFormat 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.

Note: 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.

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

Note: 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.

PrivilegePrivilege classRole namesComments




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 @baseclassPegaRULES:WorkMgr4Use this privilege for rules visible for non-Dev Studio users. Rule delegation uses this privilege.
pxViewLimitedForm@baseclassPegaRULES:ViewerCollaboratorVarious DecisionManager RolesUse this for read-only rule forms, not in Dev Studio.



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.













Standard administrative privileges are shown in the following table.

PrivilegePrivilege classRole namesComments
OpenDeveloperForm@baseclass PegaRULES:SysAdm4Restricts 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@baseclassPegaRULES:SysAdm4Allows the user to see details in memory data called clipboard pages.
ActionEditAttachmentWork-PegaRULES:SysAdm4Runs EditAttachment or ActionEditAttachment flow actions.
ReviewPolicyOverridesWork-PegaRULES:SysAdm4Performs assignments on a suspended work object.
PerformanceToolsCode-Pega-PegaRULES:SysAdm4Allows 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

    To secure an activity, determine the correct privilege, then assign that privilege to the role that is authorized to run that activity.

  • Previous topic Configuring an activity to process a JSON Web Token
  • Next topic Setting a privilege to secure an activity

Have a question? Get answers now.

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

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us