Pushing Workflows to Clients

Cross-workspace pushing copies the current active version of a workflow from your workspace into one client workspace. It rebinds a step when the client has one matching connected account and leaves ambiguous or missing connections for review. A preflight shows what the copy needs before you push it.

A push copies. Your original stays exactly as it is and keeps running: nothing in your workspace is torn down or retired.

Not sure whether this is the right route? Choose a Deployment Method compares Admin Push with saved-version Workspace Deployment.

Pushing needs a full-operational grant on the receiving client. A read-only grant can look at that client’s workflows but not write to them, so the push is refused before anything is copied. See Access Tiers for what each tier covers, and ask the client to raise the grant if you need to push to them.

The push flow

Pushing happens in two phases: review the preflight, then start the copy. Nothing is written to the client workspace during preflight.

Reading the Preflight

The preflight is the important part. It tells you what the client copy will need before you start the push.

Connected accounts

Each step that uses an app must be rebound to an account the client owns. Every one resolves in one of two ways:

Resolution	Meaning
Bound automatically	The client has exactly one account for that app. The step arrives connected.
Needs connecting	The client has no account for that app, or more than one. The step arrives with the connection cleared, and the client picks or connects an account before the workflow can run.

You never pick between a client’s credentials. Where a client has several accounts for the same app, only they know which one belongs in which step. The push leaves the choice to them.

Your own connected accounts never travel. The workflow is always rebound to the client’s own connections.

Team variables and secrets

The preflight lists every variable and secret key the workflow references, and whether that key already exists in the target.

Files

Any team files the workflow references are listed, along with whether they were found and whether they will be copied.

Sample data

Captured sample payloads never cross a workspace boundary. Whatever test data your steps hold on your canvas is stripped from every copy, and the preflight confirms it.

That is the right default: sample data is real customer data belonging to whoever it came from. It does mean the client’s copy opens with empty step previews, so tell them the first run is what fills those in.

The preflight reports missing or ambiguous client configuration before you push. Review those items with the client so they know what must be completed after the copy arrives. Existing copies need separate care, covered in Preventing Accidental Overwrites below.

After the Push

Pushed workflows arrive inactive. The client reviews the configuration, connects any missing accounts, fills in any empty variables, and activates it themselves. Nothing starts running in a client workspace without their action.

Both workspaces get an activity-log entry recording the transfer, and admins in the target workspace are emailed when it completes.

Preventing Accidental Overwrites

A push does not update a workflow already in the client workspace. If Glow reports that the client already has a copy, stop and inspect that workflow before taking another action. Clients may have customised what you sent them, so treating a new push as an update could leave two independent versions to manage.

If the existing workflow needs a change, work in that client-owned copy instead. This preserves the client’s edits and avoids presenting an additional copy as a replacement.

What’s Next?

👉 Your Console → — watch what you deployed: execution health per client, and where a pushed workflow is failing.

Sideways from here: compare this procedure with Workspace Deployment.

Sideways from here: if you need to go into a client’s workspace to fix something, see Impersonation.