Workflow execution options

Execution options determine when workflow runs. For active links and filters, you specify what event triggers the workflow; for escalations, you specify the execution schedule for the workflow. For all workflow components, you can refine the execution option by adding a qualifying statement that tells the system which set of actions to run if the additional criteria are met and which set to run if the criteria are not met.

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 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.