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

Raise an Error

Sometimes a flow has to stop and tell the customer why. PeakCommerce has three mechanisms that halt a flow, and only one of them lets you write the message. Choosing the right one matters, because they differ in where they run and how much control you have over what the customer reads.

Response gates — the one with your wording

A commerce action in a journey step can carry a response condition that inspects the result of the call and fails the step when the condition is not met. This is the mechanism to reach for when you want a specific message.

A response condition has four parts:

  • Field — the path into the action's response you want to test.

  • Operator — one of eq, neq, gt, lt, or contains.

  • Value — what to compare against.

  • Fail message — the text shown when the condition fails. This is yours to write.

A fraud check that returns a decline, an eligibility call that comes back false, an external service reporting a customer is out of contract — each becomes a gate with a message that says exactly what happened and what to do next.

Write fail messages for the person reading them. "We couldn't verify your billing address — check it and try again" beats "validation_failed".

Policy blocks

The Policy Engine stops operations that breach a ceiling — a discount above the cap, an order over the seat limit. Policy violations surface as a rejected request with a generated reason and are recorded in the audit log.

You do not author the message. Policies are for guarantees that must hold regardless of surface, so use them when the enforcement matters more than the wording.

Blocking business rules

A Business Rule scoped to a direction can mark a change as blocked. The customer is prevented from making it, and the flow receives a reason code rather than free text — again, not author-written wording.

Choosing between them

You want
Use

A specific message the customer reads

Response gate on the commerce action

A ceiling no channel can exceed

Policy Engine

To forbid a class of subscription change

Blocking Business Rule

Gotchas

  • Only response gates carry custom text. If a requirement is phrased as "show the customer this exact message", it is a response gate.

  • Response gates run on an action's response, so there has to be an action whose result you can inspect. They cannot test arbitrary state before anything has been called.

  • Policy blocks and rule blocks are server-side; response gates evaluate the response of a call the journey made. For a guarantee that must hold no matter how an order arrives, a policy is the stronger tool.

Last updated

Was this helpful?