Text version. The interactive version, with live examples, is at https://app.proptonomy.ai/docs/automations. This page as Markdown: https://app.proptonomy.ai/docs/automations.md. Index of all pages: https://app.proptonomy.ai/llms.txt.

SOPs and automation triggers

Start SOPs, automatic tasks and messages from events, schedules or webhooks, with typed conditions and assistant chat commands.

https://app.proptonomy.ai/docs/automations

One routine, several ways to start

SOPs, automatic tasks and automatic messages share the same trigger and condition rules.

A routine can start when a task, reservation or review changes, on a schedule, before or after a stay, from an incoming webhook, or when you explicitly request it. You choose When, narrow it with Only if, then choose Do.

The SOP still contains the instructions: what to check, who to notify, and how to write the report. The trigger decides when to start; it does not replace those instructions.

Set up and enable a routine

Use an organisation administrator account in the workspace where the routine belongs.

  1. Open Workflows Settings → Workflows. Choose a starter or New automation. An SOP or a task-automation rule can also open the shared builder through its trigger control.
  2. Choose When and Only if Select a trigger and its conditions. For a booking with one guest, choose reservation.created, then Number of guests is 1.
  3. Choose Do Run an SOP selects the actual SOP and internal agent. Plan a task selects an existing task-automation rule. Task work timing is configured separately from when the workflow starts.
  4. Save, review, then publish Saving a draft does not enable a new routine. Publish the reviewed version to enable it. Later edits remain drafts until published; the current published version keeps running. Publication captures the SOP instructions for that revision. If you change the SOP, review and republish the workflow to use the new instructions.

Example on the page: Try the actual trigger builder. These are the product's real controls and starter templates, with a small example field catalogue. Your workspace discovers its full available catalogue from C# contracts. This example never saves or runs anything.

The six trigger types

Choose events by their names

Event keys are lower-case and dot-separated. The catalogue shows which events and fields are available in your workspace.

A status change can also produce an ordinary updated event. Select the precise event you need to avoid doing the same business action twice.

Only if: visual rules or an expression

Choose All rules match for AND, Any rule matches for OR, or Does not match for NOT. Fields, value types and allowed operators come from the same C# catalogue used by the assistant and server. An unknown guest count does not match the number 1.

For AI maintenance monitoring, require task type Maintenance and Created by AI, then an Any group for Has assignee is false or Scheduled date is missing. Include events produced by other automations if their AI-created tasks should be monitored too. The maintenance starter also checks for missing title and property; remove those two rules if you only want assignee and date checks.

The optional expression editor suggests available fields and the values they accept. reservation.numPeople === 1 compiles to the same visual rule. Comparisons, &&, ||, !, null and registered helpers are supported. Only supported conditions can be applied. In the actual workflow, use Apply as rules and publish the validated rules.

Example on the page: Try field suggestions. Type reservation. and choose Show suggestions or Ctrl+Space. This is the actual editor; this documentation example does not compile, apply or publish a condition.

A short wait groups matching events

Event and incoming-webhook triggers default to 5 seconds quiet, with a 30-second maximum wait from the first match. Each matching arrival extends the quiet period up to that maximum. Under Run timing and origin, choose Immediately for urgent work or In a fixed window to collect for the configured maximum.

Each run receives an events[] list, even for one event. Only events matching this trigger's conditions enter it. All items have the same concrete type and schema version: task.created and task.updated never share a list, even when you selected task. Two one-guest bookings can share a run; a two-guest booking cannot join it.

Limits can split a burst into further runs. There is no promise that everything in a busy workspace becomes one invocation. The SOP should process every relevant item in its event list.

Ask the assistant in a staff chat

Use an administrator's normal staff conversation in the correct organisation, with the assistant's Automation tools enabled. Knowledge tools find named SOPs; Task Automation tools find existing task rules. Guest chats and a running workflow cannot configure automation authority.

Example on the page: Draft, then enable a one-guest SOP. Illustrative wording, not a recorded conversation. The assistant must resolve the actual SOP and agent, save it, and read back its state before claiming it is enabled.

You: Proptonomy, draft a workflow that runs our Number of People SOP whenever a new reservation has exactly one guest. Use our operations agent. Show me the trigger before enabling it.
Proptonomy: Draft saved: reservation.created; Number of guests is 1; Run the Number of People SOP with the selected operations agent. Timing: 5 seconds quiet, 30 seconds maximum. It is not enabled yet.
You: Enable that reviewed draft.
Proptonomy: The published revision is enabled. New matching reservation events will trigger it. Existing event history is not replayed.

Existing tasks and schedules keep working

Deploying the shared builder does not automatically move existing cron schedules or task rules into workflows. Existing schedules keep running. Importing a schedule into a draft also leaves the original running; publishing the reviewed import transfers ownership so the original scheduler does not run a duplicate.

A Plan a task step uses the existing rule and its template, work dates, property scope and lifecycle. Its trigger time is separate from its work time. Publication transfers that rule's planning ownership, while existing live tasks and pending automatic messages retain their work slots. Review a transfer before enabling it.

Incoming and outgoing webhooks do different jobs

An incoming source starts a workflow. Create it in Workflows, declare its fields, and select it in When a webhook arrives. Your sender uses HTTPS, the source secret as a Bearer token, and a stable X-Delivery-Id. Retrying the same delivery with the same body deduplicates it; changing the body under the same ID is a conflict. Keep the secret private.

An outgoing event subscription sends committed facts to your endpoint independently of any SOP. Select native events in the webhook settings. Deliveries are individual CloudEvents envelopes and use the endpoint's signing contract; they do not inherit a workflow's debounce. A Send a webhook step is a separate workflow action.

Check what actually ran

All documentation pages