End-to-end: cancellation flow

​

Before you start

​

What you’ll build

1. Identifies the customer on every message by looking up their email in your billing system, exposing their customer_id, plan, and an is_vip flag to the agent.
2. Cancels the subscription when the customer asks to, by calling your billing API with the customer’s ID and reason.
3. Orchestrates the conversation with a Rulebook tree that gates on intent, extracts the cancellation reason, calls the cancel Action, and replies with the confirmation details.
4. Holds VIP cancellations for human review by posting an internal note instead of replying directly when the customer is on an Enterprise plan.

​

Step 1: Configure the User Attribute

​

Step 2: Configure the Action

​

Step 3: Configure the Rulebook rule

Steps  (root)
├── Check: Topic Equals Cancellation
├── Read:  extract `reason` (String)
├── Check: customer_id Is Not Null
├── Tool:  Cancel Subscription
│     in:  customer_id, reason
│     out: confirmation_id, refund_amount, effective_date
└── Reply: confirm cancellation with refund details

1

Create a new rule

On Automations → Rulebook, click + Create Rule. Set the Name to Cancellation flow.

2

Write the Description carefully

The Description is how the LLM decides whether to fire this rule on a given customer message. A vague description (“Handles billing things”) will misroute messages or skip yours entirely. Write it like a trigger specification.For this walkthrough, paste this as your starting Description:

“Use this rule when the customer wants to cancel their subscription. The query could look like: ‘cancel my subscription,’ ‘I want to close my account,’ ‘stop charging me,’ or ‘I’d like to terminate my plan.’”

Tighten the example phrases over time to match how your customers actually phrase cancellation requests. Imagine you’re teaching a new teammate what triggers this rule, that’s the level of specificity to aim for.

The Description field is the rule’s only routing signal. If a customer’s message doesn’t seem to fire your rule in production, the Description is the first thing to revisit. You can confirm what the LLM did in the Planning section of the AI Steps trace, see the Test before publishing step below.

3

Add the intent Check

Click + Add step on the root Steps node. Pick Check as the node type. Configure:

• Name: Intent is cancellation
• Condition group: in the field picker, expand Tag Groups and pick Type of Issue (the default group) or your custom routing group (e.g., Topic). Operator Equals. Value Cancellation.

This is the deterministic backstop on the LLM’s routing. Even if the Description matches and the LLM picks this rule, the Check short-circuits if the conversation’s tag isn’t Cancellation. This protects against edge cases where the LLM routes overconfidently.

Set up the routing tag group first. Tag Groups are populated by the LLM after it classifies each conversation. For this Check to work, the tag group needs four things in place under Configuration → Tags: (1) Tag Group available in Rulebooks turned on; (2) Tag Selection set to “Exactly one tag” (otherwise use Contains, not Equals); (3) a Cancellation tag defined, with its description teaching the model when to apply it; (4) the group assigned to your agent under the agent selector. The default Type of Issue group ships with a Cancellation-style tag and is the path of least resistance; create a custom Topic group only if you need different categories.

4

Add the Read for the cancellation reason

Click + Add step again. Pick Read. Configure:

• Name: Extract cancellation reason
• Look at: Interaction History
• Find these details: field reason, type String
• Instructions: “Extract the customer’s stated reason for cancelling. Examples include ‘too expensive,’ ‘not using it,’ ‘product not working,’ ‘switching to competitor.’ If no reason is given, return an empty string.”

Concrete examples in the instructions dramatically improve extraction reliability. The Read populates a tree variable named reason that downstream nodes can reference as ${reason}.

Read or Form? Use Read when the customer typically volunteers the reason in their message (the cancellation case). Use Form when you need the reason structured for downstream reporting (e.g., dropdown of Too expensive / Not using it / Switching competitor / Other), or when the cancellation is sensitive enough that you want a typed, auditable record of the customer chose Reason X. The address-change example in Rulebook shows the Form pattern in full.

5

Add the customer_id Check

Click + Add step. Pick Check. Configure:

• Name: Customer is identified
• Condition group: in the field picker, expand User Attributes → pick customer_id. Operator Is Not Null.

This Check references the customer_id field that was exposed by the Customer Identity attribute in Step 1 (which is why it had Use in Rulebooks turned on). If the customer’s email lookup didn’t return a customer_id, they’re not in your billing system, or the API call failed silently, this Check short-circuits the rule cleanly instead of calling the cancel API with a null ID.

6

Add the Tool node and bind its inputs

Click + Add step. Pick Tool. In the configuration panel:

• Action: select Cancel Subscription from the dropdown (the Action you created in Step 2).
• Inputs: the panel shows the Action’s required inputs. For each one, pick where the value comes from:
  • customer_id → bind to customer_id (from the User Attribute)
  • reason → bind to reason (from the upstream Read node)

The binding is the load-bearing part. The dropdown for each input shows every tree variable available at this point in the tree, User Attributes, upstream Read outputs, upstream Tool outputs. Pick the one whose name and type match the Action’s input.Once you’ve bound the inputs, the Tool’s outputs (confirmation_id, refund_amount, effective_date) automatically become tree variables available to nodes below this one.

7

Add the Reply node

Click + Add step. Pick Reply. In the Instructions field, write:

“Tell the customer their subscription has been cancelled. Mention that a refund of ${refund_amount} will be processed by$, and give them the confirmation ID $ for their records.”

The ${variable} placeholders interpolate from the Tool’s outputs. The Reply node injects this as instructions into the agent’s reply-composition pass, the agent writes the final wording in its own voice, but the content (refund amount, dates, confirmation ID) comes from the bound variables.

Reply instructions don’t have to be the verbatim message to the customer. They’re guidance for the agent. “Tell the customer…” works better than copy-pasting the exact reply text, because it lets the agent maintain its voice while reliably surfacing the facts you specified.

Voice control lives elsewhere. Reply instructions are for content directives (“mention the refund amount”, “share the confirmation id”). For voice (“be formal”, “never apologize twice”, brand vocabulary), edit your agent’s Main Guidelines → Tone instead, those rules apply to every reply your agent sends, including the one this rule produces.

8

Assign to your agent

Under Assigned Bots, pick the same agent you attached Customer Identity to in Step 1. A rule with no agents assigned never runs.

9

Test before publishing

Open the ▶ Test Run panel from the rule editor. Two input modes:

• Conversation Link, paste a URL to a real conversation from your Inbox. Use this when you want to verify the rule behaves correctly on conversations you’ve already seen.
• Custom JSON, paste a JSON object describing a synthetic conversation context. Use this for edge cases.

Start with Custom JSON. Paste something like:

{
  "message": "please cancel my subscription, the product just isn't working for us",
  "user_attributes": {
    "customer_id": "cus_abc123",
    "plan": "Pro",
    "is_vip": false
  },
  "tag_groups": {
    "Topic": "Cancellation"
  }
}

Use the customer_id from the test you ran in Step 2’s Action, that’s a customer your billing API actually knows about. To test the VIP path you’ll configure in Step 4, set "is_vip": true instead and re-run. Click Run Test and walk the execution trace. A successful run looks like this:

What to verify:

1. The intent Check passes (green dot).
2. The Read populates reason with something like “product just isn’t working”.
3. The customer_id Check passes.
4. The Tool fires with the expected inputs and returns three output fields with real values.
5. The Reply interpolates the values correctly.

If a node shows a red dot, click into it to see what value it had. Reads not populating means the extraction instructions aren’t clear enough; Checks failing means the upstream data isn’t what you expected.

10

Publish

Save commits the draft. Publish promotes it to live. From the next conversation onward, your agent will run this rule on messages whose Description matches.

​

Step 4: Configure the Reply Behavior safety net

• Internal Comment lets the agent run the full Rulebook flow and draft a reply your team can review. The API call still happens. Useful when you want the work done but a human to vet the wording.
• No Reply would stop the agent from generating anything at all. The API call wouldn’t fire, the conversation would sit untouched, and you’d handle everything manually.

​

Verify the flow end-to-end

1. Non-VIP, cancellation intent. Send “please cancel my subscription, the product isn’t working for us” from a test customer whose is_vip is false. Within seconds, you should see a direct reply in the channel with the real refund amount interpolated from the Action’s output.
2. VIP, cancellation intent. Same message, but from a test customer whose is_vip is true. The Rulebook still runs, the cancellation API call still fires, the reply is still drafted, but the reply posts as an internal note instead of a direct customer reply. A human teammate can review and follow up.
3. Non-cancellation intent. Send “how do I add a new card?” from any customer. The LLM doesn’t route to your Cancellation flow rule (because the Description doesn’t match), the rule’s tree never runs, and the agent answers from its knowledge base instead. The intent Check inside your tree is a backstop for cases where the LLM does route here on a borderline message, it almost never triggers in normal operation.

• For tests 1 and 2: a green-dot trace through all five rule nodes, with the Tool node showing the real API output values.
• For test 3: the Planning section shows the LLM didn’t pick the Cancellation flow rule, and the Executed Rule section is empty, no rule ran, the agent answered from knowledge.

​

Lock it down with a regression test

​

What to vary

• Add a Form for structured reason collection. Replace the Read node with a Form node that gives the customer a dropdown of cancellation reasons plus a free-text “other” field. Read works when the customer volunteers the reason in their message; Form is better when you need structured, required input you can analyze later (e.g., reporting on cancellation reasons). The form’s submitted values become tree variables the Tool can reference. See Rulebook → A worked example: address change with Form.
• Chain multiple Tools. Add a Verify Refund Eligibility Tool before Cancel Subscription, gate the cancel Tool with a Check on the eligibility output, and handle the denial path with a Reply explaining why. See Rulebook → Chaining Tools.
• Different VIP definition. Replace the is_vip Equals True predicate with a tier check on plan (e.g., plan Equals Enterprise), or layer multiple conditions for tiered escalation.
• Stay silent for VIPs instead of drafting. Switch the Reply Behavior rule from Internal Comment to No Reply if you want the agent to not engage at all for VIPs, leaving the conversation entirely to humans.
• Add graceful recovery. Wrap the cancellation Tool in a Fallback whose second child is a Reply explaining what happened, so a failed API call gives the customer a useful response rather than escalating silently.

​

Troubleshooting

​

Related