Event-triggered automations

Event-triggered automations react when something happens, such as a Salesforce field changing or a new record appearing. Use them to turn a relevant change into the research, signal, or follow-up your configured workflow provides.

Organization administrators open Org settings → Event triggers. The four tabs describe the flow:

• Definitions: the conditions that identify an event.
• Triggers: the actual events that were detected.
• Consumers: the actions subscribed to an event type.
• Runs: each consumer's execution for a trigger. One trigger can lead to several runs when multiple consumers match.

Creating a definition identifies what to watch. Attach the appropriate consumer to make an action follow. For recurring work on a schedule, see Agents.

Build an automation by describing it to Athean. Organization administrators can create automations; anyone else needs the Automation permissions in one of their roles. If you do not see Automations under Agents, or New automation is unavailable, ask your administrator for access.

1. Open Agents → Automations and select New automation.
2. Describe what should start the work, such as a Salesforce change or a schedule, and the action that should follow. Name the records, recipients, and channels involved.
3. Review the plan Athean proposes in the conversation, ask for any changes, and approve it. Athean saves the automation paused, so it does not run yet.
4. Review its Specs and Settings, then test it.
5. When the results are what you expect, select Resume on the automation's page to turn it on.

To change what an automation does, describe the change in its conversation and approve it. Athean saves the change as a new version without activating it. The current version keeps running until you open Versions and select Make active version on the new one.

The Automations list shows the automations you own, or everyone's when you have View all (including others) or Edit any (including others). Without permission to edit an automation, you can inspect its Runs, Specs, Settings, and Versions, but you cannot change, test, run, pause, or delete it.

An automation runs with its owner's access. If the owner can no longer edit it, for example after a role change, it stops running. Org settings → Event triggers remains available only to organization administrators.

Open Automations to find the workflow behind an event consumer.

1. Use Search name or creator… to find an automation by its name or creator's name.
2. Use Add filter to narrow by Created by, Status (Active, Paused, or Needs setup), or Trigger.
3. Use Last run status and Last run within to focus on recent activity. Choose a time preset or Custom range; workflows without a last-run time do not match a date window.
4. Open the matching workflow and review its setup and run result. Save a useful search through the View menu when you want to repeat it.

The browser address preserves the current search and filters. View → Copy link links to the saved view, excluding unsaved edits; copying a link does not grant access. See Saved views to save and share a useful setup. These filters narrow the automation list; use Event triggers → Runs to investigate a particular event's consumer execution.

1. In Definitions, select Create definition.
2. Enter a recognizable Label and review its Event type. Consumers use that event type to match the event, so keep it consistent with the action you intend to attach.
3. Choose the Salesforce object and Operation: Update, Create, or Create or update.
4. Set the field condition and relevant values. Update conditions can specify an Old value and New value; Create supports multiple field conditions.
5. Choose a Lookback window and select Test. Review the match count and sample records.
6. When the conditions are correct, select Save.

The definition test previews recent matching records without saving the definition or firing its actions. A newly saved definition is enabled, so prepare the intended workflow and review any consumers already using its event type.

Update-based conditions require the relevant Salesforce field history. Resolve a not tracked warning by enabling field-history tracking in Salesforce or choosing a supported field. Some system and legacy definitions are read-only.

1. Open Consumers and select Create consumer.
2. Enter a Label and choose the matching Event Type.
3. Choose the available Action Type. If it requires a workflow, select the intended Workflow.
4. Review any action-specific configuration and select Save.

A newly saved consumer is enabled. Review its audience, outputs, and record-changing actions before saving. If the workflow or action type you need is unavailable, chat with us to configure it.

No action wired in Definitions means an event can fire without a connected action. Check the event type and its consumers when detection works but nothing follows.

The Enabled columns show the definition and consumer statuses. These cells are read-only. For a consumer connected to an automation, use Open workflow, then Pause or Resume when available. This controls the automation and its event subscription together. An automation may need its setup completed before it can resume. For other definition or consumer status changes, contact support.

Test an automation on events Athean has already detected before relying on its live runs. You can test from the automation itself or, as an organization administrator, from its consumer in Event triggers.

Email and Slack steps can send real messages during a test. Those messages are marked [TEST RUN]. Review the workflow's recipients and channels before running a test, even when the interface describes testing as read-only.

To test from the automation, open it and select Run test. This requires permission to edit the automation.

1. In Choose versions, pick the Version to test. To see how another version handles the same events, choose it under Compare with. Select Next.
2. In Choose events to replay, use Add filter or search by source record ID to find representative events, then select them.
3. Select Run test and review Test results. When comparing two versions, turn on Show only differences to focus on where they disagree.
4. Select Done to return to the automation.

For an automation that runs on a schedule, Run test starts a test run right away instead, and Run now starts a real run.

To test from Event triggers, open Consumers and select Test workflow in the row of a consumer linked to a supported workflow.

1. Find representative triggers using the status and Source Record ID filters.
2. Select up to 10 triggers and choose Run Test.
3. Review Test Results, including each result and any errors. Open a result to inspect the detail.
4. Use Rerun Test to choose another sample after reviewing or updating the workflow.

Test mode simulates record-changing actions, with the email and Slack notification exceptions above. It helps you evaluate the workflow's logic; the definition's separate Test checks which source records match the event conditions.

Use Open workflow to inspect the linked workflow. A new version affects live runs only after you select Make active version on it in Versions.

Start in Triggers to check that the source change was detected. Open the source record or payload to confirm it is the event you expected.

Then open Runs and inspect the associated consumer. Review Status, Error, Action Taken, and Result. The details also identify the workflow version when available.

A detected trigger and a successful action are separate outcomes. Several consumers can react differently to the same trigger, and a workflow can determine that no action is appropriate. Read the result before treating a quiet outcome as a failure.

• No trigger: check the definition's status, source object, operation, field values, and Salesforce history support. Use the definition Test to check recent matches.
• Trigger but no action: check for No action wired, a missing consumer, a mismatched event type, or a disabled consumer.
• Failed run: read the error and result, confirm the linked workflow and its active version, then test an appropriate sample after correcting the cause.

A successful test does not establish that a failed live run has recovered. If an event needs live reprocessing, contact support with the definition, source record, consumer, run time, and expected result.

For events from another platform or an internal system, chat with us about connecting that source. API setup separately explains publishing signals from your own tools.