An App Trigger starts an automation the moment an event happens in a connected third-party app — a new email arriving in Gmail, a ticket created in Zendesk, a record updated in Salesforce. It's the most common way to start an automation, because most workflows exist to react to something that already happened somewhere else.
Overview
Every app that exposes trigger events shows up in the trigger step's app catalog alongside the actions it supports. Picking an app trigger subscribes your automation to one specific event from that app; when the event occurs, the platform receives it, starts a new run, and makes the event's data available as data pills to every downstream step.
App triggers are one of two ways an automation can start from something happening on an app — the other is a Platform Event, which reacts to something happening inside UnifyApps itself (a new user, a failed login, a deployed change set) rather than in a connected third-party app. Use an app trigger whenever a third-party app's event is the natural starting point; see Platform Events for the platform-internal alternative.
Where to find them: Automation builder > trigger step > App & event tab
Configuring an App Trigger
Pick the app and its specific event on the trigger's App & event tab — only apps that expose at least one trigger event appear here, which is why an app with actions but no events won't show up when you're picking a trigger. Then use the Setup tab to choose the connection to use and, for most events, one or more filter conditions that narrow which occurrences of the event should start a run (for example, "Only when status equals Open"). Filtering at the trigger means the automation only runs for the events it was built to handle, instead of running on everything and discarding the rest further down the flow — and since a filtered-out event never creates a run, it never shows up in run history either.
A trigger subscribes to exactly one app and one event at a time; if a workflow needs to react to two different events, build two automations — one per event — and, where they share logic, have both call a common Callable automation instead of duplicating the downstream steps.
Delivery, Connection Scope & Testing
Most app triggers are real-time — the connector subscribes to the source app's own webhook or event stream, so the run starts the instant the event happens. A smaller number of connectors have no native event stream and instead expose a polling-based trigger: for example, an RSS/Atom feed's "new item" trigger polls on an interval that defaults to 10 minutes, and a generic "new or changed file" trigger polls roughly once a minute.
An app trigger also watches one connection at a time — to react to the same event across two accounts of the same app (say, two Salesforce orgs), build a separate automation per connection. And unlike an action step, a trigger has no Test button of its own — confirm it's wired correctly by running the automation once and checking that the run started with the payload you expect.
Common Use Cases
App triggers cover the majority of everyday automations because they hook directly into the tools a team already works in:
Support workflows — start an automation when a ticket is created or its priority changes, to route it, notify the right team, or open a linked record in another system.
Sales and CRM sync — start an automation when a record is created or updated in a CRM, to enrich it, sync it to another system, or notify the owning rep.
Inbox automation — start an automation on a new email matching a filter, to extract data, file an attachment, or create a follow-up task.
Cross-app handoffs — start an automation when a record changes in one app so its counterpart in a second connected app is created or updated in step.
Because each of these reacts to an event already emitted by a tool your team uses, they typically need only a trigger, a filter, and one or two downstream actions to be useful — which is why app triggers tend to be the fastest type of automation to build end to end.
Notes
Default to an app trigger whenever the natural starting point for your workflow is something happening in a connected app — that covers the majority of automations.
Apply filter conditions at the trigger to narrow the events that start a run — filtering here avoids run overhead for events you'd discard anyway.
Don't assume every connector's trigger is real-time — a few are polling-based, which adds up to one interval's worth of delay.
Plan for one automation per connected account when an app trigger needs to cover more than one instance of the same app.
Verify a new trigger by running the automation once, not by looking for a Test button — triggers don't have one.