Task · Workflows

Create a workflow

An automation that fires on account activity and posts to a webhook.

6 steps · About 4 minutes

1. Open Workflows and select New workflow

   Your accountWorkflows

   go.tito.io/acme/admin/workflows

   The workflow is made straight away, and its name follows the first trigger you pick. You can type over it at any point.

2. Fill in When

   When is what starts it off: an order started, completed, paid, refunded or canceled, or a ticket issued, voided or checked in, or an attendee's details changed.

   Order started runs as soon as somebody starts an order. On an event that isn't collecting emails from people who don't finish registering, it waits until the order is completed, and never runs for somebody who leaves without paying. Order completed runs once, when the order is paid, placed by bank transfer, or made by your team.

   Pick as many as you need. The workflow runs when any one of them happens, and it runs once each time.

3. Add Only if if you need it

   Look at lists the values you can compare: the order, the ticket, the event and your account, each shown with its real value from a recent order. You compare one against something you type. Amounts compare as numbers, so pick Order total rather than Order total, formatted when you're testing "more than".

4. Fill in Then

   A web address the other service gave you, and the fields to send it. The table arrives filled in from the trigger you picked. Change or clear any row.

   Each row becomes one field in the JSON that gets sent. Templates can reach the order ({{ order.total }}), the ticket on ticket triggers ({{ ticket.name }}, {{ ticket.id }}), and any collected answers by their export name from Questions ({{ ticket.answers.company }}, and a key with hyphens as {{ ticket.answers['t-shirt-size'] }}).

   On an account whose tickets were brought over from an older Tito, each ticket also has what it was known by there. {{ ticket.legacy_id }} is the number it had, and it stays the same every time the account is brought over again, so a service that keeps one record per ticket keeps matching them up. {{ ticket.id }} is assigned here and can change, which leaves that service holding a second record for the same person. {{ ticket.legacy_slug }} is the code in the ticket's QR, so a badge printed from it scans the same as the ticket itself. Both are empty on a ticket sold here.

   An older Tito asked every buyer for a company, a phone number and a job title without the organizer adding a question for them. Those come through as {{ ticket.company }}, {{ ticket.phone }} and {{ ticket.job_title }}, with {{ order.company }} and the same pair for the buyer. Where the attendee left one blank, the ticket falls back to what the buyer gave. An account may also have asked its own job title question, and the two are separate: the built-in is filled on tickets the question never reached.

   A ticket issued through a portal also has {{ ticket.portal }}, the portal's name. It's empty on a ticket that came through no portal.

   Send it as chooses between POST, PUT and PATCH. PUT creates or updates the same record when sent again, and PATCH changes a record that already exists. Each row's Send as can send its value as text, a number, or yes/no.

   Under the table, What gets sent shows the JSON body one run would produce, filled in from a recent order or ticket in this account. A step that has to send a particular shape shows that shape with your values in it. A step with no fields at all shows the one body it sends on every run.

   Anything that comes out empty is listed under Empty fields with the reason. Where no field in this account has the key, the row is marked as a problem and stays empty on every run until you correct the key. Where the key is real and this one example left it blank, it says so.

   A step that has to send a particular shape can point at a field name that isn't in the table. That's listed the same way and marked as a problem. It stays empty on every run until the names match.

   If you need a value the list doesn't have, choose Something else….

   That lets you write the template yourself under Write my own template.

   If someone else has a step open, their name shows beside Save step. If they save while you're editing it, your save keeps their changes to fields you didn't touch, and asks you to choose for any field you both changed.

5. Choose its events

   Under Which events this covers, Every event includes events you create later. Only the events I pick limits it to the events you tick.

   Picking shows every event in one list, with the ones the workflow covers at the top. Ticking or unticking an event leaves it where it is in the list. To find an event, type part of its name or date in Find an event. Select all and Clear change only the events you can see, so a search narrows what they touch.

   Events that have finished are left out of the list until you turn on Show finished events. One that is already covered is always shown, so you can see what the workflow runs on and untick it.

6. Turn on Enabled

   The switch stays out of reach until the workflow could run, and says what's missing while you build.

   Every run is kept under Activity.

   A failed run names the likely cause and the next move, and Run again queues the same trigger as a fresh run.