Performance Considerations for Automation Processes
Because Automation Processes rely on Business Object logic, be sure to optimize configurations that might impact performance. This is especially important in high-load systems that have a large number of concurrent users or a high rate of record creation and updates.
Use these general approaches to configure performance friendly Automation Processes:
- Simpler is better, in terms of performance:
- Do not reuse common, high-use One-Step™ Actions as the event that triggers Automation Processes or as the Action executed by a large number of Automation Processes.
- Simplify the Actions performed by each Automation Process.
- Minimize activation by deleting disabled or unnecessary Automation Processes.
- Constrain the number of records evaluated by each Automation Process. For example, when you use a query to limit the number of records to evaluate, configure the query so that it returns the fewest records as possible. If you use a Related child event to trigger the Automation Process, use a Relationship that will evaluate the fewest number of records.
Delete Unused Automation Processes
Disabled Automation Processes continue to generate events, but these events are not processed by the Automation Process Service. This can cause performance bottlenecks.
- An Automation Process fires when the Status field on an Incident changes from Open to Closed. The Automation Process is evaluated each time an Incident is saved and an event is sent for processing, which is ignored if the Automation Process is disabled.
- When a disabled Automation Process has an Execution Priority of High, events are generated with high priority, which means they are evaluated by the server sooner than lower priority events.
- Scheduled data imports might update thousands of records at one time, which could send a large number of events to the Automation Process Service.
To help resolve bottlenecks, consider deleting rather than disabling Automation Processes that are not needed since disabled Automation Processes continue to produce a load on the system. See Delete Automation Processes.
Avoid "Any Change" Event Types
You can configure Visual Workflow and Simple Action/Event Automation Process types to trigger when any change is made to a specific type of Business Object. In heavy load systems, this can result in a large number of events being triggered that in many cases may not be needed.
Rather than triggering Automation Processes based on any change, use a more restricted condition when possible to avoid triggering unnecessary Automation Processes.
For example, configure "any change" event types to trigger based on changes made to a specific field. For an Automation Process that notifies an owner than an incident has been assigned to someone else, set the Event Type to Field Changed, and then select the Assigned to field.
Use a Calculation to Evaluate Multiple Field Values
If you need to evaluate multiple fields to trigger an Automation Process, consider creating a new field that has a calculated value. You can then configure your Automation Process to trigger on changes to that field.
This reduces the load on the system by evaluating a single field for a specific situation.
For example, if you want an Automation Process to create tasks when either the status of an Incident changes from Pending Approval to New or the source of the Incident was not Portal, create a logical field called Ready for Tasks that has a calculated value. Then, set the Automation Process to trigger from the Ready for Tasks field.
Simplify One-Step Actions
Design One-Step Actions to be as efficient as possible. For example:
- Avoid unnecessary saves if the same Business Object is updated multiple times.
- Do not configure refreshes that occur when the One-Step Action is run.
- If your One-Step Action is designed to update a Business Object, consider setting the Update a Business Object Action for the Automation Process instead of creating an additional One-Step Action.
If you set up a One-Step Action to update a Business Object, consider setting the Update a Business Object Action for the Automation Process instead of creating an additional One-Step Action.
The Update Business Object Action cannot be used instead of refresh commands if the Business Object Association is "None" or if the step is part of a "Step through children" branch of a One-Step Action.