Difference between revisions of "Rules and Rule Sets"
imported>Aeric m (Text replace - 'Case Dynamics' to '{{HelpDesk}}') |
imported>Aeric Β |
||
(59 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
==About Rules and Rule Sets== | |||
A ''Rule'' is an if-then statement that says, '''if''' one or more conditions are met, '''then''' take one or more specified actions. A ''Rule Set'' is a collection of such rules.Β Β | A ''Rule'' is an if-then statement that says, '''if''' one or more conditions are met, '''then''' take one or more specified actions. A ''Rule Set'' is a collection of such rules.Β Β | ||
The {{EnterpriseBrand}} interface makes it easy to define rules by selecting fields and specifying matching criteria. When satisfied, the criteria causes any and all actions associated with the Rule to be carried out. | |||
The {{ | {{:Common:HistoryRulesDoNotExecute}} | ||
Β | ===Types of Rules=== | ||
Β | |||
Β | |||
Β | |||
: | |||
Β | |||
Β | |||
Β | |||
Β | |||
Β | |||
Β | |||
Rules can be defined in named [[Rule Sets]], or they can be part of an unnamed set (a "Rule List") defined for [[Event Rules]], [[Timer Rules]], and [[Scheduled Rules]]. | |||
===Rule Chaining=== | |||
One of the actions a Rule can take is to execute another Rule Set, which causes the Rules to ''chain''. When Rules chain, the processing of the current Rule Set stops until the chained Rule Set finishes. The processing of the original Rule Set then resumes where it left off. (Chaining can go to arbitrary depth.) | |||
=== | ===Rule Processing=== | ||
Rules exist in sets. When you create a Rule Set, you give it a name, which lets you invoke it from other rules. But the rules that are triggered for the Case Created event, for example, also constitute a set. Β | |||
Each set of rules is processed in two stages: | |||
# The conditions for each rule are examined, to see which ones have been satisfied.<br>All rules with valid conditions are ''enabled''. | |||
# The enabled rules then execute in the order in which they appear in the set. | |||
It's worth understanding that sequence because, when a rule action updates a field in a record, that value is ''not'' used when testing the conditions for subsequent rules in the set--because those conditions were already tested before the first rule executed. | |||
In other words, you can't set a value in one rule, and then test for that value in a subsequent rule in the same set. However, the new value is available in any ''actions'' taken by subsequent rules, and it is available in any rule sets that are invoked by one of those actions--so a value updated in one set of rules can be tested in a ''different'' rule set. | |||
In | |||
: | ==Working with Rules== | ||
:: | {{:Rules}} | ||
<noinclude> | |||
[[Category:Case Management]] | |||
[[Category:Object Aspects]] | |||
[[Category:Automating Case Flow]] | |||
[[Category:Design]] | |||
</noinclude> |
Latest revision as of 22:42, 17 August 2015
About Rules and Rule Sets
A Rule is an if-then statement that says, if one or more conditions are met, then take one or more specified actions. A Rule Set is a collection of such rules.
The AgileApps Cloud platform interface makes it easy to define rules by selecting fields and specifying matching criteria. When satisfied, the criteria causes any and all actions associated with the Rule to be carried out.
Note:
Although it is possible to define Rules on the History object, events are not propogated for the History object, so the Rules are not triggered.
Types of Rules
Rules can be defined in named Rule Sets, or they can be part of an unnamed set (a "Rule List") defined for Event Rules, Timer Rules, and Scheduled Rules.
Rule Chaining
One of the actions a Rule can take is to execute another Rule Set, which causes the Rules to chain. When Rules chain, the processing of the current Rule Set stops until the chained Rule Set finishes. The processing of the original Rule Set then resumes where it left off. (Chaining can go to arbitrary depth.)
Rule Processing
Rules exist in sets. When you create a Rule Set, you give it a name, which lets you invoke it from other rules. But the rules that are triggered for the Case Created event, for example, also constitute a set.
Each set of rules is processed in two stages:
- The conditions for each rule are examined, to see which ones have been satisfied.
All rules with valid conditions are enabled. - The enabled rules then execute in the order in which they appear in the set.
It's worth understanding that sequence because, when a rule action updates a field in a record, that value is not used when testing the conditions for subsequent rules in the set--because those conditions were already tested before the first rule executed.
In other words, you can't set a value in one rule, and then test for that value in a subsequent rule in the same set. However, the new value is available in any actions taken by subsequent rules, and it is available in any rule sets that are invoked by one of those actions--so a value updated in one set of rules can be tested in a different rule set.
Working with Rules
Creating or Modifying a Rule
You can add Rules when specifying Event Rules, Timer Rules, Scheduled Rules, or when creating a Rule Set.
- Learn more: Rules and Rule Sets
Basic Information
- Name - The name of the Rule, displayed in the ServiceDesk interface.
- Enabled - Whether or not the Rule is enabled. (Disable the rule to deactivate it without deleting it.)
- Description - A descriptive summary
Execution Criteria
Unconditionally (Always)
- Use this option for actions that should occur whenever the Rule is invoked.
(This option is not present for Scheduled Rules.)When Specified Conditions are True
- Use this option to specify a series of conditions that determine whether the Rule's actions are carried out.
- All of the Conditions are met - Every condition in this category must be satisfied
- Any of the Conditions are met - At least one of the conditions in this category must be satisfied.
- For example, here are tests for a variety of conditions, to show the kinds of possibilities that exist:
- Learn more: Defining Conditions
When Specified Expression is True
- More complex conditions can be specified using the Formula Builder. For example, here is an expression that checks for either P1 or P2 priority on a new case:
- Expressions also allow the use of the platform's built-in Formula Functions. For example, this expression returns true only of a specific field has changed, and if had some specific value before it changed:
- AND( ISCHANGED('some_field'),
- IF(PRIORVALUE(some_field) == 'some_value', true, false) )
- Learn more:
- ISCHANGED function
- PRIORVALUE function
Actions to Perform
- Selecting actions
- Select the action to perform when Rule conditions are satisfied.
(Possible actions are listed below) - As with conditions, additional options appear, depending on the action you select.
- Click [Add More] to specify additional actions.
- Available Actions
Set Priority
- This option appears for Cases. It allows the priority to be changed--for example from "P2" to "P1"
- Trigger Rules - This option enables the firing of Case-update rules.
Set Status
- This option appears for Cases. It allows the status to be changed--for example, to Closed
- Trigger Rules - This option enables the firing of Case-update rules.
Add Record
- Select an object to add a record to, and specify field values for the record:
- Do Not Trigger Rules - By default, Rules are enabled when adding a record. This option disables them.
- Use the Field Chooser to select object fields.
- For each field, use the Formula Builder to specify the field value.
Update Record
- Modify data in the current record
- Trigger Rules - This option enables the firing of record-updated rules.
- Use the Field Chooser to select fields to modify -- including fields in a record targeted by a Lookup field in the current record, or fields targeted by Lookups in those records, and so on, as shown here:
- For each field, use the Formula Builder to specify the field value.
Add Note
- Add a note to the current record.
- Enter text for the note in the text area
- Use the field selector to add record variables
- Example: This note is for $user.full_name.
Assign to User
- Determine the new owner of the record. The options are:
- Logged-In User - The user who is running the application when the rule is triggered. (Not the designer who created the rule.)
- Note: This value is undefined for a record that is created or updated by a Process.
- Pick a User - A lookup field appears. Use it to select a specific user.
- Select a User Field - The [Choose User] button appears. Use it to select a Lookup field that targets the Users object.
- That field can be defined in the current record or in the record the Lookup points to, up to 5 levels deep.
- For example: Owner > Reports To > Reports To_id assigns the record to the current owner's second-level manager.
- Use an expression - Use a combination of fields and expression operators to choose the user to assign to.
- This feature is commonly used to specify if-then logic, or to find a User field defined in an associated record.
- For example, for Case with a Lookup to an OrderItem, the Rule might choose OrderItem > Order > Customer > Agent in Charge_id
- That setting would assign the case to the "troubleshooter" who handles issues raised by that customer.
Assign to Team
- Determine the group the record goes to, so members of the group can claim it.
Send Email
- Send a message, optionally using an Email Template
- Note:
Do not choose a template that includes a JSP page as an attachment.
Learn more: JSP Attachment DeprecationStart Process
- Automatically initiate a Process.
Note: One you start a process, you cannot stop it half way and resume it from that point at a later time. A process always restarts from the first step.
Invoke IS Service
Select this to communicate with Integration Server (IS). It allows you to fetch a list of all the IS packages that you created in the Software AG Designer for the runtime application. You can view all the services that are part of each IS package. Designer is a separate application and is available to you as part of the Integration Server package. For more information about this action, see Invoking Integration Server Services from Business Rules.
Create Task
- Create a new task and specify its settings:
- Owner - Who should perform the task.
- Subject - Title of the task.
- Duration - How long it is expected to take.
- Do not notify - A notification is sent automatically, unless this box is checked.
- Description - Description of the activity to perform.
Use the Record Variable selector to add references to record fields, dates, times, user data, and company information.Change Process Status
- Set the status of the process.
- Change process shows the following statuses:
- Enable: You can enable the process instance, only if the current process status is DISABLED.
- Disable: You can disable the process instance, only if the current process status is READY. You cannot disable a process which is currently in progress state.
- Stop: You can stop the process instance, only if the current process status is STARTED.
Execute Rule Set
- Chain to a different Rule Set, and execute those Rules. Come back to this set when done, and resume processing with the next Rule.
Invoke Method
- Learn more: Invoke a method in a Java Class
Execute Web Service
- Select a Web Service, and specify the mappings for its input and output parameters.
Return Process Decision Value
- This action can be taken by a Rule in a Rule Set whose return type is "Process Decision Value".
- The specified value becomes available for testing in a Process Decision Switch.
- When this action is taken, rule processing stops.
- Learn more: Rule Set Properties
Return Step Owner
- This action can be taken by a Rule in a Rule Set whose return type is "Step Owner".
- Select the User or Role, who will be assigned the task associated with a Process step.
- When this action is taken, rule processing stops.
- Learn more: Rule Set Properties