Your First Client Automation
Onboard your first client, deploy a tested automation to their workspace, and switch it Live. The client owns the deployed copy, connected accounts, configuration, and run history. Your delegated access follows their grant, while direct workspace membership is managed separately.
- Use it to
- Onboard a client workspace, deploy a tested Draft automation copy, bind client credentials, and switch it Live
- Find it
- Clients → Invite client, then Deployment → Deploy workflow
- Limits
- Requires an active Full operational grant with Full workspace scope
- Output
- An independent client-owned automation copy in Draft with triggers disabled until switched Live
Complete this end-to-end loop with one client and one automation first. See Getting set up if Invite client is not yet enabled for your practice.
1. Onboard the client
Open Clients → Invite client and pick the onboarding mode that matches the client (see Client Onboarding):
Create client
Creates the workspace immediately with a full-operational grant and adds you as an Admin. Invite the client’s lead as an Admin through Members & Invitations before setting up accounts or billing.
2. Confirm the grant
Ask the client Admin to check Team settings → Governance. The grant must be active, unexpired, Full operational, and cover the Full workspace (read-only or selected-automation grants cannot deploy a new copy). Lowering the tier ends live sessions and disables impersonation consent. Raising the tier or scope requires a new request and consent.
3. Enter the client workspace
- Switch into the client workspace directly when your account is a workspace member.
- Uses your assigned workspace role permissions.
- Managed under Members independently of the delegation grant.
- Requires Practice Admin role, an active Full operational grant, and impersonation consent.
- Select a client Admin, set the shortest duration and scope, and log a reason.
- Notifies the client asynchronously and records both identities in the audit trail.
For an existing automation, Open automation in the console offers delegated entry subject to grant checks. Clicking a client card alone only filters the dashboard. See What is recorded for audit coverage.
Neither a full-operational grant nor impersonation lets you create, rotate, remove, or re-authorise the client’s app connections.
4. Connect the client’s accounts
Have the client follow Connecting an App inside their workspace for each required service. Keep test and production accounts distinct. Record who owns each connection and who handles reconnection or replacement (see Managing Connections). Deployment never transfers your own workspace’s connections.
5. Prepare and version the automation
Finish the reusable automation in your practice workspace before deploying:
- Reference workspace variables and secrets instead of hardcoding client values in Step fields.
- Test the main path, branches, and error handling with sample payloads. Confirm the client’s plan supports expected run volume.
- Save a named manual version with notes recording what you approved. Later canvas edits do not change that saved snapshot.
6. Deploy one Draft copy
This runbook uses Workspace Deployment from your approved saved version. See Choose a Deployment Method to compare console current-definition copies:
Open Deploy workflow and review Basic info
In your MSP workspace, open Deployment → Deploy workflow (or click Deploy on a listed automation). Review the name, description, category, and interface settings.
Select the saved version
Under Version & deploy, open Version name and select your approved manual version (AI checkpoints are excluded).
Select only this client and deploy
Pick the client’s chip under Clients, turn off Marketplace under Deploy to, and confirm. The client receives an independent Draft automation with triggers disabled. Redeploying creates another separate copy rather than overwriting.
7. Complete the client copy
Open the deployed Draft in the client workspace and bind its resources:
These checks are for your review only. They are not saved, and Glow does not verify or change your automation.
Glow auto-binds an app Step only when the client has one healthy matching account in total. Otherwise, have the client connect or select the right account.
Missing variable and secret keys are created empty. Have the client populate each value in their workspace.
Confirm that any copied team file matches the version the client automation should use.
Capture fresh test data in the client workspace because source Step samples are stripped on deployment.
Source child references are removed. Deploy or create each child automation separately and re-select it.
Account-backed tools, connection-backed tools, external MCP tools, and knowledge sources are stripped. Rebind them to client resources and review tool approval policies.
8. Test in Draft
Keep the client copy in Draft while testing with approved test accounts (manual Draft runs still call real external services and use credits):
Verify Step inputs and accounts
Check each Step’s bound account, destination, and mapped inputs. Ordinary Run step replays saved Testing data rather than calling the provider. Use Test & Debug for live Step or AI Agent tests.
Run from the trigger and inspect logs
Set the trigger as the starting point and click Run. Verify the branch taken, Step payloads, and destination record in the Execution Log.
Save a client restore point
Save a named version of the tested client copy before switching it Live.
9. Set the automation Live
Confirm the schedule, timezone, webhook sender, or app event with the client, then switch the automation from Draft to Live. Live enables automatic triggers on this same automation. Save a version and return to Draft before making future changes.
10. Monitor the first runs
- Clients → Overview (Your Console). Select the client card to filter Executions, Success rate, Waiting on you, and Activity. An issue badge indicates open alerts even if the period success rate is 100%.
- Client Execution Log and destination apps. Inspect the branch taken, inputs, outputs, and first real destination outcome before retrying any write.
11. Review or end access
Before routine handover, confirm operating ownership with the client. Revoke compromised or unwanted access immediately:
| Responsibility | Confirm with the client |
|---|---|
| Monitoring & Alerts | Who checks the Execution Log, destination outcomes, and failure notifications. |
| Connections | Who owns each app connection and handles re-authentication or replacement. |
| Billing & Sponsorship | Which billing admin manages plan capacity or sponsor subscriptions. |
| Governance & Memberships | Which client Admin reviews the delegation grant and direct workspace members after handover. |
These checks are for your review only. They are not saved, and Glow does not verify or change your automation.
Have the client Admin use Change tier for read-only visibility or End management in Team settings → Governance.
Ending a grant does not remove direct workspace members. Check Members and remove partner accounts that no longer need direct access.
Ask the client Admin to export the available audit trail as CSV in client Governance controls.
Delivered automations and audit history remain in the client’s workspace after delegated access ends.
- Run
- Trigger one controlled run in the client workspace, then check Clients → Overview in your console.
- You should see
- The client's Execution Log records a completed run and the console reflects the workspace activity.
What’s Next?
👉 Choose a Deployment Method →: compare current-definition copies with saved-version rollouts before repeating this process for more clients.
For ongoing work, use Your Console to monitor the roster and Operating Automations for testing, diagnosis, and recovery.