Skip to main content
Verify the version tags to ensure you are consuming the intended content or, complete the latest version.

Event processing with action sets

A user interface (UI) can include controls that allow users to perform certain actions before submitting a form to provide a more interactive user experience.

The event-action model

Actionable controls are based on an event-action model, which establishes a cause-and-effect relationship for a control such as a check box or a button. The event is a trigger caused by user activity, such as a button click or field entry. The action is a response by the application, such as creating a case or displaying information about a field to guide user input.

For example, an online retailer wants to allow customers to use the shipping address for an order as the billing address for payment. The form for entering the billing address provides users with a check box. When the user selects the check box, the application copies the shipping address information to the billing address fields and disables any editing of the billing address fields. When the user clears the check box, the application removes any entries in the billing address fields and allows the user to enter an address.

In the center of the following image, slide the vertical line to view how the display of the address form changes when the user clicks and clears the check box.

The following table lists examples of event-action pairs.

Event Action
Click a control such as a button, link, or icon Open a new window
Double-click a row in the grid Allow editing of the contents of the row
Press the Enter key on the keyboard Display a menu
Select a value from a list of states or provinces Update the list of office locations
Enter a value in the Quantity field Verify that inventory is sufficient to fulfill the order

Action sets

In a Pega Platform™ application, you use an action set to configure an actionable control. An action set consists of one or more events and one or more actions. Optionally, you can add conditions to each action so that the action occurs only when the conditions are met.

Caution: Both events and actions can be shared between action sets. As a result, one or more events can trigger an action, and an event can trigger more than one set of actions. When configuring more than one action set, avoid configuring conflicting behavior for an event.

In the following image, click the + icons to explore how an action set can populate the billing address fields on a form when submitting an order to an online retailer.

Check your knowledge with the following interaction:

Action set optimization

When configuring an action set, consider how the user experience and data are affected by refresh actions and calls to the server. For example, the user flow is interrupted when the user has to wait for a screen to refresh or return to a previous screen manually.

Refresh a section when:

  • Property values are updated on the server, and the UI needs to reflect the new values.
  • An action that causes a change to more than one property that occurs only on the client, such as deleting a row, must be submitted.
  • Parts of the UI require removal from the Document Object Model (DOM) because of other input.

Do not refresh a section when:

  • You need to submit user input. Instead, use a post value action.
  • You need to call a data transform or an activity after a user action.
  • You need to recalculate visibility, enabled/disabled state, or read-only state. Select the Evaluate on client check box next to the expression field.

Use a Refresh When action whenever possible to declare dependencies. To maintain accurate data, use a Refresh When action for read-only references that need to remain synchronized with data on the server. For example, refresh a hotel details section that needs to be updated only when the hotel location changes.

When a Refresh When is not possible, use a Refresh Other Section action, which is a targeted refresh. For example, if you have editable references that are updated based on other input or based on untrackable inputs, such as button clicks, use the Refresh Other Section.

Consolidating actions in the action set

Each action in the action set generates at least one HTTP request to the server and runs in the sequential order of configuration. To optimize the actions and reduce the number of HTTP requests to the server, use the following best practices:

  • If the pre-activity or pre-data transform runs in the same context as the section refresh, configure them in the refresh section action.
  • Modify the content of your pre-activity if needed when running it in the context of the refresh section.
  • Use wrapper activity or wrapper data transform to consolidate all the actions.

In the center of the following image, slide the vertical line to view how the actions in an action set can be consolidated into a wrapper activity.

Differentiating between post and refresh section actions

By default, a Refresh section action sends all the pending changes applied to a form back to the server. There is no need to use a Post value action before a refresh section action, such as a Refresh This Section action.

A Post value action will update the server and force all the Refresh When conditions to reevaluate. One Post value action can affect several sections using when conditions. Use one Post value action instead of using a Refresh section for each one of these sections. Using a Post value action to refresh all the sections also avoids hardcoding the section name in the action set when using a Refresh Other section.

For example, in a vehicle purchase application, a user enters their Customer ID to view additional accessories. When the Customer ID value changes, the conditions on two sections are evaluated against stored customer data, such as Elite membership status, active membership length, and total vehicle purchases. The Exclusive lifestyle accessories section refreshes only when a valid Customer ID is associated with a user who has purchased three or more vehicles. The Elite car accessories section refreshes only when a valid Customer ID belongs to a user who has been an active Elite member for more than 10 years. 

In the center of the following image, slide the vertical line to compare the view displayed for an invalid user with the view displayed for an Elite member:

Note: The Run activity, Run data transform, and Set value actions do not send the changes made to a form back to the server. If you want to pass some of the changes that are made on a form to an activity or a data transform, you need to pass them as parameters.

This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

50% found this content useful

Want to help us improve this content?

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

Pega Academy 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