Workflows

A notification policy sends a message. A workflow does something. Workflows are drawn under Launchpad → Automation → Workflow, as a trigger followed by steps and actions joined by lines.

The trigger

A workflow starts when a problem opens. You can narrow that with filters:

• At least this severe (serious by default);
• Only this kind;
• Only about a service, a host, an application or a database, and Only this one;
• Title or summary contains;
• Also when an old one comes back, which is off by default.

The catalogue also lists triggers for a service disappearing, a measured value crossing a line, a synthetic check failing, and an incoming web request. These can be drawn and saved, but today only the problem trigger starts runs. Workflows do not run for a machine in maintenance. Only the ticket's own organisation's workflows run.

Steps

Step	What it does
If	Compares a value with =, ≠, >, < or contains, and continues on yes or no.
Do both	Splits into two branches.
Wait	Pauses for up to 60 minutes. A waiting run is held in memory, so a restart of the install drops it.
Add a value	Stores something for later steps, read as {{extra.name}}.
Look something up	Adds the service, the host, the last deploy or the open problems.
Ask a model	Sends your prompt to the model that holds the "Runs inside a workflow" job. Only the prompt is sent.
Write the message	Composes the text the actions will send.

Actions

• Send a web request: POST, GET or PUT to your URL, with a ten-second timeout. Private addresses are refused, except for workflows of the install's own organisation.
• Send an email: needs an email channel. Through the install's shared mail server, it may only write to members of your organisation.

Running a command and opening a problem appear in the catalogue but are refused by the engine for now.

Templates

Text fields can use the ticket's values:

{{problem.title}}   {{problem.severity}}   {{problem.kind}}   {{problem.summary}}
{{problem.cause}}   {{problem.evidence}}   {{problem.host}}   {{problem.app}}
{{problem.entity_name}}   {{problem.peak}}   {{problem.opened_at}}   {{problem.url}}

A name that has no value in a run is listed in that run's trace, so a typo shows up instead of sending an empty field.

Example

1. Trigger: a problem opens, at least serious, only about the checkout service.
2. Look something up: the last deploy.
3. If the deploy was in the last half hour: ask a model to summarise the ticket and the deploy in two sentences.
4. Write the message from {{problem.title}}, the model's answer and {{problem.url}}.
5. Send a web request to your chat or ticketing system.

Test runs and the run log

Test run runs the workflow against the most recent real ticket that matches it, and it sends for real. If no ticket matches, it uses an invented ticket that says so. Each run keeps a trace of what every step decided. The editor lists the last runs, which is how you debug a drawing. A run stops after 60 steps, in case the drawing loops, and a drawing can have up to 60 nodes.

Workflows need the Automation capability, which is off by default for members. See Capabilities.