Client onboarding
Turn a won opportunity into a reviewed, assigned kickoff checklist.
Updated October 6, 2026 4 min read
Winning the work is the beginning of delivery. This plugin helps a team carry the customer’s context into the tasks needed to start the project, without copying the deal into another system.
Complete your first checklist
Enable Client onboarding in Apps & connections, then open Client work → Client onboarding. You need an authorized workspace, a won opportunity and valid task assignees. The plugin starts disabled and has no extra provider credentials or public settings.
- Select the won opportunity that the work belongs to.
- Enter one to ten tasks, each with a title, description, due date and assignee.
- Choose Review workflow and check the source, dates and owners. Choose Request approval for that exact version.
- Choose Approve & create tasks on the proposal below, then inspect the execution result and open the created tasks in Work. The same proposal is also available in the shared approval queue.
For a fictional example, prepare two tasks: confirm the kickoff meeting and request brand assets. After successful approval execution, expect two assigned tasks linked to the selected source. A preview or pending proposal has not created them yet. The demo uses the actual admin components with session-local fictional data.
Use it through AI
The registered tools prepare_client_onboarding and propose_client_onboarding use the same workflow as the interface. Preparation returns a reviewable plan; proposing uses that plan's digest and a stable request identity. The assistant cannot approve its own task creation.
At execution, the host checks the workspace, the enabled plugin, the source, the assignments, and the approved plan all over again, right before it commits anything. If any of those facts changed since you reviewed the plan, it asks for a fresh one rather than running a stale decision, which is what keeps the created tasks attached to the decision you made, not one that has since gone out of date.
What this example teaches you to build
Adapt the checklist for your own delivery process: a site survey, legal intake or account setup. Keep the opportunity as the source of truth and let the shared task service handle assignments and saved work.
The workflow source produces a bounded plan. The shared host owns permissions and business writes. You can change the business-specific plan while reusing the approval queue, task records and execution receipts.
Costs, disabling and recovery
Checklist preparation and task creation are both deterministic and make no paid model or provider request on their own. Hosting and database costs still apply as usual, and any AI chat you have around the workflow uses your workspace's configured model.
Disabling the plugin in Apps & connections blocks any later execution, including approvals that are already pending, while existing tasks and receipts stay exactly where they are. Use the normal task controls to edit or complete whatever work was already created before you disabled it.
If the source or an assignee is missing, correct the input and preview it again. When a result comes back uncertain, inspect the original receipt and reuse its request identity for a retry, rather than submitting a fresh request just to route around the uncertainty. A code or policy upgrade can invalidate an existing preview too, in which case it simply needs a fresh review.
The developer guide covers the contracts and npm run test:business-workflows. Controlled tests and fictional demo behavior are distinct from verification of your own workspace permissions and database.
Use the same sources in an AI conversation
With this plugin enabled, the assistant can request its declared knowledge sources through the shared search tool. Results include source references, revisions, applicable reviewed guidance and the plugin's prerequisites. This uses the same host-reviewed source permissions as the plugin itself, so disabling the plugin also stops new source retrieval.
The manifest declares which correction signals it accepts and what saved artifact counts as success. These declarations help an assistant choose and inspect the workflow; the report or approved workflow still performs the actual work. Review the resulting report or tasks and their source records before treating the example as complete.