Onboarding a client is one modal, one field, and a handful of statuses to watch. What actually takes the work is everything between “they signed up” and “they can act on their own account”. This page walks the whole path: sending the invite, reading the lifecycle honestly, seeing what the client sees on their own first run, and knowing exactly which steps you can finish and which ones only the client can close.
“Invite sent” and “client is live” are separated by a sign-up, an auto-attach, and a sync period the dashboard tracks for you. None of it needs you to refresh manually, but all of it is worth reading before your first invite.
One field: their email. Actionist emails the signup link from your business address through its own mail relay.
The invitation moves to “Accepted — awaiting org” the instant they finish sign-up, before their workspace exists yet.
Their workspace links to your reseller account on its own. The relationship status flips to Active.
Active does not always mean manageable yet. A short sync period can leave management access unavailable.
Once setup clears, View as client works, and you can start building their agents.
No day count anywhere. The invitation shows a real expiry date. Nothing in the product states a fixed number of days, so read the date rather than quoting one from memory.
Active isn’t always manageable. Watch the dashboard’s attention rail. It names exactly which clients still need setup to finish before you can act on their workspace.
An open tab can lag. The dashboard caches for three minutes, so a client who just signed up may not appear in an already-open tab until it refreshes.
When a client needs setup attention, the dashboard collects them into one rail rather than scattering the warning across the page: ” clients need setup attention”, followed by “Management access stays unavailable until setup finishes.” That is your cue that Active does not yet mean manageable for that client.
The whole flow lives on Overview. There is exactly one action button and exactly one field to fill in.
1
Open Invite client
Invite client is the only action button on the Overview page. Click it to open the invite modal, titled “Invite a client to Actionist”.
2
Enter the client's email
Type their address into Client email. That is the only field the modal renders. Older material may describe a company name field too, but nothing like it appears in the app, and there is nothing else to fill in before sending.
3
Send it
Click Send invitation email. The button reads “Sending…” while the request is in flight, then the modal shows a confirmation screen titled “Invitation sent”.
4
Watch it move
The confirmation shows Email, Status, and Expires. Track those same three values afterward from the Clients table as the invitation works its way to Active.
Overview → Invite client
Send invite
Invite a client to Actionist
We’ll email them a signup link that auto-attaches their workspace to your reseller account after successful sign-up.
Client email
We’ll send the invite from [email protected] via Actionist’s mail relay.
When they sign up through this link, they’re auto-attached to your reseller account. You’ll see them appear in Clients the moment they activate.
CancelSend invitation email
The modal renders exactly one field. There is no company name input to fill in, and nothing is sent to the backend beyond the client’s email address.
If you’re not sure whether you already invited someone, check the Clients table before sending again. Sending twice for the same address is what produces “A pending invitation already exists for this email.” below, not a bug worth chasing.
Five statuses cover the whole life of an invitation, from the moment you send it to the moment it either lands or lapses.
Status
What it means
What you do
”Pending”
Sent, not yet opened or acted on.
Nothing required. Resend only if the client says it never arrived.
”Accepted — awaiting org”
They finished sign-up, but their workspace has not attached yet.
Nothing required. This clears on its own once their organization finishes provisioning.
”Active”
The relationship is live and the client appears in Clients.
Check whether View as client is enabled yet. See the pipeline above. It may still be syncing.
”Expired”
The expiry date shown on the invitation passed before it was used.
Send a fresh invite. If it happens repeatedly for the same address, confirm you have the right email.
”Failed”
The invitation could not be sent or processed.
Send a fresh invite. If it keeps failing, contact Actionist support.
Never tell a client “you have N days to accept this.” No fixed number of days is defined anywhere in the product. Read the expiry date shown on the invitation itself, in the confirmation screen or in the Clients table, and go by that.
Most invitations move through these states without you doing anything. Where you actually intervene is at the ends of the path: resending after “Expired” or “Failed”, and checking in on an “Active” client whose management access has not cleared yet.
Six messages cover every way Send invitation email can fail. Each one tells you where to look first.
Message
Cause
Whose problem
”This email already has an Actionist account and cannot be invited through reseller signup.”
That address already owns an Actionist account outside the reseller flow.
Client’s. They should sign in directly, or reach out to you outside the invite flow to get linked another way.
”A pending invitation already exists for this email.”
You already invited that address and it has not resolved yet.
Yours. Check Clients or your recent invites before sending a second one.
”Enter a valid email address.”
The address you typed does not parse as a valid email.
Yours. Fix the typo and resend.
”Invitation limit reached. Try again in a few minutes.”
Too many invitations went out in a short window.
Yours. Wait a few minutes, then retry.
”Your reseller account isn’t certified yet, or this feature is disabled.”
Your reseller profile is not certified, or the feature is turned off for your account.
Yours. Confirm your certification status before trying again.
”Something went wrong.”
Any other backend error not covered above.
Actionist’s. Retry once, and if it repeats, contact support.
For a broader symptom index across the whole reseller programme, not just invitations, see Troubleshooting.
Three of these six are yours to fix directly: a typo, a duplicate send, or sending faster than the rate limit allows. Two point back at the client’s own account state. The last is the only one worth escalating rather than retrying repeatedly.
Once a client is in, Actionist runs its own onboarding: the Agent Onboarding studio. Knowing this flow means you can talk them through it, or pick up from wherever they stopped. Some clients finish it before you ever touch their workspace. Others hand it to you half-answered and expect you to carry on from Company Overview.
Before they even open it
A re-entry teaser greets them first: “Set up your agents”, with the line “Answer a few questions about your business and Actionist proposes the agents to build.” A single button, “Start”, is all it takes to open the studio itself, titled “Agent onboarding” with the subtitle “Review the company memory every agent reads, then work through your agents one at a time.”
Workspace provisioning
Their workspace comes online in the background while they answer setup questions. Three states cover it: Preparing, Ready, and Needs attention. The steps shown are “Creating your workspace”, “Waiting for your workspace to report in”, then “Your workspace is online”. Timing is described softly: “Usually ready in two to three minutes. You can keep working while it starts.” If it stalls, the copy is equally calm: “Agent setup carries on. Anything that needs the workspace waits until it is back.”This mirrors the reseller side of the same syncing period. The client’s workspace coming online and your management access clearing are two separate things happening at once, not one blocking the other.
Company Overview
Before touching individual agents, the client lands on a “Company Overview”: “The memory files written from your setup answers. Open any file to read exactly what your agents will know.” This is the shared context every agent reads from, worth pointing new clients to directly if they ask “what does it actually know about us?”
Each agent, in five parts
Every agent the client works through breaks into the same five groups:
Agent Instructions. Identity, remit and team from the accepted proposal.
Skills. Manual tasks, schedules and triggers.
Channels. Where this agent talks to the client’s team.
Advanced. Delegation, access control and approval mode.
Apps. Connecting the tools this agent uses.
The Apps group tracks readiness explicitly: ” of connected”, with “Each app still needs connecting before can use it without you.” until every one is linked, at which point it reads “Every app needs is connected.”
Confirming an agent
Once the five groups are in shape, the client confirms the agent: “Confirm this agent”, with the warning that “Confirming turns on and enables its schedules and triggers at the same moment.” Progress across the whole roster shows as ” of agents confirmed”, ending in “Every agent is live” once the last one is on.
Almost everything in a new client’s workspace is yours to prepare. One category never is: whatever needs the client’s own credentials or authorization. That control is disabled for any active delegated session, whatever scopes the client granted you, with the tooltip “Client action required”: “This app requires the client’s credentials or authorization to complete installation. Ask the client to install or connect this app directly.” Build your onboarding around that boundary instead of running into it mid-setup.
Prepare this yourself
Workspace goals and the roster of agents you’re proposing.
Agent Instructions: identity, remit and team for each agent.
Skills: which task packs each agent loads.
Schedules and triggers for recurring or reactive work.
Channels: where each agent talks to the client’s team.
Approval mode, under Advanced, for how much each agent runs unsupervised.
Only the client can do this
Every app connection and OAuth authorization, including the static API-key form.
Anything that touches an API key, token, or other credential.
Confirming an agent yourself, if you were never granted the scope to.
Connect app
Client action required
This app requires the client’s credentials or authorization to complete installation. Ask the client to install or connect this app directly.
Sit down with the client before opening the app. Get plain answers to what each agent is for and what “done” looks like, so the workspace you build matches a real business, not a template.
2
Prepare the workspace
Enter their delegated session once setup finishes. Draft the Agent Instructions, skills, channels and approval mode for each agent using what you agreed in step one.
3
Build the agents
Work through the five groups per agent. Leave Apps for last on any agent that needs a credentialed or OAuth connection, since that step waits on the client either way.
4
Request the connections
Hand the client the specific list of apps still needing their credentials or authorization. Point them at “Connect app” directly rather than describing it abstractly.
5
Test
Run each agent through its actual workflow once every app shows connected. Confirming turns on schedules and triggers immediately, so test before you confirm, not after.
6
Hand over and train
Walk the client through Company Overview and their own agents so they know what each one knows and does. Agree who checks in, and when.
Confirming an agent turns on its schedules and triggers immediately. Get through Test before you get to Confirm this agent, not after.
None of these six steps require anything you can’t do inside a delegated session, except the one that was never yours to do in the first place. Plan the connection request early, not as an afterthought once everything else is built.
Onboarding rarely happens for one client at a time. The habit that keeps their data from bleeding into each other is small: leave sessions the right way.
Exit a delegated session with the Exit button or the Escape key rather than navigating away or closing the tab. That is what clears the cached workspace data before you open the next client. Full detail on entering, reading the banner, and leaving cleanly lives on View as client.
This matters most in the middle of an onboarding run, when you’re moving between two or three new clients in the same afternoon. Skipping the exit step is how one client’s workspace data ends up lingering in view while you’re meant to be looking at the next one.
Three shapes an onboarding tends to take, depending on how ready the client is to hand over their own logins. None of these are guarantees, just patterns worth recognizing early so you can plan the week around them.
Omar · Agency owner
Sends the invite the same afternoon he closes the deal. By the next morning the client is “Active” and setup has cleared, so he spends most of the first week building agents in their workspace before asking for a single connection.
a straightforward week, once setup clears
Priya · Ops consultant
Gets three clients through certification and invites all three the same day, then works one Prepare the workspace at a time. Two clients connect their own apps within days; the third takes longer to get to it, so that agent stays on Needs attention until they do.
pace set by the client, not the dashboard
Declan · Small agency, solo
Prepares the whole workspace first, agents, skills, channels and approval mode, before ever asking the client for anything. When he finally requests the app connections, it is a short, specific list rather than an open-ended conversation.
One field to invite a client. No day count to promise, no credential you can ever see.
Read the status · watch the attention rail · hand the connection back when it’s the client’s to finish.
