Workflow actions
A workflow action defines what Solvimon does when a workflow fires. There are two action types: send a templated email to the customer, or deliver the trigger payload to one of your webhooks.
How it works
Actions belong to a workflow through workflow_id, and carry their own status. A workflow can hold several actions, and each one is activated independently, so you can add an action to a live workflow without it sending anything until you activate it.
The email itself is rendered and delivered by an email provider integration, so an action always references an integration_id and a template_name that exists on that provider.
Implementation
Invoice emails
Invoice actions carry an invoice block whose type must match the workflow’s invoice variant. include_pdf and include_payment_link apply to TO_FINAL and OVERDUE only:
include_customer_contacts_as_cc adds the contacts configured on the customer as CC recipients. It defaults to false, so the email goes only to the customer’s billing address unless you set it.
Payment and subscription emails
Payment and subscription actions take no per-type options beyond the CC behaviour. Set the variant and the matching configuration block:
Subscription actions use variant: "PRICING_PLAN_SUBSCRIPTION" and a pricing_plan_subscription block with the same single option.
Subject lines
The subject of a workflow email comes from one of two places, and the two are mutually exclusive. This matters most for localized templates: an action with no subject of its own used to fall back to a hard-coded English subject, which left the body localized and the subject not, so a translated email could never actually be finished.
use_template_subject sends no subject override at all, which leaves the subject to the template the provider renders. This is what a localized template needs: the subject arrives in the same language as the body, out of the same template. It defaults to true, so an action that sets no subject takes the template’s.
subject is the alternative: a fixed string used for every recipient, whatever language their template is in. Setting both explicitly is rejected with a validation error pointing at use_template_subject, so an action that currently carries a subject has to have it cleared to adopt the template’s.
Threading
Every workflow email carries an X-Entity-Ref-ID header that is unique to that send, derived from the action and the trigger that produced it. Mail clients that group by this header, Gmail in particular, would otherwise fold a customer’s successive invoices and reminders into a single conversation, hiding the newest message behind the older ones. Each email arrives as its own thread instead. There is nothing to configure.
Localized email templates
Set localize_template_names to true on a send-email action to send each customer the template in their own language. At send time the action appends the end customer’s locale to the template name (for example credit.invoice becomes credit.invoice_en-us) and looks that template up with your email provider. When no localized variant exists, the action falls back to the base template, so a missing translation degrades to the default language instead of failing the send.
This matches the behaviour of the legacy Paragon email integration, so platforms sending invoice emails in their customers’ languages can migrate to native workflows without losing localization. In Desk, the toggle sits in the send-email action settings.
Send a webhook
A SEND_WEBHOOK action delivers the workflow’s trigger payload to one of your registered webhooks, referenced by webhook_id in the action’s send_webhook block:
Combined with a usage-limit workflow, this produces usage.threshold_reached notifications carrying the customer, the metric, the threshold that was crossed, the resolved limit and the consumption, so your platform can react to usage events in real time.
Activate an action
Actions move between statuses through PATCH /v1/workflow-actions/{id}, not through dedicated transition endpoints:
Deleting removes the action outright, which is the right move for one that was never activated:
Via Desk
Actions live on the workflow’s detail page under Actions. The template picker lists the templates available on the selected email integration, so configure the integration before adding the action.
Edge cases
- The action
variantand the workflowtypemust agree. APAYMENTaction on an invoice workflow is rejected. include_payment_linkrequires a working payment setup. See Payment collections and the Adyen payment acceptor.- A missing template on the provider fails at send time, not at configuration time. The workflow still records a trigger; the failure shows up in the executions table in Desk.
- If you use
localize_template_names, make sure a localized template exists for every locale your customers use, or accept that those customers get the base template. The fallback is silent, so a missing translation shows up as a wrong-language email, not an error.
Related guides
- Email providers: Mailgun, SendGrid
- Workflow triggers