Error reference

This page describes some of the common error categories that may be encountered when using the Automate application.

Evaluation errors

An automation may fail to evaluate due to problems with the underlying data. Automations are automatically retried, but some errors may require manual intervention. For example, if the object type being monitored is deleted, automations using that type will fail to evaluate.

Automation out of sync

Automations may use a reference to a saved exploration to define the input. This reference is not dynamic, but instead is stored according to the exploration as it exists when the automation is saved. If the exploration changes, the automation will continue to evaluate using the exploration's old state unless the automation is updated. In this case, a warning banner is displayed on the automation:

Notification effect errors

After a successful condition evaluation, notifications may fail to send. If this occurs, the history event will show a tag indicating that notifications for that event were not sent to subscribers, along with additional details such as an error identifier, the error message, and the object or objects that triggered the failure.

Action effect errors

After a successful condition evaluation, Action effects may fail to execute. This failure could happen for a variety of reasons, including:

• Changes to the Action logic that make it incompatible with the saved input configuration on the automation;
• The submission criteria for the Action are not met; or
• The function backing the action has a runtime execution failure.

If an Action effect execution failure occurs, the history event timeline will show a tag indicating that one or more Actions failed to execute for that event, along with relevant error details.

Note that when per-object execution is enabled, the object identifier surfaced in the error details as the cause of the error represents the object associated with the first request that caused the failure, and there may be more hidden failures that are not propagated.

Cycle detection

Consider a set of automations defined as:

• Automation A: Monitors an object set of all red cars. When a new red car is added to the ontology, an action will be triggered to change its color to blue.
• Automation B: Monitors an object set of all blue cars. When a new blue car is added to the ontology, an action will be triggered to change its color to red.

Such a sequence of automations would cause an unintentional infinite loop, or cycle. A framework has been implemented to automatically detect and disable live automations that cause cycles.

For certain automations, cycle detection may be undesirable. Up to 50 cycles can be allowed by overriding the configuration in Settings.

Permissions

Automation evaluation uses the permissions of the owner or recipients. This is to ensure that condition evaluation and any subsequent Action or notification effects will always reflect data that the user may access at the time the automation is evaluated. If a user is missing permission to view object type(s), saved exploration(s), and/or the automation, they may see a permission-related error message instead of successful evaluation. We strongly recommend storing automations and their related resources in shared Projects.