# SOPs and automation triggers

Start SOPs, automatic tasks and messages from events, schedules or webhooks, with typed conditions and assistant chat commands.
Page: https://app.proptonomy.ai/docs/automations

## One routine, several ways to start (https://app.proptonomy.ai/docs/automations#what-is-new)
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 (https://app.proptonomy.ai/docs/automations#set-up)
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 (https://app.proptonomy.ai/docs/automations#trigger-types)
- When an event occurs: Start from a committed change, such as task.created or reservation.updated.
- On a schedule: Run once or repeat daily, on weekdays, weekly, monthly or with custom cron. Choose a timezone; 17:00 Pacific/Auckland follows New Zealand daylight saving.
- Relative to a reservation date: Choose check-in or check-out and hours before or after it. Uses the organisation's timezone and re-evaluates changed booking dates. Cancelled reservations cannot start a new task action.
- When a webhook arrives: An authenticated request to a configured incoming source starts the routine. Declare payload fields before using them as conditions.
- When run manually: An administrator runs the published version from the app, with reservation context if its actions need a stay.
- When requested by an AI tool: An administrator asks the assistant to invoke the published workflow. Add this trigger before asking to run a workflow from chat.

## Choose events by their names (https://app.proptonomy.ai/docs/automations#events)
Event keys are lower-case and dot-separated. The catalogue shows which events and fields are available in your workspace.
- Tasks: task.created, task.updated, task.deleted. Selecting task subscribes to these three. Add task.status.changed separately for status transitions.
- Reservations: reservation.created, reservation.updated, reservation.deleted. Selecting reservation subscribes to these three. reservation.status.changed covers all status transitions.
- Properties: property.created, property.updated, property.deleted; property is their CRUD selector.
- Reviews and ratings: review.created, review.updated and reservation.rating.created. Choose review.created for every new review; a booking-linked review can also emit reservation.rating.created, so selecting both can start two separate runs.
- Inbox and contacts: inbox.message.received; conversation.created/updated/deleted; contact.created/updated/deleted and contact.tag.added/removed.
- Inventory: inventory.item.created/updated/deleted; inventory.delivery.created/updated/deleted and inventory.delivery.status.changed; inventory.transaction.created.
- Enso: enso.upsell.created, enso.upsell.status.changed and enso.boardingpass.verification.status.changed. Availability requires the workspace's supported active Enso connection; these observe integration syncs, rather than promising instant provider callbacks.

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 (https://app.proptonomy.ai/docs/automations#conditions)

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.

Click an empty condition to see the available variables, then type to filter the suggestions by field path or name. Choose a variable such as reservation to browse its fields. `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. Clear the condition and click inside it to browse variables. Type guests to find Number of guests, or reservation. to browse its fields. Show suggestions or Ctrl+Space reopens the dropdown. This is the actual editor; this documentation example does not compile, apply or publish a condition.]

## A short wait groups matching events (https://app.proptonomy.ai/docs/automations#batching)

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 (https://app.proptonomy.ai/docs/automations#chat-commands)
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.
- Discover: Proptonomy, which automation events can I subscribe to, and which reservation fields can I filter on?
- Find and read: Show our automations for new reviews, including their triggers and published state.
- A new review: Run our Review SOP every time a new review arrives. Use our operations agent and enable the workflow.
- AI maintenance: Draft a workflow: when AI creates a maintenance task with no assignee or scheduled date, run our Maintenance Monitoring SOP and report to this operations group. Include tasks created by other workflows. Use immediate timing.
- A schedule: Draft our Unfinished Tasks SOP for every day at 5 PM Pacific/Auckland. Check whether it already has a schedule first.
- Automatic tasks: Draft a workflow to plan tasks using our existing Solo Guest Checklist rule whenever reservation.created has Number of guests equal to 1.
- Change a condition: Change the draft one-guest workflow to use reservation.numPeople === 1. Validate it and show the rule; leave it as a draft.
- Run from chat: Add a When requested by an AI tool trigger to our published Review workflow. After publication, run that workflow now for the reservation I selected.
- Existing cron: Show the existing Unfinished Tasks schedule and import it into a draft workflow without stopping the current schedule.
- Capacity and cost: Show our automation execution limits. Estimate the AI-step token cost of the reviewed one-guest workflow for 20 matching events and two model calls per AI step.

Note: A request needs real targets. Replace the example SOP, rule and agent names with yours. If a name is ambiguous or a target is missing, the assistant needs that choice. A prose instruction alone does not create a trigger; the confirmation must describe the saved draft or enabled published revision.

## Existing tasks and schedules keep working (https://app.proptonomy.ai/docs/automations#tasks-and-schedules)

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 (https://app.proptonomy.ai/docs/automations#webhooks)

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 (https://app.proptonomy.ai/docs/automations#run-history)
- Open the workflow's run history to inspect its published revision, trigger, matched context, action results and receipts.
- Pending means queued; Running means execution started; Waiting means a wait or reply step is active. Completed means workflow processing finished, including any skipped steps. Planned tasks and messages may still be pending; inspect their receipts and lifecycle. Held, Failed and Cancelled need their recorded reason checked.
- A chat confirmation that a run was queued is not proof that its message was delivered or its task was approved. Required approvals and tool permissions still apply.
- New event subscriptions begin with future eligible facts after activation. They do not replay all historical events. Execution limits can defer work while retaining its run identity.