Your First Client Workflow
This runbook takes one client from an empty relationship to an operating workflow in their own workspace. The client keeps the deployed copy, connected accounts, configuration, and run history; your access remains governed separately through their delegation grant.
This guide uses one client and one workflow deliberately. Complete the whole operating loop once before repeating it across your client roster. The client layer and console must already be enabled for your practice; see Getting set up if the Client quick action is not available.
1. Onboard the client
Open your console, select Client, and choose the route that matches the client’s starting point in the New client dialog.
| Route | Use when | When access begins |
|---|---|---|
| Create workspace | You are setting up a new workspace for them | Immediately, with an active full-operational grant; you are also added as an Admin |
| Invite by email | The client should create their own workspace | When they accept the invite, with an active full-operational grant |
| Add existing team | The client already has a Glow workspace | After a client Admin approves the requested tier, scope, duration, and consent |
For an existing workspace, request Full operational because deployment writes a workflow into the client workspace. The request remains pending and the client does not appear in your active roster until an Admin accepts it. If you will need to enter the workspace without direct membership, ask the client to enable Allow impersonation as a separate consent.
See Client Onboarding for each route and Governance & Impersonation for the access controls.
2. Confirm the grant
Before you build, open the console’s Governance tab and confirm that the grant is active, unexpired, and Full operational. Read-only access is not enough to deploy into the client workspace. The client can narrow or end the grant later.
3. Enter the client workspace
Open the client from the console. Glow uses your normal membership when you are already a member of that workspace. Otherwise, entering the client workspace requires an impersonation session allowed by the active grant.
For an impersonation session, choose a client Admin, set the shortest practical duration and scope, and record a specific reason. The client receives notice when the session starts and ends, and the activity trail attributes your actions to both identities.
A full-operational grant does not let you create, rotate, remove, or re-authorise the client’s connections. Impersonation does not change that boundary.
4. Connect the client’s accounts
Have the client connect each app account the workflow will use from their own workspace. Keep production and test accounts distinct where an action can create or change real records.
These connections belong to the client. Your own connected accounts never cross into their workspace, and deployment only considers accounts already connected there.
5. Prepare and version the workflow
Return to your own workspace and finish the reusable workflow there. Before deployment:
- Use variables and secrets for client-specific values rather than embedding them in step fields.
- Test the main path, branches, and failure handling with representative data.
- Check that the client’s plan supports the workflow’s expected volume and limits.
- Save a named version with notes that identify what you approved for this client.
A saved version is an immutable deployment point. Later canvas edits do not change the version already selected for deployment.
6. Deploy one Draft copy
Glow has two client deployment paths. This runbook uses Workspace Deployment because it starts from the saved version you approved. If you need a detailed one-client preflight against the current active workflow instead, compare the paths in Choose a Deployment Method.
In your workspace, open Deployment, select the workflow, and choose Deploy. Select the approved version, enable the client destination, and choose only this client.
Choose the saved version and client workspace, then start the deployment.
The client receives a new, independent workflow in Draft. Its triggers are disabled, so nothing begins running when the copy arrives. An existing client copy is never overwritten; deploying again creates another separate workflow.
7. Complete the client copy
Open the new workflow in the client workspace and check every resource it depends on:
- Exactly one healthy matching client account: Glow binds the step automatically.
- No healthy match, several matches, or only an unhealthy match: the step arrives without an account selected. Have the client choose or connect the correct account.
- Missing variable or secret key: Glow creates the key without a value. Have the client enter the value in their workspace.
- Referenced team file: confirm that the copied file is the one the client workflow should use.
- Captured sample data: collect fresh test data in the client workspace because source samples are stripped during deployment.
Do not copy credentials or secret values from your workspace. Resolve each reference against resources owned by the client.
8. Test in Draft
Keep the client copy in Draft while you test. Draft disables automatic triggers but still permits manual runs.
Test uncertain steps individually
Run each step that writes to an external system against a safe client-owned test record or account. Read the step’s Executions tab and confirm the destination changed as intended.
Run from the trigger
Set the trigger as the run point and press Run. Starting in the middle is useful for diagnosis, but it does not prove the full path.
Read the Execution Log
Confirm the branch taken, the values passed between steps, and the first unexpected result. A completed step shows that the call finished; verify the resulting message, ticket, row, or record in the destination too.
Save a restore point
Once the test passes, consider saving a version of the client-owned copy before enabling its triggers. This gives the client a restore point for later changes.
9. Set the workflow Live
Review the trigger with the client, including its schedule, timezone, webhook sender, or app event. Then switch the workflow from Draft to Live.
Live enables automatic triggers. It does not create another copy or version. Future edits affect this same client-owned workflow, so save a version and return it to Draft before a controlled change.
10. Monitor the first runs
Use the console for cross-client health and the client’s Execution Log for the full sequence of one run.
- In Fleet, watch execution health and trends for the client.
- In Activity, filter to the client to see failures and workflow changes.
- In the client workspace, open the Execution Log to find where a run stopped or took an unexpected branch.
- Open the affected step’s Executions tab for its exact input, output, and error.
Confirm the first real outcome in the destination system. If an external write is uncertain, check that system before retrying so you do not create a duplicate business event.
11. Review or end access
At handover or the end of the engagement, review the two access paths separately:
- Delegation grant: confirm that its tier, scope, impersonation consent, and expiry still match the work you are doing. From the client card’s actions, use Leave workspace… or Leave workflows… when your delegated work is complete.
- Direct membership: if your people were added under Team Management, remove memberships that are no longer needed. Ending the grant does not remove direct workspace members.
The workflow remains in the client’s workspace when delegated access ends. It keeps its configuration and can remain Live under the client’s ownership. The client also keeps the grant and impersonation history in their audit trail.
What’s Next?
- Pushing Workflows to Clients: use the one-client admin path when you need a detailed preflight.
- Your Console: monitor workflow health across the rest of your client roster.
- Operating Workflows: use the same test, Live, monitor, diagnose, and recovery loop for ongoing changes.