Skip to main content
This tutorial creates an Automation that posts an alert when an App record is inserted or updated with priority set to P0. You will prepare its instructions, save the trigger, and check the resulting run.

​
Before you begin

You need:
  • An existing App with a registered entity whose record data includes a text field named priority.
  • An Agent in the destination Room with access to that App.
  • An authenticated CLI and permission to create Automations in the Room. See Authentication.
Replace the IDs below with values from your workspace. This example is for a signed-in person and explicitly selects the Agent with --agent. If an Agent carries out the setup in a conversation, its assignment supplies that identity. The alert is posted in Kylon. Each matching insertion or update can produce an alert, including an update to another field while the priority remains P0. To alert only when a record becomes P0, the implementation also needs to compare prior state.

​
1. Find the App and entity

Keep the App ID and entity ID from the returned contract. Confirm that priority is the record-data key and that the value is exactly P0; filters use strict equality. If your App uses a different key, substitute it in both the filter and instructions below. Check for an existing Automation before creating another:

​
2. Prepare the instructions

Save the following as p0-alert.md:
Review the proposed output with the Agent before scheduling it. For data that requires a more involved lookup or change, include those requirements in the saved instructions.

​
3. Save the Automation

Keep the returned Automation ID. Saving enables the trigger but does not execute a run immediately. The default destination is the Room’s main conversation. Read back the saved definition:
Confirm the App, entity, events, filter, Agent, and destination. The filter is optional; remove it if every change should trigger work. Delete events have no field data, so a value filter cannot match them.

​
4. Check a triggered run

Create or update a designated test record in the App so its priority is P0. This is a real record change and will produce a real alert. Then inspect the run:
The expected result is an alert in the Room containing the matching record’s label, link, and change type, with a corresponding run in history. Check the actual output as well as the run status. For this trigger, testing through a record change supplies the event data the instructions expect. Run now is a separate real execution, not a dry run or a replacement for the record-change test.

​
5. Manage the Automation

Open it in the Room to pause, resume, review run history, or set credit protection. Resolve reported failures before resuming an automatically paused Automation. Resuming does not execute immediately. See Automations for other trigger types and workflow for schedule JSON, state storage, SDK code, and webhook controls.