Sharing
Open the share dialog on any resource, pick who gets access and at which role, and set an expiry. The same grants can be made from the CLI.
Every resource in Helios has a share button. It opens a dialog where you choose who gets access, at what role, and for how long. The dialog works the same way for projects, workflows, chats, integrations, MCP servers, database connections, service accounts, and Library paths.
For how resources inherit access from their project, see projects and sharing.
Who you can share with
| Principal | Notes |
|---|---|
| A person | Any member of the organization. |
| A group | Every member of the group gets the role. |
| A service account | Gives a workflow that runs as that account access to the resource. |
| Everyone in the organization | Shown with an Org-wide badge in the access list. |
Roles
The share dialog offers four roles. The dashboard labels them by what they allow.
| Role | Label | Allows |
|---|---|---|
viewer | Can view | Read the resource and its runs. |
operator | Can run | Everything a viewer can, plus trigger runs and use the resource from an agent. |
editor | Can edit | Everything an operator can, plus create, change, and delete. |
admin | Full access | Everything an editor can, plus change who has access. |
You can never grant a role above your own on that resource. See roles and permissions for how roles resolve.
Some resource types restrict the choices.
- Chats can only be shared at
viewer, only with people or groups, and default to a one day expiry. - Service accounts can be shared at
vieweroradmin, and not org-wide. - Integrations, MCP servers, and database connections default to
operator. - Projects default to
editor. Workflows default tooperator.
Expiry
Every grant can expire. The options are No expiry, 1 day, 1 week, or Custom with a date you choose. An expired grant disappears from the access list and the person loses access at that time.
The access list
Below the dialog, the access list shows every grant on the resource, including grants inherited from the project. From here you can change a role or revoke a grant.
For integrations, each row also shows how the grantee connects. See credential mode.
Sharing a Library path
Library folders are shared through the same dialog with the Library path grant type. The levels are viewer and editor. See Library permissions.
From the CLI
The helios CLI makes the same grants, so sharing can be scripted.
helios share workflow/<id> --with group:support --role operator --expires 2026-10-01
helios share integration/<id> --with sa:nightly-digest --role operator
helios unshare workflow/<id> --from user:<id>
helios access list workflow/<id>
helios shared listPrincipals are everyone, user:<id>, group:<id or name>, and sa:<id or name>. Add --json
to any command for machine-readable output. The same rules apply as in the dashboard. You cannot
grant above your own role, and grants to a project's default service account are refused because
they could not be revoked.
Related
Last updated on
Roles and permissions
Helios has two layers of access control. An organization role says what you can create. A resource role says what you can do to a specific project, workflow, chat, or integration.
Groups
A group is a named set of people and service accounts. Share a resource with the group and every member gets the role.