FAQs: Triggers

Scheduled triggers run at the configured interval, for example, every hour, but they do not execute at an exact time. Instead, they run within a flexible window around the scheduled time. The variable window is of up to five minutes after your configured time. This flexible execution window ensures that the workflow maintains the correct spacing between runs.

For example, a trigger consistently executes at one minute and 30 seconds after the scheduled time. For an hourly schedule, the workflow execution is at 1:01:30, 2:01:30, 3:01:30, and so on. Another trigger consistently executes at two minutes and 45 seconds after the scheduled time for a two-hour schedule, the workflow execution is at 12:02:45, 2:02:45, 4:02:45, and so on. The offset can differ between triggers, but for any individual trigger, the offset remains consistent for as long as the trigger exists.

Also, a trigger can run a maximum of two times per hour. The UI and API prevent configuring more than two-minute values within a single hour.

For more information, see Create a scheduled trigger.

Behavior

Scheduled triggers automatically invoke a workflow at configured time intervals. When you create a scheduled trigger, you define the schedule, for example, using a cron expression, and the workflow runs according to that schedule without requiring an external event. Scheduled triggers execute solely based on a defined schedule and do not depend on event-based conditions.

Scheduled triggers do not support test mode because they are time-based rather than event-driven and cannot be manually executed. To validate a scheduled trigger, you must enable it and allow it to run according to its configured schedule.

Limits

Scheduled triggers are subject to the following limits:

• A scheduled trigger can be invoked at most two times per hour.
• Workflow invocation limits are shared between scheduled triggers and event triggers.

Workflow executions initiated by scheduled triggers are included in the same limits as those workflows initiated by event-based triggers. The shared workflow invocation limits are:

• event.orchestration.workflow.invocations.per.hour
• event.orchestration.workflow.invocations.per.minute

If the combined number of workflow invocations from both scheduled and event triggers exceeds these limits, additional invocations are throttled according to the configured rate limits.

For more information, see About triggers and Create a scheduled trigger.

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.