Dispatch in your workflows

The triggers Dispatch contributes and the job fields it adds to your existing estimate and invoice triggers.

Automations

Illustrated map of Dispatch workflow events, separating job events from visit events. The named events come from the Dispatch extension; this is not a screenshot of the trigger picker.

Illustrative local workflow trigger palette with Dispatch event names from the delivered extension registry. The current sample CRM does not expose this category, so verify the installed trigger picker before publishing.

Dispatch contributes its own triggers into your CRM's workflow engine, and workflows can create dispatch jobs in return. The follow-up text, the review request, the internal alert and the invoice draft all run on the same automation engine as the rest of your CRM, with no connector in the middle.

The restyled CRM workflow builder's Actions panel open to Dispatch, with options to create a job, add a visit, add a checklist, and invoice a job. The workflow shown is an unpublished sample.

It also adds job fields to four existing triggers - estimate_accepted, estimate_declined, invoice_paid and invoice_refunded - so a recipe can branch on the job behind a document rather than only on the document itself.

Field	What it holds
`event.dispatchJobId`	The job the document belongs to
`event.dispatchJobNumber`	The job number a person would recognise
`event.dispatchPropertyId`	The property the work is at
`event.dispatchServiceType`	The service type, or empty when the job has none
`event.dispatchJobStatus`	The job's status when the trigger fired

The two invoice triggers carry three more, because a payment on a deposit and a payment on a final balance are different events to you:

Field	What it holds
`event.dispatchInvoiceRole`	`deposit`, `balance`, `milestone` or `standard`
`event.dispatchParentInvoiceId`	The invoice this one is part of, when it is part of one
`event.dispatchPacketSettled`	True on the payment that clears the last part of a multi-part packet

dispatchPacketSettled is the one to filter on for "the job is fully paid, close it out". A rule on balance fires on the first balance part rather than the last, and a rule on the parent invoice never fires at all.

Example workflow recipe: an Invoice Paid event with a Dispatch job ID passes through a fully settled payment check before a chosen follow-up action runs.

If one of these fields is missing from an event, the job behind that document could not be resolved, and a condition testing it fails closed. A recipe waiting on a deposit does not fire on everything instead.

Two things to know when a workflow schedules the next visit:

A paid deposit does not announce itself. A workflow that adds a visit drops it into the board's Unscheduled strip. It does not move the job into the Needs scheduling bucket, which means something else - jobs still at lead that were never scheduled. Watch the Unscheduled strip, or the No upcoming visit marker in the jobs list.
Add dispatch visit cannot pin a technician. It can schedule a follow-up a set number of days out, but not onto the same person who did the first visit. Assign that on the board.

Loading the guide...

Did this answer your question?

Help us make the guides more useful.

0 helpful · 0 not helpful

Use the handbook and release notes included with your download for version-specific instructions.

All Seedly Dispatch docs Learn the foundations

Automations

Illustrated map of Dispatch workflow events, separating job events from visit events. The named events come from the Dispatch extension; this is not a screenshot of the trigger picker.

Illustrative local workflow trigger palette with Dispatch event names from the delivered extension registry. The current sample CRM does not expose this category, so verify the installed trigger picker before publishing.

The restyled CRM workflow builder's Actions panel open to Dispatch, with options to create a job, add a visit, add a checklist, and invoice a job. The workflow shown is an unpublished sample.

Field	What it holds
`event.dispatchJobId`	The job the document belongs to
`event.dispatchJobNumber`	The job number a person would recognise
`event.dispatchPropertyId`	The property the work is at
`event.dispatchServiceType`	The service type, or empty when the job has none
`event.dispatchJobStatus`	The job's status when the trigger fired

The two invoice triggers carry three more, because a payment on a deposit and a payment on a final balance are different events to you:

Field	What it holds
`event.dispatchInvoiceRole`	`deposit`, `balance`, `milestone` or `standard`
`event.dispatchParentInvoiceId`	The invoice this one is part of, when it is part of one
`event.dispatchPacketSettled`	True on the payment that clears the last part of a multi-part packet

Example workflow recipe: an Invoice Paid event with a Dispatch job ID passes through a fully settled payment check before a chosen follow-up action runs.

Two things to know when a workflow schedules the next visit:

A paid deposit does not announce itself. A workflow that adds a visit drops it into the board's Unscheduled strip. It does not move the job into the Needs scheduling bucket, which means something else - jobs still at lead that were never scheduled. Watch the Unscheduled strip, or the No upcoming visit marker in the jobs list.

Add dispatch visit cannot pin a technician. It can schedule a follow-up a set number of days out, but not onto the same person who did the first visit. Assign that on the board.