Can one automation react to more than one event category — say, both User Created and Connection Deleted?

No. Each trigger subscribes to one event type. Build separate automations per event, and share downstream logic through a Callable automation if it overlaps.

How do I know if a pipeline completed successfully or with errors?

Inspect the status field in the Pipeline Completed event payload — the event fires for both outcomes, so add a Condition node to branch on the value.

What should I do with the API Access Profile Changed payload?

Treat it as sensitive. Use the before/after snapshots only within the automation's own steps (e.g. to compare permission sets) — never write the raw payload to logs or forward it externally without masking credential fields.

Can I filter these triggers by specific object, app, or environment?

Yes — most Platform Event triggers accept a filter condition on fields in the payload, such as a connection's app type, a change set's target environment, or an automation's name.

A Platform Event starts an automation the moment something happens inside UnifyApps itself — a user created, a connection changed, a change set deployed, a pipeline completed, an automation run failed — rather than in a connected third-party app. Use these to automate governance, security, and operational housekeeping around the platform.

Overview

All Platform Events are real-time, webhook-style subscriptions — each fires the instant the event occurs, with no polling interval. Each automation gets its own independent subscription, so two automations listening to the same event type never interfere with each other. Most events accept a filter condition so your automation only fires on the specific circumstances you care about — for example, only failed logins from a particular source, or only connection changes for a specific app. Some payloads are fixed (a known, unchanging set of fields); others are dynamic, resolved at runtime from whatever record actually changed.

They fall into six categories, covered below: User Events, Connection Events, Change Set Events, Project & Pipeline Events, Automation & API Events, and a generic catch-all trigger.

User Events

Fire when a user account changes state or performs an authentication action. Use these to auto-provision resources for new users, alert on repeated login failures, or clean up after a deletion.

Event	When It Fires	Use It For
User Created	A new user account is added.	Auto-provisioning: assign default roles, create a workspace, send an onboarding email.
User Updated	A user's profile or attributes change.	Sync profile data downstream, or audit the change.
User Deleted	A user account is removed.	Deprovisioning: revoke access tokens in connected systems, archive their data.
User Logged In	A user successfully authenticates.	Audit logging or session-start workflows.
User Logged Out	A user's session ends.	Session-end housekeeping or audit logging.
Login Failed	An authentication attempt does not succeed.	Security alerting: detect brute-force patterns, alert on repeated failures.
Password Reset	A user's password is reset (self- or admin-initiated).	Audit trails or follow-up security checks.

The login failed event fires for every failed attempt regardless of cause — read the payload to distinguish bad passwords from account lockouts or other failure reasons. The user deleted event fires at the moment deletion is processed, so act on it promptly to avoid access gaps in connected systems.

Connection Events

Fire when a managed connection to an external system is created, updated, or deleted. Use these to notify teams when new integrations go live, or trigger re-validation logic when a connection changes.

Event	When It Fires	Use It For
Connection Created	A new connection is added.	Register it in an external catalog, run a connectivity test, trigger a first sync.
Connection Updated	A connection's configuration changes (e.g. credentials rotated).	Propagate the updated configuration downstream, or log the change.
Connection Deleted	A connection is removed.	Revoke associated tokens externally, pause dependent automations.

Note: The connection-deleted event's payload may include credential fields at the time of deletion — treat these as sensitive and never log or forward them unmasked.

Change Set Events

Fire as a change set moves through its deployment lifecycle. Use these to notify reviewers, enforce approval policies, or kick off post-deployment validation.

Event	When It Fires	Use It For
Change Set Submitted	Submitted for review.	Notify assigned reviewers, create a review task, log the submission.
Change Set Approved	A reviewer approves it.	Notify the submitter, trigger pre-deployment checks, queue the deployment.
Change Set Rejected	A reviewer rejects it.	Send the submitter feedback, reopen the related work item.
Change Set Deployed	It's deployed to a target environment.	Run smoke tests, invalidate caches, notify stakeholders.

The deployed event fires when deployment is initiated, not necessarily when it's fully applied — if post-deploy tasks depend on completion, add a check or wait step first.

Project & Pipeline Events

Fire during the lifecycle of projects and data pipelines. Use project events for project-level governance and housekeeping; use pipeline events to kick off downstream syncs, alert on failures, or act on individual record outcomes as a pipeline runs.

Project Events

Event	When It Fires	Use It For
Project Created	A new project is added.	Initialize standard resources, assign default members.
Project Updated	Configuration or metadata changes.	Propagate changes to external tools, log for audit.
Project Deleted	A project is removed.	Archive assets, revoke permissions, notify affected members.

Pipeline Events

Event	When It Fires	Use It For
Pipeline Created	A new pipeline is defined.	Register it in a catalog, notify the owning team.
Pipeline Updated	A pipeline's configuration changes.	Re-validate downstream dependencies, log the change.
Pipeline Completed	A run finishes — success or failure.	Run-level reactions: overall notification, post-run sync.
Pipeline Record Success	One record processes successfully.	Per-record follow-up: update a status field, notify downstream.
Pipeline Record Failure	One record fails to process.	Route to an error queue, alert, or retry.

Note: Pipeline Completed fires on both successful and failed runs — inspect the status field, don't assume "completed" means "succeeded." Record-level events fire once per record, not once per run, so high-volume pipelines can generate large bursts — apply filters and make sure the triggered automation can handle the throughput.

Automation & API Events

Fire when an automation run errors or is cancelled, or when an API access profile changes. Use these to build self-healing workflows, fire failure alerts, and audit credential changes.

Event	When It Fires	Use It For
Automation Run Failed	A run ends in any kind of error — bad input, timeout, permission denial, and so on all trigger this the same way.	Self-healing workflows: read the error details to classify and route the failure.
Automation Run Cancelled	A run is explicitly cancelled before completing (does not fire for failures or timeouts).	Clean up partial state left by the cancelled run.
API Access Profile Changed	An API access profile's configuration is modified.	Compliance auditing, security alerting on elevated permissions.

Note: The API Access Profile Changed payload's before/after snapshots can include credentials — passwords, client secrets, API keys. Never log this payload verbatim or forward it to external systems without masking sensitive fields first.

Generic Platform Event (Catch-All)

The catch-all Platform Event trigger watches changes across a broader set of platform object types that don't have a dedicated event of their own — automations, roles, user groups, entity types, API endpoints/collections/policies/clients, access profiles, connections, permission groups, and identity providers. You choose which object types and which change (created, updated, deleted, or any) should fire the automation. It also reports the deployment source of a change — for example, that it arrived via a change set deployed from another environment — so you can trace where a change originated.

Reach for it when there's no dedicated trigger for the object you care about, or when one automation should watch several object types at once; use the specific event triggers above when you need their richer, tailored payloads.

Notes

All Platform Events are delivered in real time — there's no polling delay between the event occurring and the automation starting.
Apply filter conditions to scope a trigger to what you actually need — without one, a trigger fires for every matching event across the entire platform.
Each automation gets its own independent subscription; multiple automations can react to the same event type without interfering with each other.
Design event-driven automations to be idempotent where possible — if an event is ever delivered more than once (e.g. due to a retry), the automation should produce the same result without duplicating side effects.
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.