Create Declare Trigger rules to cause an activity to run when instances of a specific class are created, updated, or deleted in the database. This implements a form of forward chaining.
The primary page passed to Trigger activities is the top-level page corresponding to the Applies To class of the rule.
An activity of type
may alter properties, call functions and
execute other rules, but do not perform database commits. Take care in declarative
processing not to specify processing that produces infinite looping.
When you choose
In Background on Copy
in the Execute field, the triggered
activity runs in a child requestor in parallel to the current requestor. This means that:
- The triggered activity does not appear in your Tracer session
- The triggered activity cannot access clipboard pages other than the primary page
- Within the triggered activity, the primary page has no name
During execution of a Declare Trigger rule, the page on which the rule operates
temporarily becomes the primary page. The page keyword
results of the
PublicAPI method reflect this
When the Declare Trigger rule execution completes, the primary page of the calling activity resumes as primary.
Testing and debugging
Using the Tracer, you can watch the evaluation of a Declare Trigger rule if the Execute
field value is
- Start the Tracer and select a requestor session.
- Click Settings and check the Declare Trigger box in the Event Types to Trace section.
- Select the RuleSet that contains the rule to be traced.
History change auditing
Declare Trigger rules can automatically update the history of a work item, rule, or data object when certain properties change.
For work item change tracking, use the Field Auditing gadget, on the Work History landing page.
For data or rule tracking, see the Pega Community article How to audit field-level changes to security rule and data instances.
You can view the generated Java code of a rule by clicking. You can use this code to debug your application or to examine how rules are implemented.