Triggers

Triggers are the starting points of any workflow in Lleverage. They determine how your workflow is initiated and what form it will take when published. Triggers define the entry point for your automat

A Trigger defines what event creates work for a Workflow.

Choose it from the operation outward: first identify when the work should begin, then select the trigger type that represents that event most directly.

Choose the right starting event

Common trigger types include:

• App — a person starts the work through a published form or chat interface.

• API Call — another application explicitly starts the Workflow.

• Schedule — the work should happen at a known time or cadence.

• Integration — an event in a connected application starts the work.

• Data Table — a change to maintained structured data starts the work.

A good Trigger matches the real operational event closely. Avoid using a schedule to repeatedly search for work when a reliable event-driven trigger exists, for example.

Think about the input contract

The Trigger is also the boundary where information first enters the Workflow.

Define what downstream execution can safely assume:

• which values are required;

• which identifiers should come from an authoritative system;

• what validation is needed;

• whether duplicate events are possible;

• what should happen when expected information is missing.

A Workflow that begins with ambiguous input usually pushes that ambiguity further downstream.

User-facing App triggers

App triggers are useful when a person should deliberately initiate the work.

They can be paired with Form or Chat actions to collect information and return a result through a user-facing interface.

App URLs can also receive parameters that pre-populate context. Use this for non-sensitive identifiers or defaults such as an order reference or machine type.

Do not put passwords, API keys, secrets or other sensitive values in URL parameters. URLs may be visible in browser history, logs and copied links.

API Call triggers

Use an API Call trigger when another system should start the Workflow programmatically.

Treat the API input as an explicit contract. Define the fields and types the Workflow expects and use authentication appropriate to the deployment.

API-triggered Workflows are a good fit when an external system owns the event but Lleverage owns the operational work that follows.

Schedule triggers

Use a Schedule trigger when time itself is the meaningful starting condition, for example a daily reconciliation or weekly report.

Prefer a schedule for genuinely periodic work. If the Workflow is really waiting for a business event, an event-driven trigger usually gives faster and clearer execution.

Integration triggers

Integration triggers react to events from connected applications, such as incoming email or changes in another system.

When using them, check what the external event actually guarantees. A received email may be a reliable signal that new work exists, but it may not yet contain everything required to complete that work.

Data Table triggers

Data Table triggers start work when records are created, updated or deleted.

They are useful when a Data Table is acting as a maintained operational queue, mapping or intermediate dataset. Use filters so that only meaningful changes create work.

Changing a Trigger

Changing how a Workflow starts can change its operational contract even when the downstream canvas stays the same.

After changing a Trigger, retest the Workflow with representative input and re-check publishing, authentication and downstream assumptions.