A setup trigger is the starting point of every automation — it defines what causes the automation to run, and the four available types are Application Trigger, Webhook, Schedule, and Callable, each suited to a different initiation pattern.

Overview

Each trigger type starts an automation in a different way. Choose based on who or what needs to initiate the run: an event happening on a connected app or on the platform itself, an external system pushing a request, a clock firing on a timetable, or another automation invoking shared logic.

Application Trigger

An Application Trigger starts a run from an event on an app — either a third-party app you've connected, or the UnifyApps platform itself. Configure it from the trigger's App & Events tab, then finish setup — connection and any filter conditions — on the Setup tab. The event's data is available as data pills to every downstream step.

App Trigger

Reacts to an event raised by a connected third-party app — a new ticket in Zendesk, a record change in Salesforce. Most app triggers are real-time; a few connectors instead poll on an interval. An app trigger is scoped to one connection at a time.

Platform Event

Reacts to an event raised by the UnifyApps platform itself — a new user, a failed login, a deployed change set — built for governance, security, and operational housekeeping. Platform events are always real-time and most accept a filter condition.

Webhook

The Webhook trigger gives your automation a unique URL that other systems can call. When an HTTP request hits that URL, the automation starts immediately, with the request's body, headers, and query parameters all available to the steps that follow. Use it to let an external app push events to you in real time — a form submission, a payment event, a message from another platform — instead of polling for changes.

You define the shape of the incoming data when configuring the trigger, so the rest of the automation can map fields from it cleanly. Incoming requests are validated against that data shape, so malformed payloads are caught before they reach your steps.

Responding to the caller

A Webhook trigger does not return workflow data to the caller. If the caller needs a response, use a Callable trigger with Trigger via API instead, define its Responses, and add a Respond to API request step on every path that should reply.

Schedule

The Schedule trigger runs an automation automatically on a recurring timetable — no incoming request or manual start needed. You define the recurrence in one of two ways:

• Interval — "every N seconds / minutes / hours / days / weeks / months", for simple recurring jobs.

• Cron expression — precise calendar timing such as "weekdays at 9:00", for jobs that need fine-grained control over when they fire.

The Schedule trigger is timezone-aware: you set the timezone the schedule should follow, and the platform fires it at the right local time, handling daylight-saving shifts automatically. Use it for digests, syncs, cleanups, reminders, and any job that should run on the clock.

Minimum interval

The shortest interval you can set is 15 seconds by default. If you enter an interval below this minimum, the schedule is rejected with a validation error — you cannot accidentally create a job that fires faster than allowed. Platform administrators can configure a longer minimum floor, so your environment may enforce a stricter limit than 15 seconds.

Trigger In Sequence

If a scheduled run has not finished by the time the next one is due, the Trigger In Sequence toggle decides what happens:

• On — the platform waits for the current run to complete before starting the next. Any scheduled triggers during an active run are skipped, and the trigger's output counts how many were skipped. Turning it on also shows Run Time-Duration Limit (default 30) and Run Time-Duration Unit, which cap how long the scheduler waits for a slow run. Use this when runs touch the same data and must not collide.

• Off — runs can overlap. Use this when runs are independent.

Callable

A Callable is a reusable automation that other automations — or an external API — can invoke like a function. You define its inputs and outputs once, then call it from many places instead of copying the same steps everywhere. Use callables to factor out shared logic (such as "create a customer", "score a lead", or "send the standard onboarding sequence") so it lives in one place and every caller stays in sync.

Synchronous vs asynchronous

When you call a Callable, you choose how the parent automation should behave while it runs:

• Synchronous — the parent waits for the callable to finish and receives its outputs before moving on. If the callable fails, that error propagates to the parent so the parent can handle it. Use sync when you need the result, or need to know it succeeded, before continuing.

• Asynchronous — the parent fires the callable and moves on immediately, receiving only a simple acknowledgement (a success flag), not the callable's real outputs. The child runs independently, and its errors stay isolated — a failure in the async child does not fail the parent. Use async for fire-and-forget work such as notifications or background processing where the parent should not wait or be affected.

Run for user

The Call automation step has an optional Run for user field. Select a user, or map a user ID, to run the called automation as that user, so its permission checks apply to them. If you leave it empty, the callable runs in the caller's context. Only system-level runs can switch to another user; other runs fail with "User does not have permission to run automation as another user". The Call automation async step doesn't have this field.

Choosing a Trigger

Use the table below as a starting point when deciding which trigger fits your use case.

Notes

Keep the following in mind when configuring setup triggers.

• Use an Application Trigger when the automation should start from an event in a connected app (App Trigger) or from something happening on the platform itself (Platform Event).

• A Webhook automation does not return workflow data to the caller. If the caller needs a response, use a Callable trigger with Trigger via API and a Respond to API request step.

• Webhook payloads are validated against the data shape you define at configuration time; malformed requests are rejected before they reach your automation steps.

• The minimum Schedule interval is 15 seconds by default; entering a shorter value produces a validation error. Platform administrators can raise this floor.

• For scheduled automations where runs operate on shared data, turn on Trigger In Sequence so a new firing is skipped while a run is still active; leave it off only when runs are independent.

• An async Callable returns only an acknowledgement (a success flag) to the parent — not the callable's real outputs. Use synchronous mode when the parent needs the actual result before continuing.

• Use Run for user on the Call automation step only when the callable must run as a specific user. Leave it empty to run the callable in the caller's context.

When combining trigger types across a workflow — for example, an Application-Triggered automation that calls a Callable — test each trigger's behavior end-to-end to confirm data flows correctly across the boundary between automations.