Collaboration permissions reference
This page lists every permission related to cross-organization collaboration, what it allows, and which roles have it by default.
For background on how collaboration works, see Understanding Cross-Organization Collaboration.
Permission reference
| Permission | What it allows | Default roles |
|---|---|---|
collaboration.manage_partnerships | Create partnership invitations, accept or decline incoming invitations, dissolve active partnerships. | Organization Admin, Coordinator |
collaboration.invite_partners | Invite a partner organization to collaborate on a specific event. Set worker count, compensation type, and self-signup policy. | Organization Admin, Coordinator |
collaboration.manage_assignments | Assign workers from your organization to a partner event, remove assigned workers, open or close self-signup. | Organization Admin, Coordinator |
collaboration.view_collaborations | View collaboration details, worker rosters for active collaborations, and collaboration settlement status. | Organization Admin, Coordinator, Family Lead |
collaboration.settle | Approve and confirm collaboration payouts during event settlement. | Organization Admin |
external_contacts.manage | Create, edit, and delete saved external operator contacts for roster sharing. | Organization Admin |
roster_share.create | Share an event roster with external contacts via email link. | Organization Admin, Coordinator |
roster_share.revoke | Revoke an active external roster share link. | Organization Admin, Coordinator |
Permissions apply within your own organization's context. A coordinator at NPO-B uses collaboration.manage_assignments to assign NPO-B's workers — they cannot assign workers from NPO-A or any other organization.
Custom roles
If your organization uses custom roles, an admin can add or remove collaboration permissions from any role. See Manage Users and Roles for instructions.
A few combinations to be aware of:
- A user needs both
collaboration.manage_partnershipsandcollaboration.invite_partnersto both create partnerships and use them to invite partners to events. Having only one of these is valid — for example, a coordinator who can send event invitations but cannot create new partnerships. collaboration.settleis intentionally Admin-only by default because payout approval affects the organization's ledger. Grant it to coordinators only if your organization's workflows require it.collaboration.view_collaborationswithout any management permission creates a read-only role — useful for treasurers or family leads who need visibility without the ability to make changes.
Subcontractor access
When a collaboration is created as a full subcontract (rather than a standard collaboration), the partner organization's coordinators receive elevated access to that specific event. This is a temporary, event-scoped elevation — it does not change their role or grant them any permissions outside of that event.
What a subcontractor can do on the host's event
| Action | Available to subcontractor? |
|---|---|
| View event details | Yes |
| Assign workers from their own org | Yes |
| Open self-signup for their workers | Yes |
| Record worker attendance | Yes |
| Enter stand commission data | Yes |
| View settlement preview | Yes |
What a subcontractor cannot do
| Action | Available to subcontractor? |
|---|---|
| Transfer or reassign event ownership | No |
| Invite additional partner organizations | No |
| View the host organization's other events | No |
| View the host organization's family accounts | No |
| View the host organization's fund balances | No |
| Commit settlement (finalize the payout) | No |
| Access any data outside the subcontracted event | No |
The host organization always retains final control over settlement approval and payout confirmation. The subcontractor can prepare and preview the settlement but cannot commit it.
External roster sharing
The external_contacts.manage, roster_share.create, and roster_share.revoke permissions control who in your organization can share event rosters with people outside of StandShare.
External roster shares are separate from cross-org collaborations. They require no partnership and no StandShare account on the recipient's side — the recipient receives a secure, view-only link by email. Because they bypass the partnership layer, access to these permissions is worth reviewing carefully:
external_contacts.manageis Admin-only by default. This keeps the saved contact list under admin control.roster_share.createandroster_share.revokeare available to Coordinators as well, since coordinators routinely communicate with venue operators and often need to share rosters as part of event day logistics.
For a full explanation of how external sharing works — including identity verification, forwarding, worker privacy gates, and cascading revoke — see Understanding external roster sharing.
For step-by-step instructions, see Share an event roster externally.
Next Steps
- Understanding roles and permissions — how StandShare's RBAC system works broadly.
- Understanding cross-organization collaboration — how collaboration scenarios and money flow work.
- Delegate full event operations to a partner — the full subcontract how-to guide.