Set a workflow to Public when other members of the same workspace should be able to discover and run the same procedure. Keep it Private while it is personal, experimental, or contains material the workspace should not share.
Publishing a workflow shares its instruction and attached reference files. It does not share the creator's private chats, connected accounts, credentials, or personal permission grants.
Before you publish
Confirm that:
- the workflow produces a useful result with more than one realistic input;
- its description clearly says when to use it;
- the instruction contains no token, password, customer secret, or unnecessary personal data;
- attached files are safe for every workspace member to view;
- in Legacy Agents, the owning Agent is Public and available to the intended members;
- approval rules are explicit for sending, publishing, deleting, purchasing, or changing external data.
My Okou: Public Workflows are workspace methods, and Private Workflows belong to the current user. Legacy Agents: workflows belong to an Agent; a Public Workflow also needs an owning Agent teammates can access.
Which experience are you using?
These docs cover both experiences. If Settings → Personal → My Okou is available, follow the My Okou steps. If you use an Agents page with New agent, follow the Legacy Agents steps. Availability can differ between members; these docs do not change your experience.
In either experience, you can run several chats or tasks at once, reuse workflows, and share reviewed work with your team. A runtime subagent is an execution tool, not a separate product profile you need to create.
Make a workflow public
- Open Workflows.
- Select the workflow you want to share.
- Review its Name, Description, Instructions, and attached files.
- Under Visibility, choose Public or select Make workflow public.
- Confirm the change.
The workflow now becomes part of the workspace's shared workflow library.
My Okou example: the Workflow’s Settings tab includes Make workflow public and Make private copy.

Publication and maintenance still follow existing workspace permissions. Creating a Private Workflow does not grant Public publication rights. In Legacy Agents, an Admin may need to publish work on an Agent you do not own.
Public versus private
| Visibility | Who can see and use it | Best for |
|---|---|---|
| Private | The current user in My Okou; the owner within the Agent context in Legacy Agents | Drafts, personal methods, experiments, and sensitive reference material |
| Public | Workspace members; in Legacy Agents, also subject to owning-Agent access | Reviewed team procedures, approved templates, and recurring cross-functional work |
Public means public inside the workspace. It does not create an unauthenticated web page or publish the workflow to the open internet.
How teammates run it
In My Okou, members use a Public Workflow in their own Chat in the current workspace. In Legacy Agents, open its owning Agent's Chat. In either experience:
- enter its slash command, such as
/qualify-inbound-lead; - ask for the task in natural language when the workflow description clearly matches the request.
In Slack, mention Okou and include the workflow name or intended task. See Use shared workflows in Slack.
The member running the workflow supplies the request-specific inputs. Okou uses the executing member's Instructions, memory, connected accounts, and permissions (plus the Agent context in Legacy Agents); it does not borrow the workflow creator's personal account access.
Share the method, not the account
The following are independent:
- Workflow visibility determines who can see and invoke the procedure.
- Instructions are personal in My Okou. Agent visibility remains a separate access boundary in Legacy Agents.
- Connection identifies the service account a member has connected.
- Authorization and named permissions determine what Okou can do with that connection. Any additional Chat account controls are independent of Workflow sharing.
This is why two teammates can run the same public workflow and still receive an authorization request for different services. Each person grants access for their own work boundary.
Copy a Workflow
Use a copy when you need a version that can evolve independently. My Okou: choose Make private copy to create your own version in this workspace. Your same-name Private Workflow takes precedence over the Public version; use an explicit Workflow ID to identify a particular shared definition. Another member's Automations are not copied.
Legacy Agents: the existing copy flow is:
- Open the workflow.
- Select Copy workflow.
- Choose the destination agent.
- Open the new copy and review its instruction, files, and permissions.
- Publish the copy only after it has been tested in the destination agent.
The copy starts as a new private workflow. Changes to it do not update the original, and changes to the original do not update the copy. Treat this as a fork, not a live sync.
Copying is useful when Sales and Customer Success share a research method but need different output formats or approval boundaries. If everyone should receive future updates to one standard, keep one public workflow instead of creating copies.
Update a public workflow safely
A public workflow may already be used by teammates or automations. Before a material change:
- Identify what behavior or output will change.
- Test the revised instruction with representative inputs.
- Tell affected members when inputs, fields, destinations, or approval rules change.
- Check any automations that run the workflow.
- Keep the same slug when the change is backward-compatible; use a new workflow when the contract changes substantially.
Small improvements such as clearer citations or a stronger quality check can usually remain in the same workflow. A new workflow is safer when the audience, required inputs, or resulting action is fundamentally different.
Make a workflow private again
Changing a public workflow to Private removes team access. Other members may lose the ability to run it, and their automations that depend on it can stop.
Before making it private:
- review which people and automations use it;
- create or copy a replacement if the team still needs the method;
- notify affected owners;
- confirm that no shared reference file becomes unexpectedly unavailable.
A lightweight publishing checklist
- Clear name and memorable slug
- Description explains when to use it
- Instruction defines inputs, steps, output, and approval boundaries
- Files are current and safe to share
- In Legacy Agents, owning Agent is Public
- Tested by someone other than the author
- No personal credentials or private chat content
- Known automations reviewed
Next, invite teammates or help existing members join the workspace.

