# Permissions and Access > Understand how account security, workspace roles, workflow visibility, shared resources, and MSP delegation combine to control access in Glow. 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. ```mermaid flowchart LR A[Account Identity] --> M[Team Membership] --> R[Workspace Role] --> V[Workflow Visibility] G[MSP Grant] --> R ``` | 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](/manage/billing/overview). 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. > **Review both access paths at the end of an engagement.** Leaving MSP > management ends the delegation grant, active impersonation sessions, partner > console visibility, and planned workflow transfers. It does not remove a > direct team membership held by one of the partner's people. Removing that > person in Team Settings does not end the delegation grant either. Use > **Settings → Governance** for the grant, then **Team Settings** for any direct > memberships that should also end. 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](/manage/workspace-settings/team-management). - Set access for an individual workflow in [Workflow Visibility and Sharing](/build/core-concepts/workflow-visibility). - Review partner tiers, scope, and session controls in [If a Partner Manages Your Workspace](/msp/governance/for-clients).