Permissions and Access

Access in Glow is decided in layers: your account proves who you are, each workspace membership gives you a role, workflow visibility narrows or widens one workflow, and an MSP delegation grant provides a separate route for an approved partner.

The access model

A team and a workspace are two views of the same boundary. The team is the people and their roles; the workspace is the workflows, app connections, variables, secrets, files, billing, and settings those people work with.

Layer	What it decides	Where to manage it
Account	Your identity, profile, password, and personal 2FA	Personal Settings
Team membership	Which workspace you can enter	Team Settings
Workspace role	What you can administer inside that workspace	Team Settings
Workflow visibility	Who can open one workflow	Share on that workflow
MSP delegation	What an approved partner can reach across the workspace boundary	Settings → Governance
Impersonation	Whether a partner operator may temporarily act as a workspace Admin	Settings → Governance

These layers do not replace one another. Signing in through SSO does not assign a workspace role. Making a workflow Public does not expose its connected accounts or run history. Ending an MSP grant does not remove a separate team membership.

Account, team, and workspace roles

Your account follows you across every workspace you belong to. Profile settings and personal 2FA therefore apply to you, while your role can be different in each workspace.

Glow uses three workspace roles:

Role	Use it for	Key workspace authority
Admin	People responsible for the workspace	Team settings, billing management, invoices and payments, all workspace roles, and MSP governance
Manager	People who organise day-to-day work	Workflows, files, variables and secrets; usage and pricing; Manager and Member role changes
Member	People who build and operate workflows	Workflows and files; usage and pricing; variable and secret names; invitations for other Members

All three roles can create, edit, run, and set team-visible workflows Live. A Member is a builder, not a read-only seat. Use workflow visibility when one workflow needs a narrower audience.

All three roles can open Billing & Usage to view Usage and Pricing. Only Admins can view invoices and payments or manage billing. See Billing & Usage.

Workspace resources follow their own controls:

• App connections belong to the workspace context and can be selected in its workflows. Every workspace role can create a connection. Only the person who created one can reconnect or disconnect it; disconnecting it affects every workflow that uses it.
• Variables and secrets are workspace resources. Every role can see their names, while Managers and Admins can create, change, or delete them. Secret values are never shown again after saving.
• Files are shared workspace resources. Admins, Managers, and Members can view, upload, rename, move, duplicate, and delete them.

Workflow visibility is a separate layer

A workflow’s visibility works on top of workspace membership and role:

Visibility	Who can open it	What that means
Private	Its author	Other workspace members cannot see it
Team	Everyone in the workspace	The default for a new workflow; workspace members can work on it
Public	Anyone with the link	External visitors get a read-only view of the canvas shape

A Public visitor sees step names, apps, notes, and connections between steps. They do not receive step configuration, app accounts, variables, secrets, or run history. Only the workflow’s author can change its visibility.

A signed-in outsider can request access from a Public workflow. Approving that request adds them to the workspace as a Member; it does not create a view-only guest role for that workflow.

Sign-in security does not grant workspace access

SSO controls how a person proves their identity. Workspace membership and roles are still managed in Team Settings, whether the person signs in with a password or through your identity provider.

2FA protects an individual password-based Glow account and is enabled in Personal Settings. For people who sign in through SSO, apply your identity provider’s multi-factor policy instead. To require a second factor across the whole workspace today, use SSO with that policy enabled.

MSP delegation is another access path

A consultancy or MSP reaches a client workspace through a delegation grant, not through the Admin, Manager, or Member role table. The grant records a tier, scope, expiry, and whether impersonation is allowed.

• Read-only supports monitoring and alerts covered by the grant.
• Full operational adds workflow copies and operational actions within the grant’s scope.
• Impersonation is separate consent on a full-operational grant. It lets an operator act temporarily as a selected client Admin, within a scope no broader than the grant.

Impersonation can use existing app connections when running or repairing workflows. It does not allow billing, team settings, membership, governance, security, or connection lifecycle changes.

Workflows and workspace resources remain in the client workspace when governance ends. Ending access changes who can reach them; it does not remove the work already delivered.

I need to…

I need to…	Use this control	What to expect
Change what a teammate can administer	Change their role in Team Settings	The new role applies only in this workspace
Remove a teammate from the workspace	Remove their membership in Team Settings	They lose this direct access path; an MSP grant is unchanged
Keep a draft workflow to myself	Set Share → Private on the workflow	Only the author can open it
Let the whole workspace work on a workflow	Set Share → Team	All workspace roles can open and edit it
Let someone inspect a workflow without joining	Set Share → Public and send the link	They receive a read-only canvas view without configuration or run data
Give someone full workspace access from a Public link	Approve their access request	They join as a Member, not as a workflow-only guest
Add an app account	Connect it from Connections or the step’s Account field	Every workspace role can create a connection; it becomes available to workflows in that workspace
Reconnect or remove an app account	Have its owner manage it from Connections	Other members do not see lifecycle actions for that connection; disconnecting leaves affected steps without a working account
Control who manages secrets and variables	Assign Manager or Admin	Members can see names but cannot create, change, or delete these resources
Require corporate sign-in and multi-factor authentication	Set up SSO and enforce MFA with your identity provider	Team membership and roles still remain in Team Settings
Let a partner monitor or operate selected work	Approve a delegation grant in Settings → Governance	The grant’s tier, workflow scope, and expiry set the boundary
Let a partner work temporarily as an Admin	Enable Allow impersonation on a full-operational grant	Each session is time-bound and remains confined to the grant
Stop one impersonation session	End the active session in Settings → Governance	The grant remains available for future permitted work
Stop all future impersonation	Turn off Allow impersonation	Any active session ends; the underlying grant remains active
End the MSP relationship	Choose Leave MSP management in Settings → Governance	Delegated access ends; review Team Settings separately for direct memberships
Remove a partner operator who is also a teammate	Remove them in Team Settings	Their direct membership ends; review Governance separately for the grant

What’s Next?

• Manage members and workspace roles in Team Management.
• Set access for an individual workflow in Workflow Visibility and Sharing.
• Review partner tiers, scope, and session controls in If a Partner Manages Your Workspace.