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, the discovery tools 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
After discovery, the actions appear as drafts. Review and test them carefully before enabling — discovery is a starting point, not a final answer.
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 — for read-only actions with no side effects (lookups, checks, fetches). The AI runs them silently.
Confirm required — for actions that create, update, or delete data. The AI prepares the full payload, then pauses and asks the user to approve before firing.
Default to Confirm required for any write. The cost is one extra click; the benefit is preventing a category of mistakes that are expensive to undo.
For the full reference on governance policies — Automatic vs Confirm required, role-based gating, and identifier resolution — see the Policies developer documentation.
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.