Actions
Every action, process and walkthrough the assistant can offer a customer, and which of them you allow. Three tiers of risk, two allowlists that work in opposite directions, one tier with no allowlist at all, and what ships on.
/admin/ai/support/workflows. This screen answers a question you should be able
to answer instantly and previously could not: what can this thing do to my
customers' accounts?
Three tabs, left to right in order of decreasing reach: Actions, Processes and Walkthroughs. Each carries its own master switch in its section heading and a search box above its list; Processes and Walkthroughs add status chips, and Actions does not, because an action is not individually switchable and "enabled" and "disabled" would be the same list twice. Processes and walkthroughs are grouped into six areas — account, wallet, trading, investment, commerce, other. The search and the status filter are shared across the tabs, and the number on each tab is the count you are currently looking at, so a tab label and the list under it can never disagree.
Actions and processes require MashDiv AI. Walkthroughs do not.
An action changes something on a customer's account and a process chains several together, so both are metered, audited and reconciled — and that accounting only exists on the gateway. On a self-managed key the switches on the first two tabs save and the assistant offers nothing; the Processes tab says so, with a link to the Provider screen.
Walkthroughs are not tied to a provider. A walkthrough writes nothing, so it needs no accounting, and all 21 are offered on any provider. Withholding them would be a paywall dropped across an arbitrary feature.
The honest way to read this screen: the last tab is free, the two before it are what you switched MashDiv AI on for.
Three tiers, and they are not equally risky
| Tier | What it is | Catalogue | Ships |
|---|---|---|---|
| Actions | A single step it can offer to take on the account | 3 | Off |
| Processes | Several actions carried across a conversation | 19 | Off |
| Walkthroughs | The assistant shows a customer where a screen is and what to press | 21 | On |
A walkthrough cannot write. It points, it explains, and the customer does the thing themselves. That is why it is the only tier on by default: the worst outcome of a wrong walkthrough is a confused customer, not a changed account.
Actions and processes ship off. Nothing happens because you installed the addon.
The Actions tab also states, above the list, the four rules that decide what may be on it at all — reversible, non-financial, never an authentication factor, and no parameters supplied by the model. A sweep of roughly forty user-facing mutations on this platform produced three entries and nothing else; the refusals are the argument, which is why the rules are printed rather than the count.
Allowlists: one empty-means-none, one empty-means-all, one that does not exist
This trips people up, so it is stated plainly, tier by tier.
Actions have no per-item allowlist. There is one switch,
aiSupportOperationsEnabled, and it governs the whole catalogue. You do not tick
actions individually and the cards carry no switch — there is no
aiSupportOperationKeys setting to hold your choices. Each card shows the
action's label, a Needs a second factor / No second factor badge, the
exact sentence the customer will be shown on the confirmation, and the action's
key in monospace.
Processes are empty-means-none. aiSupportWorkflowKeys starts empty and
nothing runs until you tick it — including anything a future update adds, which
stays off until you tick that too. Because ticking nineteen boxes one at a time
is nineteen chances to stop halfway on a list where half-finished is a
configuration nobody chose, there is an Enable every process button beside
that rule.
Walkthroughs are empty-means-all. aiSupportGuideKeys starts empty, which
means every walkthrough in the catalogue including any a future update adds. Two
edges follow from that and the screen handles both for you:
- Unticking the last remaining walkthrough would write an empty list, which means all of them. So the master switch goes off instead and the screen tells you that is what happened.
- Ticking every box would freeze today's catalogue and an upgrade's twenty-second walkthrough would arrive switched off for an operator whose stated position is "all of them". So it collapses back to the empty list.
The asymmetry between the last two follows the risk: the tier that can change an account is opt-in item by item, the tier that cannot is opt-out.
Turning an action on
-
Switch the Actions tier on. One switch, all three actions. This is a Super-Admin control.
-
Switch the Processes tier on if you want processes, then tick the ones you want. Read what each does — the card names every step in order, marks each one as an action, a page or a walkthrough, and shows the words the customer will read, rather than an opaque key.
-
Watch for the badges. A process tagged Needs the addon cannot be enabled unless that addon is installed; its switch is disabled and, where the store slug is known, a Get this addon button appears. The Unavailable status chip filters the list down to exactly those.
Every operation step in a process runs a runner from the actions allowlist, so
a process on an install with aiSupportOperationsEnabled off is a sequence whose
steps cannot execute. The backend enforces this where the tool spec is built, so
such a process is never offered and never started — but the Processes tab does
not currently call it out the way it calls out a missing provider. If you
have ticked processes and none is ever offered, check the Actions switch first.
An action is offered, not executed silently. The assistant proposes it, and the customer confirms it from their own session. Your operators are not in that loop and neither is the model — which is why an action the assistant gets wrong becomes a declined offer rather than an incident.
What ships on, and why you should look at it anyway
The walkthrough catalogue is enabled at install, and it is worth reading once. Every entry describes a real screen in your platform; if you have disabled a feature — say you do not run P2P — a walkthrough for it is a walkthrough to nowhere. Narrow the list to what your install actually has.
Each card shows the page the walkthrough runs on and how many stops it makes; press the stop count to read them. A walkthrough badged Uses the page's own tour starts the terminal's built-in onboarding rather than authoring its own, so a stop count of zero there is correct rather than missing.
Customers are also filtered individually: before a walkthrough is offered, its route is resolved against that customer's own session exactly as a link would be. A walkthrough of a page their verification level cannot enter is never offered rather than offered, pressed and bounced.
Turning everything off
Opening this screen needs access.ai.support.settings — the same key as the
Settings screen, because every request it makes is one of the settings routes or
a catalogue those routes share.
Within that, the Actions and Processes master switches and the process allowlist are Super-Admin only, and this screen is where they are changed. An ordinary administrator sees the current value with a padlock and the note "A Super Admin control, changed in system settings." rather than a control that silently refuses to save. The walkthrough switch and its allowlist are not protected — any administrator who can open this screen can narrow or widen that tier.
Every change saves the moment you throw the switch. There is no save bar and nothing to lose by leaving the page; a refusal can only ever be about the one control you touched.
Switching the Actions tier off makes actions and processes inert, whatever is ticked, because processes are built out of actions. Switching the Processes tier off makes only processes inert, and the tab says so once at the top — "Processes are switched off, so nothing ticked below is offered to anybody. What is ticked is kept." — rather than dimming nineteen cards individually. Nothing you have ticked is lost either way.
aiSupportAccountToolsEnabled on Settings is often mistaken for
a master control over everything here. It is not. It gates the three account
read tools — the customer's balances and verification state, their recent
transactions, and their activity in a given area — and the admin-side Ask about
this customer rail. It does not gate offers, processes or walkthroughs: an
action runs under the customer's own session and never needed the assistant to
read their account in the first place.
If what you want is an assistant that answers questions and touches nothing, turn account tools off and leave the Actions tier off. Turning off account tools alone still allows a customer to be offered — and to confirm — an action.
Related: Catalogues for every action, process and walkthrough entry with its gate, and All settings for the full protected list.