Workflow objects

An action or a series of actions that are triggered when a user performs an operation and are conditionally interpreted. The interpretation occurs on the AR System client in the current form window, and run with the permission of the user. For example, you might define an active link that displays a list of all problems reported for the current workstation whenever a user presses Enter in the Workstation field. 

When an active link is executed, it can trigger varying actions as the result of a single user action. When you design an active link, you specify the conditions under which the active link executes, and further conditions to determine which action it will take. For example, if the user is a member of the Human Resources department, an active link could attach one menu to the Short Description field, or else attach a different menu if the user is a member of the Shipping department.

Active links can be grouped into execution groupings called active link guides that allow procedural processing. 

Active links cannot be run by an API program.

Used to implement and enforce your organization's business rules. A filter tests every request transaction to see if certain conditions are met, and then responds to the conditions by taking specific actions. For example, a filter can notify support staff members when they are assigned responsibility for a new request. 

Filters can act on virtually any condition that arises in a request. For example, filters can restrict how users create or modify a request. As another example, a filter can check for conditions in requests that are submitted by a network management system for a device that the system is monitoring. Then, the filter can automatically call a program to control that device. 

Filters execute on the AR System server and run with administrator permissions. This means that filters can access any field in the AR System server database, even if the field is not available to the user (no view or change access). 

Filters can be grouped into filter guides to control the order of processing. For more information, see Defining-guides-and-guide-actions.

Causes a condition to be checked on a regular basis and, depending on whether and how the condition is met, performs one or more actions. For example, an escalation can set the priority of a request to Urgent if the request is not closed within 24 hours, or send a page to a support staff member if a critical request has not been addressed in one hour. 

Escalations execute on the AR System server and run with administrator permissions. Unlike filters, which run in response to a specific operation, escalations run at a specific time or after a defined time interval. Also, when they run, escalations find and act on all requests that meet a qualification, while filters act on the current request if it meets a qualification. 

At the time specified in the escalation, AR System server searches for requests that match the escalation qualification and performs the specified escalation actions on those requests that match. 

Escalations can be assigned to pools so the escalations from each pool run in parallel on separate threads within the escalation queue.

If you assign an escalation to a pool that has no thread configured, the escalation is run by the first thread.

All escalations in a particular pool run on the same thread, so the execution of escalations within a pool is serialized. Escalations run in the order of their firing times, but an escalation is delayed if an escalation from the same pool is currently running. If two or more escalations have dependencies and must not run at the same time, put them into the same pool to make sure they run in sequence.

AR System does not support escalations if you have a read-only database. For more information on using a read-only database, see Setting-database-options.