Develop > Process Designer Tailoring Best Practices > Best practices for configuring rule sets > Perform automatic operations with Run Action rules > Configure Run Action rules on related records

Configure Run Action rules on related records

You can configure the Run Action rules to enable Service Manager to perform automatic operations on related records. The relationship of the related records is usually maintained by the Related Records functionality.

For example, when an incident is resolved, you might want to copy the incident resolution to the related interaction from which the incident is escalated. In this case, you can configure the Run Action rules with these steps:

  1. Define a rule set on the source table
  2. Define a rule set on the target table
  3. Configure the rule set on the source table into an appropriate workflow

Define a rule set on the source table

To copy the incident resolution, you can define a rule set on the source table “probsummary” that stores incident records. The rule set definition form is as follows:

In addition to the above configuration, you also need to perform the following tasks:

  • Select Related Records for the "Run Action on" field
  • Select Escalate From Interaction for the "Relation Type" field. This means the target related record is the interaction from which the current incident is escalated.
  • Select sd.copyIncidentSolution for the "Run Rule Set" field. This rule set is executed against the related interaction.
  • Select Save for the "Action after Rule Set" field. The rule set is saved for the related interaction.
Note: You can select "Do nothing", "save" or one of the back end transitions for this field.
  • The back end transition list is retrieved from all the workflows of the current related record file based on your selected relation type. At run time, if some of the workflows do not have your selected back end transition, the corresponding transition is not run.

    For example, suppose you have a Change file "cm3r" and it meets the following conditions:

    • Relation type: You have selected "Caused Changes" as the relation type.
    • Workflows: Based on the selected relation type, there are two workflows for the Change file: "Normal Change" and "Standard Change".
    • Back end transitions: The "Normal Change" workflow has the back end transition "event.close", whereas the "Standard Change" workflow does not.

    In this case, if you select the action "Backend Transition: event.close", and if at run time there are two related caused changes: One for "Normal Change" and the other for "Standard Change", the back end transition is only run on the "Normal Change" workflow, not on the "Standard Change" workflow.

  • You are suggested to use the same back end transition name in different workflows if these backend transitions follow the same business logic.
  • While a back end transition is selected from the list, the interface is updated to indicate to which workflows the transition applies and to which it does not apply.

The form on which you can perform these tasks is shown below:

Define a rule set on the target table

You need to define a rule set on the target table. This rule set is used as the value of the "Run Rule Set" field when you define the rule set on the source table. In this example, you define the rule set “sd.copyIncidentSolution” on the target table “incidents” that stores the interaction records.

You need to configure a Set Field rule in this rule set to append the resolution of the incident to the resolution field of the interaction. To do this, you can use JavaScript, in which you can refer to the current source record as srcRecord and the original copy of the source record (before any changes are made by the user) as oldSrcRecord. The system only supports invoking the current rule from the Run Action rule at run time. The JavaScript of this example is as follows:

value = record.resolution.toArray().concat( ["Copy resolution from Incident " + srcRecord.number + " on " + new Date() + ":"], srcRecord.resolution.toArray());

In JavaScript, the current record and the original copy of the record are also referred as record and oldRecord. In this example, they are the current interaction record and original interaction record.

Configure the rule set on the source table into an appropriate workflow

In this example, you can configure the rule set into the After successful enter event of the Review phase of the Incident workflow. This means only after the incident record is resolved, the rule set is triggered.

Note: The Run Action rule is executed in a sequential manner, which means the configured rule sets and actions of each related record are called one after another. If one of the rule sets and actions fails, for example, one of the related record is locked by another user, the whole execution stops and returns with a failure result. If you want the system to handle the failed execution on related records caused by record locking, you can combine the Run Action rules and the Run Scheduled Action rules. For details, see Combine the Run Action rules and the Run Scheduled Action rules.