Onboarding invited teammates and accounts set up with help
Preserve invitation context, separate shared setup from personal progress, and give invited users and assisted accounts a clear first task.
In this article
Onboard an invited teammate from the work already prepared for them. Preserve the intended account and task through sign-in, check their permissions, and separate shared setup from that person’s first useful action. For accounts prepared by a colleague or specialist, show what is ready, what still needs confirmation, and who can resolve each remaining dependency.
An administrator spends the morning importing projects and setting permissions. After lunch, a colleague follows an invitation to review one of those projects. The first screen asks them to create a workspace.
The product has treated a new person as a new account. It is a small distinction in an onboarding diagram and a large one for the person being asked to repeat work.
The invitation is the beginning of the experience
An invitation should let its recipient understand why they are being contacted and what accepting will let them do. The necessary detail depends on the work and its sensitivity. A project name may be appropriate in one setting and too revealing in another. But a generic “You’ve been invited” leaves the person to reconstruct the purpose.
Preserve the destination through account creation and sign-in. If the user needs to authenticate, treat that as a step on the way to the assigned work. Do not silently turn it into a choice to create a separate workspace.
Slack’s joining instructions describe accepting an invitation and setting up an account for that workspace. The workspace context is part of joining, rather than a detail to recover after registration. Your product may have a different identity model, but the same design question applies: what context should survive authentication?
For a document reviewer, it may be the document and their review role. For a new operator, it may be a queue of assigned work. Land them there once access is authorized, and explain the immediate action. They can discover the wider product when they need it.
Shared setup and individual work need different records
Consider an illustrative planning account. An owner has connected a data source, imported projects, and invited two planners. One planner has reviewed their assignments; the other has not yet opened the invitation.
If onboarding progress belongs only to the account, both planners may appear finished. If all progress belongs only to individuals, both may be asked to import the same projects again. Neither representation describes the work accurately.
Track shared conditions at the account level and personal actions at the individual level. Then use both to decide what to show.
| Person arriving | Shared account condition | Useful first destination |
|---|---|---|
| Planner | Projects imported and access granted | Their assigned projects |
| Planner | Import still running | Import status and any work available meanwhile |
| Administrator | Connection needs authorization | The specific permission decision |
| Approver | A review is ready | The item awaiting approval |
| Owner after assisted setup | Projects prepared, sharing undecided | A summary with the remaining sharing choice |
Roles alone are not enough. An administrator can also be a planner. Prefer the purpose of this visit where you know it, while keeping permitted routes to other work visible.
Account readiness should mean that prerequisites are satisfied. Personal activation should refer to a useful action by that person. You may need both measures, but they answer different questions.
A blocked user needs a handoff
Permission problems are easy to mislabel as onboarding problems. A contributor may understand exactly what to do but lack authority to connect the required system. More education will not change that.
Slack’s invitation documentation provides a concrete example: members who lack permission to send invitations can request them, and receive a notification when an administrator approves or denies the request. The design supports a transfer to someone who can act.
Use that principle for your own dependencies. “Ask an administrator” is incomplete if the user does not know which administrator or what to ask for. Where supported, offer a request that identifies the missing permission and the relevant account. Let the user see whether the request is pending, approved, or rejected.
Do not show a setup task as merely incomplete when it is waiting on another person. That makes the current user look responsible for a delay they cannot resolve. It also makes reminder emails more likely to target the wrong recipient.
Useful waiting states can include the work still possible: drafting a project, checking sample data, or reviewing an existing configuration. Be explicit when the result is provisional or based on sample content.
Assisted setup should leave a readable receipt
A specialist can prepare an account without making every decision for its owner. The handoff needs to distinguish work already performed from choices still awaiting confirmation.
In the planning example, imagine a specialist imports project names and proposes notification recipients during implementation. When the owner first signs in, a useful page says which projects are available and asks them to review recipients before sharing. It links to the actual configuration. A blanket “Setup complete” would conceal the outstanding choice.
Show consequential defaults in a place where they can be checked and changed. Make it clear who will receive an announcement, which data source is connected, or what will become visible when the owner proceeds. Record confirmation separately from preparation when the distinction matters.
The summary should remain available after the first session. The colleague who takes over next week may not have attended the setup call. Product state should carry the handoff, rather than requiring someone to reconstruct it from a meeting or a private message.
This also gives support a better starting point. “The import finished; recipient confirmation is pending” describes a recoverable state. “The customer did not complete onboarding” does not.
Try the invitation from the recipient’s starting point
The account creator is a poor stand-in for an invited teammate during usability testing. They know why the account exists, which work is available, and what happened during setup. The invitee may know none of it.
Give participants the context a real recipient would have, including any prior discussion of the project and their expected contribution. Withhold the creator’s knowledge of how the setup was implemented. Observe whether they can identify the account, reach the intended work, and complete their task. Include a wrong signed-in identity and an expired or revoked invitation in the review. These paths need recovery that preserves the intended destination without granting unauthorized access.
Measure the handoff in stages: invitation sent, accepted, access established, useful task completed. A high acceptance rate can coexist with an unusable destination. Conversely, an account may take time to prepare but give an invited colleague a fast first result once ready.
When the planner finally opens the project, they should see the work their colleague prepared and the review that needs their attention. That is where their onboarding begins.
The invitation journey also depends on the workspace choice. Compare joining an existing workspace with creating a new one so the next step matches where the customer’s work belongs.
