internal: every member sees it on the organization’s tab of Dashboard > Workflows and can run it, and their agents list it with list_workflows. Nobody outside the organization can see it.
Share a workflow
Open the workflow and click Share with <organization> (pick the organization when you belong to several). Before anything moves, Danube checks every step for the organization’s members:- Access. A step whose tool members cannot see, such as a tool from your own private service or from another organization, is blocked, with the reason. Sharing stays disabled until you replace that step, because every member’s run would fail there.
- Credentials. Each step says whose credential it runs with: No credential needed, Danube has a shared <service> credential (the organization holds a shared credential), or Each member connects their own <service>.
How shared workflows run
A member’s run uses that member’s own credential for each service, or the organization’s shared one, in the usual credential order and subject to any credential rules. A member who has not connected a service a step needs sees that step fail withauth_required, the same as for any tool call.
Only the author schedules. A scheduled run executes as its author, with the author’s credentials, so only the author can turn a schedule on, change it or turn it off.
Duplicate to Personal copies a shared workflow into your own private workflows, for when you want to change it without changing the team’s.
Who can change a shared workflow
Members can share workflows unless an owner or admin turns off Members can share skills and workflows in Dashboard > Organization > Settings (
skills_member_publish); owners and admins always can.
API
PATCH /v1/workflows/{id} does not move a workflow in or out of an organization; use share and unshare.