Skip to main content
Complete reference for building automations in Alguna. This page documents every trigger, the data each one carries, every action and its parameters, the step types, the template syntax, and the condition expression language. Automations are built in the dashboard, in the visual automation builder. There is no public automations API: the values on this page are the identifiers the builder and the engine use, and knowing them helps you read execution logs, write conditions, and reference data between steps.

Anatomy of an Automation

An automation is a named container. Each automation holds one or more versions, and each version holds:
  • exactly one trigger — what starts a run
  • a set of steps — what the run does
  • the paths between steps, each optionally guarded by a condition
Only one version is active at a time. Editing an active automation mints a new draft version rather than mutating the running one.

Trigger Types

Every trigger is one of two types. Both types accept an optional condition and an execution policy. See Trigger filtering below.

Event Trigger Types

There are twelve event trigger types.
These are not the same as webhook events. Webhook subscriptions use a separate, larger catalogue of events (invoice.paid, subscription.activated, and so on) and cannot be used as automation triggers. Automation triggers use the snake_case identifiers above.

Event payloads

The fields below are the trigger’s event data. Reference them from a step as {{trigger.inputs.<field>}}, and from a trigger condition by their bare field name.

payment_failed

card_expiring

invoice_status_updated

status is one of: draft, upcoming, pending_approval, scheduled, processing, issued, void, paid, canceled, overdue.

prepaid_usage_update

credits_depleted

subscription_sent_for_signature

quote_signed

subscription_status_updated

status is one of: draft, sent, accepted, active, canceled, paused, pending_approval, rejected, withdrawn, expired.

subscription_renewal_window_entered

flow_session_completed

salesforce_opportunity_changed

hubspot_deal_changed

Each entry in changedFields is keyed by the CRM field name and holds a before/after pair, so a condition can read changedFields.Amount.after.

Trigger Filtering

A trigger has no separate filter language. Narrowing happens in two places.

Condition

An optional condition attached to the trigger. It is a set of expr expressions combined with and, or, or not, evaluated directly against the event payload’s top-level fields.
If the condition is not satisfied, no run starts.

Execution policy

With once, you also pick an event field key — a field from the event payload, either a top-level key (accountId) or a dot path into a nested object (changedFields.Amount.after). The first event carrying a given value runs the automation; later events carrying the same value are suppressed. Suppression is scoped to the automation, not to the version, so editing an automation does not reset its history and re-fire values it has already handled. Some event types refine the slot further — prepaid_usage_update scopes suppression to the commitment period and the prepaid price, so a customer can be alerted again in the next period.

Schedule Triggers

A schedule trigger carries one of two shapes.

Calendar

The shape the builder writes. Each field is a list of { start, end, step } ranges; the schedule fires at every point matching all of them.

Interval

Automations do not accept cron expressions. A schedule is either a calendar or an interval shape; there is no cron field anywhere in the trigger model.
Duration units are seconds, minutes, hours, days, weeks, months, quarters, years.

Step Types

The automation builder currently offers action, condition, and delay steps. for_each and do_until are executed by the engine and appear in automations that use them, but are not yet offered as choices in the builder.

Delay steps

A delay carries a duration and a unit — seconds, minutes, hours, days, weeks, months, years in the builder.

Condition steps

A condition step has no “then” and “else” fields of its own. Instead it fans out into branches, and each outgoing path carries its own condition expression. A path with no condition is the fall-through.

for_each steps

do_until steps


Actions

There are twenty-six actions. The action list is a closed set — you cannot register a custom action. Parameter names below are exactly as the engine serializes them. Note that a few CRM parameters end in a capitalised ID (recordID, integrationID, planID); the rest use Id.

Notifications

send_email

Sends a generic, customizable email to a customer.

send_slack_message

Sends a Slack message to a selected Slack channel. The workspace and channel are picked from connected Slack integrations rather than templated. If no Slack workspace is connected, users who can manage integrations can connect Slack inline from the action form; others are directed to Settings → Integrations.

send_webhook

Sends an HTTP POST request with a JSON body to a specified URL. headers is a flat map of string header names to string values.

send_billing_info_request

Requests billing information from a customer via email. Shares a link to the customer portal via email.

Payments

send_card_expiration_reminder

Emails the customer a reminder that their stored card is expiring, with a link to update it.

Invoicing

retry_invoice_payment

Retries payment for a failed invoice using the default payment method. Outputs: invoiceId, paymentMethodId, paymentId, status, failureReason.

send_invoice_reminder

Sends a reminder email for an issued or overdue invoice.

send_invoice_reminders_bulk

Sends reminders for a list of invoices based on a set of filters. Outputs: sentInvoices, failedInvoices, skippedInvoices.

Subscriptions

cancel_subscription

Cancels a customer’s active subscription. Outputs: subscriptionId.

send_subscriptions_autorenewal_notification_bulk

Sends auto-renewal notifications for a list of subscriptions based on a set of filters. Outputs: sentSubscriptions, failedSubscriptions, skippedSubscriptions.

Quotes

send_subscription_signature_reminder

Sends a reminder email for a subscription that requires signature.

create_quote

Mints a new, renewal, or amendment quote for an account, optionally linking it to a CRM opportunity. Outputs: created, quoteId, subscriptionId, opportunityId, reason.

activate_quote

Marks a quote’s subscription signed offline, mirroring the dashboard’s manual offline-sign action. Outputs: activated, quoteId, subscriptionId, reason.

CRM

These actions require a connected CRM integration.

get_crm_opportunity

Reads a CRM opportunity and the Alguna account and quotes it correlates to. Outputs: opportunityId, externalId, name, stage, amount, currency, closeDate, ownerName, url, accountId, externalAccountId, quoteId, linkedQuoteIds.

create_crm_record

Creates or updates the quote’s CRM record of the requested object type, or an account-anchored expansion Opportunity. Outputs: created, updated, skipped, externalId, opportunityId, reason.

update_crm_record

Writes billing and quote facts onto the subscription’s linked CRM opportunity. Outputs: updated, skipped, opportunityId, reason.

set_opportunity_stage

Moves the stage of the opportunity linked to a quote. Opt-in only — use it when no CRM workflow already moves the stage for you. Provide exactly one of subscriptionId, quoteId, or recordID to address the opportunity. Outputs: updated, skipped, opportunityExternalId, reason.

create_quote_from_opportunity

Mints a draft quote for a CRM opportunity’s customer and links the two, importing the customer when the deal has none here yet. Outputs: created, quoteId, subscriptionId, opportunityId, accountId, reason.

void_open_quotes_for_opportunity

Withdraws every open quote linked to a CRM opportunity, cancelling their pending signature sessions. Outputs: opportunityId, quotesVoided, quotesSkipped, reason.

cancel_renewal_for_lost_opportunity

Schedules a subscription to stop auto-renewing at its current contract end date when its renewal Opportunity is marked lost in the CRM. Outputs: scheduled, subscriptionId, effectiveDate, reason.

Lookups and general

get_invoice

Retrieves details of a specific invoice. Outputs: the invoice fields listed under Invoice shape.

get_invoices

Retrieves a list of invoices based on filter criteria. Outputs: invoices — an array of the invoice shape.

get_subscription

Retrieves details of a specific subscription. Outputs: the subscription fields listed under Subscription shape.

get_subscriptions

Retrieves a list of subscriptions based on filter criteria. Outputs: subscriptions — an array of the subscription shape.

set_tags_on_entity

Sets tags on an invoice, subscription, or customer. Outputs: entityType, entityId, tagIds.

Object Shapes

The lookup and bulk actions pass around reduced invoice and subscription shapes. These are the fields available on step outputs.

Invoice shape

id, accountId, subscriptionId, currency, status, amount, amountPaid, amountDue, issueDate, dueDate, overdueDays, dueInDays, autoPay, paidDate, voidDate, tagIds.

Subscription shape

id, name, accountId, status, currency, contractPeriodType, contractDuration, contractStartDate, contractEndDate, activatedAt, endedAt, autoRenew, renewalPeriodType, renewalDuration, cancelationReason, daysUntilRenewal, signedByCustomer, customerName, acv, arr, mrr, tagIds.

Template Syntax

Action inputs and path conditions can reference values produced earlier in the run. A reference is a dotted path in double braces, and it always has at least three segments: the source, inputs or outputs, and the field.
A value that is entirely one reference resolves to that value with its type preserved — an array stays an array, a number stays a number. A reference embedded inside a longer string is substituted into the string:
References also work inside nested objects and arrays, such as the cta object on send_email.
There is no filter pipeline. {{ amount | currency }}, {{ now }}, and {{ secrets.KEY }} are not supported — a reference is a path into the run’s data and nothing else. Secrets belong in the connected integration, not in an automation input.

Condition Syntax

Conditions use the expr expression language. A condition is a list of expressions plus a logical operator that joins them. Trigger conditions are evaluated against the event payload, so fields are referenced by bare name. Path conditions are evaluated after template references are resolved, so they reference step data with {{...}} paths.

Comparison operators

The builder also offers is null / is not null for scalar fields, and contains, does not contain, is empty, is not empty for array fields.

Logical operators inside an expression

Collections and null

An identifier that is absent from a sparse change payload resolves to nil rather than failing to compile, which is what makes changedFields.Amount.after safe to write against CRM change events that carry only the fields that changed. An expression that cannot be evaluated against the payload is treated as not satisfied.

Execution Outcome Reasons

Actions that may legitimately write nothing report a reason on their output instead of failing. Reading these in the execution log tells you why a run did less than you expected. already_active, already_automated, no_linked_opportunity, no_crm_integration, already_created, already_signed, already_void, already_expired, already_rejected, subscription_active, not_a_renewal_opportunity, already_cancelled, cancellation_already_scheduled, already_renewed, expansion_already_open, no_active_subscription, ambiguous_subscription, no_opportunity_link, stage_already_set, stage_owned_inbound.

Failure Handling

Automations have no per-step retry or fallback configuration. Behavior on failure is fixed:
  • Invalid inputs — a required parameter missing, or a template reference that cannot be resolved — fail the step permanently. There is no retry.
  • Execution failures — a downstream service being briefly unavailable, for instance — are retried automatically by the workflow engine.
  • Outcome reasons are not failures. An action that reports skipped with a reason has succeeded; the run continues.
To branch on an action’s result, read its outputs in a following condition step rather than reaching for an error handler.

Next Steps

Automation Overview

Getting started with automations.

Triggers

Learn about trigger types.

Actions

Explore available actions.

Conditions

Build conditional logic.