Understanding cross-organization collaboration

Roles

Organization Admin · Event Coordinator

StandShare is built around the idea that each NPO manages its own members, events, and finances independently. But in practice, youth sports organizations often work together — sharing workers for a big game, covering an event when the primary org is overcommitted, or trading favors across a season.

Cross-organization collaboration is the feature that makes this possible inside StandShare, without giving one organization access to another's private data.

The problem it solves

Before this feature existed, coordinators who needed extra workers from a partner organization had to coordinate by text, spreadsheet, and trust. Workers showed up at the partner's event but their attendance was not tracked in StandShare. No payout was recorded. No audit trail existed. If money changed hands, it was informal.

Cross-organization collaboration brings those arrangements into StandShare so that attendance is tracked, payouts are calculated accurately, and both organizations have a record of what happened.

Two scenarios

"I'm short — send help"

This is the common case. Your organization owns an event and has open spots. You ask a partner organization to send some of their workers to fill those spots.

• You stay in charge of the event.
• The partner coordinator assigns their workers (or opens self-signup for their members).
• Workers from the partner organization show up, work the stand, and get checked in like any other worker.
• At settlement, you pay the partner organization a lump sum (or a per-worker rate) — or the collaboration is volunteer-only and no money changes hands.

This scenario is designed for situations where you need 5 to 15 extra workers and you have a trusted relationship with another local NPO.

"Take the whole thing"

This is rarer. Your organization has a venue contract for an event but genuinely cannot run it — a scheduling conflict, a key coordinator is unavailable, or you are overextended. Rather than forfeit the event, you hand full operational control to a partner organization.

• Your organization remains the legal owner of the event (the venue contract stays with you).
• The partner coordinator manages everything: assigning workers, recording attendance, entering commission data, running settlement preview.
• You review and finalize settlement from your end.

This is called a full subcontract. See Delegate Full Event Operations to a Partner for the how-to.

Partnerships: the trust layer

Before either collaboration scenario is possible, the two organizations must establish a partnership. A partnership is a mutual agreement in StandShare that says "we trust each other enough to collaborate on events."

• Either organization can send the invitation.
• The other must accept.
• Once active, either side can invite the other to collaborate on specific events.
• Partnerships can be dissolved, which prevents future collaboration invitations but does not affect collaborations already in progress.

Think of partnerships as your approved vendor list. The marketplace for discovering new partner organizations is planned for a future release — for now, you need to know the organization by name to invite them.

How workers stay in their home organization

A worker from NPO-B who is assigned to NPO-A's event does not become a member of NPO-A. They remain in NPO-B throughout.

• Their profile, family account, and compliance documents are in NPO-B.
• Their attendance at NPO-A's event is recorded under the collaboration record.
• From NPO-A's event view, coordinators see their name and assignment but cannot access their full profile or financial history.
• From NPO-B's view, coordinators can see which of their workers are assigned to partner events.

This design keeps tenant data boundaries intact. NPO-A never gets a window into NPO-B's financials or member data, and vice versa.

How money flows

Volunteer collaboration

No money changes hands between organizations. The partner organization's workers show up, their attendance is recorded, and the collaboration is closed when the event settles. The partner org may credit those workers internally using their own settlement process — that is entirely their choice.

Paid collaboration

NPO-A (the host) pays NPO-B (the partner) as a single payment. The amount is agreed when the collaboration invitation is created — either a fixed lump sum or a per-worker rate.

NPO-A (host)
  → Pays lump sum to NPO-B at settlement
  → Ledger records: debit to NPO-A, credit to NPO-B

NPO-B (partner)
  → Receives the lump sum
  → Distributes internally to their families using their own settlement

NPO-A does not pay NPO-B's individual families directly. The payment goes org-to-org. What NPO-B does with it — how they distribute it to the families whose workers attended — is NPO-B's own internal settlement process.

Settlement timing

Collaboration payouts are calculated automatically as part of the host organization's standard event settlement. When a coordinator at NPO-A settles the event, the system adds collaboration payout line items to the settlement preview alongside the usual family distributions. The host reviews and approves the payout as part of committing settlement.

See Settle Paid Collaboration Payouts for step-by-step instructions.

How StandShare knows which organization you're working in

Every time you use StandShare, the platform needs to determine which organization's data to show you. This happens automatically — you generally never think about it. But if you ever work across multiple organizations, it helps to understand how it works.

StandShare resolves your active organization in this order:

1. Login context (fastest path). When you sign in to a specific organization, your session carries that organization directly. No database lookup is needed — the platform already knows.
2. Your default organization. If your session doesn't specify an organization, the platform uses whichever organization you've marked as your default. You can change your default organization in your profile settings.
3. Your first active membership. If you haven't set a default, the platform picks the first organization you actively belong to.

If none of these resolve — for example, if your account is still pending approval at an organization — you are blocked from accessing protected pages until your membership is confirmed. You can still log out, check your approval status, and accept invitations, but the rest of the platform is unavailable until your membership is active.

tip

Most users belong to exactly one organization and never encounter this. If you coordinate across multiple organizations, setting a default organization in your profile ensures StandShare opens in the right context each time.

Pending membership: what you can and can't do

If you have created an account but your organization membership is still pending approval, you have limited access:

• You can check your approval status
• You can accept or verify invitations
• You can log out

Everything else — the dashboard, events, documents, finances — is blocked until an administrator approves your membership.

Document requirements

A collaboration can attach documents that must be in order before workers are assigned. This is how host orgs enforce insurance riders, media-release waivers, background checks, or venue-specific rules when partners help staff their events.

Two layers of requirement exist:

Org-level acknowledgment

The host pins a single document to the collaboration and marks it orgAcknowledgmentRequirementId. Until an admin from the partner org acknowledges the document, every attempt to create a worker assignment on this collaboration is rejected with a pending_org_acknowledgment error. This is the "we need your org's sign-off once, before anyone steps on site" gate.

Partner-side admins see a banner on the collaboration detail view with an Acknowledge button. Clicking it records the acknowledgment, the gate opens, and assignments unblock.

Worker-level requirements

The host attaches one or more documents to the collaboration that each individual worker must have signed. On a new assignment, the system:

1. Sets the worker's registrationStatus to pending_documents.
2. Creates a document_instance per required document inside the same transaction so the worker can see exactly what they need to sign.
3. Flips the status to the normal flow once every required document has a signed copy.

This lets partner-org workers join a host's event without being forced through the host's full worker onboarding — only the documents that matter for this specific collaboration are required.

See Assign Cross-Org Workers for the partner-side how-to.

---

External roster sharing

Cross-organization collaboration — partnerships, event invitations, worker assignments — requires both organizations to be registered in StandShare and to have an active partnership. But sometimes you need to show your event roster to someone who does not use StandShare at all: a venue's gate coordinator, a stadium operations contact, or a third-party vendor who needs to know who is showing up.

External roster sharing handles this case. It lets an admin or coordinator send a secure, view-only roster link to any email address. No partnership is needed. The recipient does not need a StandShare account.

How it differs from cross-org collaboration

	Cross-org collaboration	External roster sharing
Recipient must be in StandShare	Yes	No
Partnership required	Yes	No
Recipient can assign workers	Yes (partner coordinators)	No — view only
Money flow tracked	Yes	No
Audit trail in StandShare	Yes	Yes (views and forwards logged)

External roster sharing is not a substitute for a collaboration. It is a read-only communication tool — it tells an outside contact who is working an event. It does not give them any ability to manage the event inside StandShare.

Identity verification

Because the roster contains worker names and potentially contact information, the recipient must verify their identity before the roster opens. The verification flow works like this:

1. The recipient clicks the link from their email.
2. They enter the email address the link was sent to.
3. A one-time code is delivered to that address.
4. After entering the code, the roster is shown.

Organizations that use QR-based check-in at their venues may also provide a QR code as an alternative to the email code step.

Forwarding to the next person

When the sending organization enables forwarding on a share link, the recipient can pass the roster along to another person from inside the roster viewer. The forwarded person goes through the same identity verification step and receives their own link.

Forwarded links are tied to the original share. If the original recipient's access is revoked, every link that was forwarded from it stops working at the same time.

Worker contact privacy

Not every worker's contact information appears in a shared roster, even when the sending organization chooses to include contact details. Workers control their own privacy settings. A worker who has marked their phone number or email as private will not have that information shown to external recipients — only their name and shift assignment are visible.

This is enforced by the platform and cannot be overridden by an admin or coordinator when configuring the share.

Cascading revoke

An admin or coordinator can revoke a share link at any time from the Roster tab on the event. Revoking the link stops access immediately for the original recipient and for anyone the recipient forwarded it to. There is no need to track down forwarded copies — revoking the parent share ends all access in the chain.

See Share an event roster externally for step-by-step instructions on creating, monitoring, and revoking share links.

---

What each side can see

What you want to see	Where to find it
Partners you have invited to collaborate	Event detail → Collaborations tab
Incoming invitations from partners	Collaborations → Incoming
Events at partner orgs where your workers are assigned	Collaborations → Active
Settlement payout status for a collaboration	Event detail → Collaborations → Settlement

Audit trail

Every cross-organization action is logged:

• Partnership creation, acceptance, and dissolution
• Collaboration invitations, acceptances, and declines
• Worker assignments and removals (including who performed the action and from which org)
• Payout approval and payment confirmation

This audit trail is visible to admins in the audit log for their own organization's actions. Neither organization can see the other's internal audit log.

Next Steps

• Create a trusted partnership — the first step before any collaboration is possible
• Invite a partner to help staff your event — the "send help" scenario
• Assign workers to a partner event — the partner side of accepting a collaboration
• Collaboration permissions reference — which roles can do what