Sharing Workflows and Access Control

Control who can view, edit, and run your workflows.

Overview

Workflows have a visibility setting plus an explicit share list. Visibility is the high-level mode (private, shared, or public); the share list is the set of specific workspace members and teams who can access a non-private workflow.

Access control sits on top of workspace membership: the people you share with must already belong to the workspace. Sharing is the right tool for routine collaboration; for organization-wide policies, use workspace roles instead.

Before You Start

  • You need permission to manage the workflow's sharing settings.
  • The teammate already invited to the workspace.

Visibility Modes

  • PRIVATE - Only the workflow owner sees it. The share list is ignored in this mode.
  • SHARED - Visible to the workspace members and teams named on the workflow's share list.
  • PUBLIC - Visible to everyone in the workspace.

Steps

  1. Open the workflow and click the Settings tab.
  2. Go to the Access section.
  3. Set Visibility to PRIVATE, SHARED, or PUBLIC.
  4. For SHARED, click Add Member or Add Team and pick from the workspace member or team list.
  5. Click Save. The change applies immediately.

Changing or Removing Access

  • To change visibility, switch the mode in the Access section and click Save.
  • To remove a member or team from a SHARED workflow, click the remove icon next to their entry and save.
  • Switching from SHARED back to PRIVATE hides the workflow from everyone except the owner immediately.

Tips

  • Default to PRIVATE for drafts and SHARED for production work. Use PUBLIC only for genuinely workspace-wide utilities.
  • Share with a team rather than per-person where you can - it tracks staff changes automatically as the team membership changes.
  • Use folders to keep workflows organized; folder membership does not change access, but it makes shared work easier to find.

Common Pitfalls

  • Sharing a workflow does not share its Connections. Other members need their own access to the connectors the workflow uses.
  • Subworkflow nodes need the caller to have access to the called workflow at runtime.
  • Workflow visibility does not override workspace role limits. Workspace Viewers still can't edit, even if a workflow is set to PUBLIC.
  • Switching to PRIVATE does not retroactively scrub execution logs - past runs remain visible to whoever ran them.

Related Articles

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.