A Platform Event trigger starts an automation the moment something happens inside UnifyApps itself — a user created, a connection changed, a pipeline completed, or an automation run failed — giving you real-time hooks into platform governance and operations without polling.
Overview
Platform events start an automation when something happens inside UnifyApps itself, rather than in a connected third-party app. They cover governance, security, and operational events such as a new user being created, a connection being changed, or an automation run failing. This is the platform-internal counterpart to an App Triggers — use a platform event when the automation is about governing or operating UnifyApps itself, not about reacting to something in a connected app.
All platform events are real-time. Each is a webhook-style subscription that fires the moment the event occurs — there is no polling interval. Most triggers accept a filter condition 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). Each automation gets its own independent subscription, so two automations listening to the same event type never interfere with each other.
Where to find them: Automation builder > platform event triggers
User Events
Fire when a user account changes state or performs an authentication action: created, updated, deleted, logged in, logged out, login failed, and password reset. Use these to auto-provision resources for new users, alert on repeated login failures, or clean up after a deletion.
See User Events for the full event reference, use cases, and FAQs.
Connection Events
Fire when a managed connection is created, updated, or deleted. Use these to notify teams when new integrations go live or trigger re-validation logic when a connection changes.
Change Set Events
Fire as a change set moves through its deployment lifecycle: submitted, approved, rejected, or deployed. Use these to notify reviewers, enforce approval policies, or kick off post-deployment validation.
Project and Pipeline Events
Fire during the lifecycle of projects and data pipelines: project created/updated/deleted, pipeline created/updated/completed, and per-record success/failure.
Note: Pipeline Completed fires on both successful and failed runs. Inspect the status field in the payload to determine the outcome — don't assume "completed" means "succeeded."
Automation and API Events
Fire when an automation run errors or when API access configuration changes: Automation Run Failed, Automation Run Cancelled, and API Access Profile Changed.
Note: API Access Profile Changed payloads may carry credentials — passwords, client secrets, API keys — in the before/after fields. Don't log or forward this payload without masking sensitive values first.
Generic Platform Event (Catch-All)
Watches changes across broader object types with no dedicated trigger — automations, roles, user groups, entity types, API endpoints/collections/policies/clients, access profiles, connections, permission groups, identity providers — for a chosen change action (created, updated, deleted, or any), and reports the change's deployment source (for example, a change set from another environment). Use it when no dedicated trigger covers your object type, or one automation should watch several types at once; use the specific triggers above for their richer, tailored payloads.
Notes
Apply filter conditions on every platform event trigger to narrow the events that start a run — filtering at the trigger avoids run overhead for events you'd 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 the 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.