For the complete documentation index, see llms.txt. This page is also available as Markdown.

Commerce Actions

Commerce actions are the operations a journey step performs when a customer advances — the work behind the screen. A single step can run a fraud check, create or update an account, create an order, convert a lead, capture a payment method, record the order in PeakCommerce, and more. Each step runs its actions in order the moment the customer moves forward.

Open them in the journey builder: Content → Journeys → Edit → Steps, expand a step, and look under Commerce actions.

Anatomy of an action

Each action has:

  • Target — where it runs:

    • Internal — runs inside PeakCommerce with no external integration attached (integrationId stays null). These are PeakCommerce's own writes — for example create organization, update contact, and record order.

    • Integration — calls a connected system (Zuora, Salesforce, SEON, …). You pick the Integration and the Operation it performs.

  • Operation — the specific operation to run. Common operations include:

    • create_order — place a new order / subscription.

    • update_order — amend an existing subscription (used by change-plan steps; targets an account + subscription).

    • cancel_order — cancel a subscription via the Orders API, so the cancellation is recorded as an order that can carry custom fields mapped from context (for example the captured cancellation reason → CancellationReason__c).

    • update_account, fraud_check (integration actions), and the internal create organization, update contact, and record_order.

  • Execution mode:

    • Blocking — must finish before the next action starts. Use when a later action depends on the result (you can't create an order before the account exists).

    • Async — dispatched in turn without holding up the next action. Use for fire-and-forget side effects.

  • Order · Condition — the action's position in the run order, plus an optional condition that decides whether it runs (for example always, or only when a given field is present).

  • Field mapping — how the operation's inputs are filled (see below).

Run order

Actions run top to bottom. Drag the handle to reorder them. Because blocking actions must complete before the next begins, order matters — a typical checkout step runs fraud check → create account → create order → … Async actions are dispatched in turn and don't hold up the sequence.

Field mapping

Each action maps source values into the operation's destination fields:

  • Source — where the value comes from:

    • Context — a value produced earlier in the journey (a previous step's output variable).

    • Literal — a fixed value you type.

    • Dynamic / Expression — a computed value.

    • Object / JSON — a structured value.

  • Destination — the operation field the value fills.

For example, the internal record order action maps totalRecurringCents → netMrrCents, email → customerEmail, and a literal journey → source. The builder validates these routes, so the operation's required destination fields must be supplied before you can save the action.

Required actions (locked)

Some actions are required by the step's role and appear locked with a 🔒 Required badge. You can drag to reorder them, but you can't remove them.

Required actions guarantee that PeakCommerce always performs its own internal writes — creating the organization, updating the contact, and recording the order — so your PeakCommerce records stay correct and complete regardless of what the external billing system does or returns.

"Required" is a posture the step's role assigns: when you give a step a role (for example Payment), the role brings its mandated set of internal actions with it, already configured and locked. See Step Roles.

Internal and integration actions — why both

PeakCommerce models commerce natively and also syncs to your connected systems of record. The integration actions push to whatever billing, CRM, and risk systems you've connected — for example creating the subscription in your billing system (such as Zuora or Stripe), creating the account in your CRM (such as Salesforce), or running a fraud check (such as SEON). The internal actions make sure PeakCommerce's own order, contact, and organization records are written authoritatively. Together they keep PeakCommerce and your downstream systems in lockstep — and let the journey keep working even while a given integration is still being deepened.

Add or edit an action

  • Add action — at the bottom of a step's action list. Choose the target, operation, and execution mode, then map the fields.

  • Edit action — opens the action editor for an existing action.

  • Required (locked) actions can be reordered and re-mapped, but not deleted.

Click Done, then Publish the journey to make your changes live.

Last updated

Was this helpful?