Workflow execution options - Documentation for Remedy Action Request System 20.02
Active link and filter execution options
The following table lists examples of execution options for active links and filters. For a complete list, see Defining workflow execution options.
Execution options for active links and filters
Execution option | Description | Active link | Filter |
|---|---|---|---|
Button/Menu Field | Executes when a user selects the button or menu item associated with the active link. | + | |
Gain Focus | Executes when a user or a Change Field action moves the cursor to a field. | + | |
Display | Executes after a request is loaded into a form but before the request appears in the Details pane. | + | |
Hover on Field Hover on Data Hover on Label | Executes when a user hovers the mouse pointer over a field, field data, or a field label. To display tooltips, use a Hover execution option to trigger a Message action. | + | |
Lose Focus | Executes when a user or a Change Field action moves the cursor out of a field. | + | |
Menu Choice | Executes when a user chooses an item from a character menu associated with a specified field. | + | |
Modify | Executes after a user modifies an existing request but before the request is sent to the AR System server (for active links) or to the database (for filters). An active link with this execution option does not run during a Modify All operation. | + | + |
Service | Enables filters to be called by the Service action. | + | |
Submit | Executes after a user submits a new request but before the request is sent to the AR System server (for active links) or to the database (for filters). | + | + |
Table Refresh | Executes when a user updates a table's contents by loading the field, sorting, refreshing, or displaying the previous or next part (chunk) of the table. | + | |
Window Open | Executes when a user opens a form or dialog box or changes a form to a different mode. This is especially useful for establishing initial environments. It executes before any data is loaded into the window. | + |
Execution options and user actions
Some execution options depend on how a user interacts with fields on the form. For example, if the user does not click a particular button, that active link does not fire (the user "controls" whether the active link fires). Use "user-controlled" execution options to provide additional helpful information, such as a list of nearby printers.
Active links that are not under a user's control, however, fire whenever the user finishes a task. That is, if the user follows the normal steps, from opening a window through closing the window, the active links not under explicit user control always fire. (Of course, if a user does not submit or modify the request, the active links that fire on Submit or Modify do not execute.) Use execution options that are not controlled by users to ensure that consistent, complete data is maintained regardless of whether users perform certain actions. For example, to guarantee that every submitted request includes the host name, an active link could retrieve the host name of the client and copy it into a field in the form whenever a request is submitted.
Execution order of active links and filters
Active link execution options have an implicit order in relation to one another and to the interaction between the client and server. You can use this order to control when the active link runs. For example:
- If field values were required for workflow processing before a request is displayed, you would set them on Window Open. However, to set any values that you want the user to see when a request is displayed, you would use the Display execution option.
- An active link that runs on Window Open might check the user's permission to open a Modify All window and, if the user does not have permission, generate an error message, preventing the window from opening.
More than one active link or filter can run on the same execution option. In this case, you can specify the order that you want it to fire in relation to the other active links or filters. One reason to do so is that the output of one active link can affect another active link. By carefully ordering a group of active links, you can perform very complex operations.
When active links and filters are bundled into guides, execution order within the guides is ignored. Instead, workflow executes in positional order within a guide. This enables a guide procedure to run without affecting the order of workflow outside the guide.
Escalation execution options
In contrast to active links and filters, which react to events, escalations respond to the passage of time. You can trigger an escalation at a specific time, such as every Monday at 6 a.m., or at a time interval, such as eight hours after each run of the escalation.
When the specified time arrives, the server searches for requests in the database that meet the escalation's qualification. If it finds any, the server runs the escalation's primary ("if" ) actions for each matching request. If no requests meet the qualification, the server runs the escalation's alternative ("else" ) actions, if any, once. The following figure illustrates how escalations work.
How escalations work
An alternative ("else") action for the example in the figure might be to notify the manager that all requests comply with the assignment rule. This action would run only if no requests meet the escalation qualification.
An escalation does not process records on a form as per its execution order. This is because the AR System server follows the chunking approach to process the matching records.
