Candu Actions is currently available to select customers. If you're interested in wizards for your team, contact us.
Actions are the connections between your wizard and your product's backend. A wizard can only do what its available actions allow: if an action doesn't exist, the wizard can't call it. So actions get set up before you build the wizard.
This article covers identifying which actions your wizard needs, getting them into Candu, and testing them.
Who does what. Setting up actions usually involves two roles:
You (the wizard designer) identify what the wizard needs to do, define the action set, set governance policies, and test the actions in practice.
Your engineering team provides the technical details for each action — endpoint, method, parameters — or grants Candu access to discover them automatically.
This article walks through the parts you own, and tells you what to ask engineering for when you need their help.
Start with what the wizard needs to do
Before creating actions, write out the workflow in plain language. For each step, list what the wizard needs to do, expressed as verbs:
Get the user's current plan
Check whether a segment has members
Fetch content details
Create a new segment
Update a setting
Each verb is usually one action. This list is your minimum action set.
Check whether the actions exist
Go to Actions → All Actions and review what's already available. Some of what your wizard needs may already be set up from earlier work. Note which existing actions cover which steps.
If actions are missing, you have two paths to add them.
Path 1: Discover actions automatically
The fastest path. If your engineering team has connected your codebase to Candu via Code Chat, Candu can scan your repositories, find API endpoints, and create draft actions for review.
This is best when:
The backend endpoints already exist in your code
You want to start with broad coverage and refine
You're working on a wizard for an established workflow
If Code Chat isn't connected yet, that's an engineering setup task. Share the Code Chat setup guide with your team to get it wired up, once it's connected, action discovery happens through this same flow.
Path 2: Set up actions manually
When discovery isn't available, you'll work with engineering to create actions one at a time. For each action, you'll need from engineering:
Action name — a clear human-readable label
Method —
GET,POST,PUT,DELETEEndpoint — the URL pattern, e.g.
/api/users/{id}/planInput parameters — what data the wizard needs to send
What the action returns — so you know if the response gives the wizard what it needs
A short worked example of what to ask engineering for:
"I'm building a wizard that troubleshoots why content isn't showing for a user. I need three actions:
Get user plan — looks up a user's subscription.
GET /api/users/{id}/planCheck segment membership — checks if a user is in a segment.
GET /api/segments/{id}/members/{userId}List recent content events — shows what content the user has seen.
GET /api/users/{id}/events?type=content
Can you send me the endpoint details and a sample response for each?"
A template like that gives engineering everything they need to deliver, and saves you a back-and-forth.
Create the action in Candu
Once you have the details, go to Actions → All Actions → New action.
Fill in the fields:
Action name — use a clear verb + noun pattern: Get User Plan, Create Segment, Fetch Content Details
Description — plain language explanation of what the action does
Method, endpoint, inputs — from engineering
The description matters more than it looks. The AI uses it for intent matching — if the description is vague, the AI is less reliable at picking the right action. Be specific.
For the full action schema and field reference, see the Actions developer documentation.
Set governance carefully
Every action has a governance policy. Choose based on what the action does to your data.
Automatic — the AI runs the action silently the moment it decides to use it. The user doesn't see what's about to happen.
Confirm required — the AI prepares the full payload, then pauses. The user sees exactly what will happen — which fields, which values, which endpoint — and clicks Confirm or Cancel before anything fires.
The governance choice isn't just operational — it shapes user trust. Automatic is fine for reads (looking up a plan, fetching segment data) where there's no risk if the AI picks the wrong action. It's risky for writes (creating an invoice, deleting a segment) where the AI might pick the wrong action, send wrong inputs, or fire at the wrong moment — with no chance to catch it.
Default to Confirm required for anything that creates, modifies, or deletes data. Make Automatic on a write the exception, not the rule.
Restrict actions to specific roles (optional)
Some workflows need stricter access, for example, only admins should be able to delete segments, or only managers should approve invoices. Candu Actions supports this via role gating: an action can be configured so it's only available to users with a matching role.
Role gating is configured by your engineering team. They pass the user's role to Candu at session start, and you flag which roles can use which actions. See the Policies documentation for the full technical details.
If you don't need this, leave actions visible to Everyone — that's the default and is the right choice for most basic wizards.
Test each action before using it
Don't trust an action just because it's configured. Run it with realistic inputs and confirm:
The action runs successfully
The response includes the data the wizard actually needs
Required inputs are clear and the wizard can recover from missing ones
The governance policy is appropriate
This step catches the most common class of wizard problems: an action that looks right in config but returns an unexpected payload or fails on real data.
If an action doesn't return what the wizard needs, fix the action first. Don't paper over it in the wizard's instructions.
Scope actions per step, not globally
Once your actions exist in the workspace, they still need to be selected inside each wizard step. The wizard can only use actions you've explicitly given it at that step.
Think about actions in two layers:
Workspace level — which actions exist
Step level — which of those actions a given step can use
Best practice: include only what a step actually needs, and remove write actions from later steps once they're no longer relevant. This keeps the AI focused and reduces the chance of it calling the wrong thing.
Common mistakes
Building the wizard before the actions exist. The wizard can't do anything its actions can't do.
Skipping the test step. Configuration is not the same as working.
Action descriptions that are too vague. The AI relies on descriptions to know when to call an action. "Get data" tells it nothing; "look up a user's subscription plan and renewal date" tells it everything.
Too many actions per step. More choices reduces AI reliability. Keep each step's action list tight.
Letting writes run automatically. When in doubt, require confirmation.
Next
Once your actions are set up and tested, read Build your first wizard to configure the wizard that uses them.