Application Triggers start an automation the moment something happens inside the UnifyApps platform itself — for example, a user is created, a connection changes, a pipeline completes, or an automation run fails. Because each trigger reacts instantly (not on a polling schedule), you can automate platform governance and operations in real time.

Overview

Application triggers — referred to in the platform as platform event triggers — are built-in triggers that start an automation when an event occurs inside UnifyApps itself. They cover governance, security, and operational events such as a new user being created, a connection being changed, or an automation run failing.

Application triggers differ from connector-based triggers in scope: connector triggers react to events in third-party apps (a new ticket in Zendesk, a record updated in Salesforce), while application triggers react to events produced by the UnifyApps platform itself. Use application triggers to automate housekeeping, enforce governance policies, or build audit pipelines that run entirely within the platform.

All application triggers are real-time. Each trigger listens for its event and fires the moment the event occurs — there is no polling interval or delay. Each automation gets its own independent subscription, and most triggers accept a filter condition — a rule you configure on the trigger to narrow which events start the automation — so your automation only fires on the specific events you care about (for example, only failed logins from a particular source, or only connection changes for a specific app).

Where to find them: Automation builder > platform event triggers

User Events

User event triggers fire when a user account changes state or when a user performs an authentication action. Use these to auto-provision resources for new users, alert on security events such as repeated login failures, or clean up after a user is deleted.

Connection Events

Connection event triggers fire when a connection — an integration with an external system — is created, changed, or removed. Use these to notify teams when new integrations go live, or to trigger re-validation logic when a connection is updated.

Change Set Events

Change set event triggers fire as a change set moves through the deployment lifecycle — from submission through approval or rejection to deployment. Use these to notify reviewers, enforce approval policies, or kick off post-deployment validation workflows.

Project and Pipeline Events

Project and pipeline event triggers fire during the lifecycle of projects and data pipelines. Use these to monitor pipeline health, trigger downstream syncs when a pipeline completes, or alert on per-record processing failures.

Note: The Pipeline Completed trigger fires on both successful and failed pipeline runs. Inspect the status field in the payload to determine the outcome — do not assume "completed" means "succeeded."

Automation and API Events

Automation and API event triggers fire when automation runs encounter errors or when API access configuration changes. Use these to build self-healing workflows, notify teams of runtime failures, or audit changes to API credentials.

Note: The API Access Profile Changed trigger's payload may carry credentials — passwords, client secrets, and API keys — in before/after fields. Do not log or forward this payload to external systems without first masking sensitive values.

Generic Platform Event (Catch-All)

The generic platform event trigger watches for changes across a broad set of platform objects — things like automations, roles, and API configurations — that do not have their own dedicated triggers. You choose which object types and which change actions (created, updated, deleted, or any) should fire the automation.

Object types covered include: automations, roles, user groups, entity types, API endpoints, API collections, API policies, API clients, access profiles, connections, permission groups, and identity providers.

This trigger also reports the deployment source of a change — for example, that a change arrived via a change set deployed from another environment — so you can trace where a change originated.

Note: Use the generic platform event trigger when there is no dedicated trigger for the object type you want to monitor, or when you want one automation to watch multiple object types. Use the specific triggers — User Events, Connection Events, and so on — when you need their richer, tailored payloads.

Notes

Application triggers give you real-time visibility into platform activity without polling. To make the most of them:

• Apply filter conditions on every trigger to narrow the events that start a run — filtering at the trigger avoids unnecessary run overhead for events you would discard anyway.

• Inspect the status field in Pipeline Completed payloads before acting — this trigger fires on both successful and failed runs.

• Classify Automation Run Failed errors by reading the error details in the payload — a timeout, a permission error, and a bad input all fire the same trigger but require different remediation.

• Mask credential fields before logging or forwarding any API Access Profile Changed payload — the before/after snapshot may contain passwords, client secrets, or API keys.

• Use specific event triggers (User Events, Connection Events, and so on) when you need their tailored payload structure; fall back to the generic Platform Event trigger only when no dedicated trigger covers the object type you need.

• Each automation gets its own independent subscription — two automations listening to the same event type do not interfere with each other.