FAQs: Triggers

The variable maximum size is 32000 characters and any variable larger than this size can cause the workflow target to fail.

For more information, see Overview of triggers.

The most common reason for a trigger to get invoked multiple times is that its match criteria apply to multiple, similar events. For example, if a trigger is configured to run when an interaction’s Archive attribute is set to true, it will get invoked when the attribute is first set to true and again whenever any other attributes on the interaction change, as long as Archive remains true.

For more information, see Overview of triggers.

The workflow must be able to handle the following scenarios:

• Being triggered more than once for the same event

• Being triggered multiple times for similar events

• Being triggered out of order

• Being executed multiple times in parallel for the same or related events

For more information, see Overview of triggers.

Triggers typically execute in the same general order as events occur, but this order is not guaranteed. Multiple related events can initiate workflows simultaneously or in varying sequences.

For more information, see Overview of triggers.

Yes, attributes used in Architect workflows are case-sensitive. When you reference an attribute in an Architect workflow, use the exact letter case as it appears in the event schema of the trigger that you want to create. 

If you use incorrect capitalization for an attribute, the workflow may not function as expected. The condition may not evaluate correctly, leading to unexpected results or errors.

For more information, see Overview of triggers.

No. Even with a TTL in place, a workflow can still start after the specified time. This issue can happen if delays occur in the system’s event processing. However, TTLs reduces the likelihood of outdated or irrelevant workflows being triggered.

For more information, see Overview of triggers.

Most workflows start immediately after the event or after the set configured delay. However, system load or failure conditions may significantly delay the start of the workflow. To avoid processing outdated triggers, you can set Time to Live (TTL) for triggers.

For more information, see Timing configuration and Overview of triggers.

When you configure variables in the workflow, set them as input if they match the name of any of the event schema properties.

For example, assume that you have a workflow with a variable named Flow.priority and the variable is not used as an input. The topic v2.taskmanagement.workitems.{id} contains priority as a property and is sent as part of the event schema. In this instance, a conflict occurs and the workflow is not triggered. To resolve this issue, either use the Flow.priority variable as an input or rename Flow.priority so that it does not match the properties names of the event schema.

For more information, see Overview of triggers.