Invite Your Team

Membership is the relationship that lets an Account act inside an Organization. It is separate from attendance: buyers, LINK recipients, and imported attendees never become Members, and removing a Member deletes neither the Account nor the record of what that person did.

Inviting needs members.invite. Assigning Roles needs roles.assign.

1. 1

   Invite by email or phoneCopy Anchor Link

   An invite is a pending record for one contact, carrying the Roles to grant on acceptance.

   • The token. Random, single-use, stored only as a hash, and it expires after seven days.
   • Duplicates. A second pending invite for the same contact is refused while the first is live.
   • Visibility. The Member list shows pending invites alongside active Members, and each can be revoked.
   • Acceptance. The Account becomes a Member and the Roles become RoleAssignments. If the person has no Account, verifying the invited contact creates one through the ordinary passwordless flow.

   Delivery is not wired yet

   Send Invite creates the pending record and reports success, but Ulsav does not send the email or text and the app does not display the token. Only an API caller receives it, so acceptance from the app is not possible today.

   Authority is never widened

   You cannot grant authority you do not hold. Choosing a Role whose Capabilities exceed your own is rejected at invite time rather than silently narrowed.

2. 2

   Pick the Role that matches the jobCopy Anchor Link

   Each Organization starts with five reviewed Roles.

   Role	What it is for	What it reaches
   Owner	The account of record; protected	Everything, including settings no other Role can change
   Administrator	Runs the Organization day to day	The whole catalog, including Roles, API keys, and audit
   Event Manager	Publishes and operates Events	Events, Sessions, Passes, coupons, Registrations, Participants, approvals, Orders read and export, Check-In
   Finance Viewer	Reads the money	Orders, payments, ledger, payouts, and exports — no writes
   Check-in Operator	Works a door	Check-In read and operate, plus read-only Pass context

   The distinction that matters most is between reading money and moving money.

   Reading money

   A Finance Viewer sees refunds, payouts, and ledger entries but cannot issue one.

   Moving money

   A refund needs payments.refund.

   Reading the activity log needs audit.read on its own. It is not implied by organization.read, and it is not granted to Event Manager, Finance Viewer, or Check-in Operator by default.

3. 3

   Scope the assignmentCopy Anchor Link

   A RoleAssignment grants one Role to one Member at one Scope: the Organization, an EventGroupSeries, EventGroup, EventSeries, Event, or CheckInSession.

   • Inheritance. A grant at a higher scope reaches everything beneath it. The group and series paths are independent, so an Event inside both inherits from both, plus the Organization and the Event itself.
   • Composition. Effective Capabilities are the additive union of every active assignment covering the resource. There is no explicit deny and no priority order, which has one practical consequence: you cannot grant broadly and then remove one Capability at a single Event. If that narrowing matters, scope the broad grant lower instead.
   • EventSession and Pass. Both inherit Event scope, so a Pass never needs its own grant. Moving an Event between groups changes inherited access immediately, as a confirmed, audited action — worth re-checking after any reorganisation.

   The Members page's Grant scoped Role dialog asks for a scope type and a raw scope ID. There is no resource picker, so have the ID to hand before you start.

4. 4

   Use a custom Role when a job does not fitCopy Anchor Link

   Custom Roles are composed from the versioned Capability catalog, which the Role editor exposes as grouped checkboxes rather than asking you to guess names. Wildcards are reserved for the protected Owner Role and platform operations; a custom Role carries an explicit, non-empty, duplicate-free list.

   The catalog is organised by domain:

   • Organization and access — organization, members, roles, domains, API keys, SSO
   • Publishing — events, EventSessions, Passes, coupons
   • Participation — Registrations, Participants, approvals, Requirements
   • Money — Orders, payments, ledger, payouts
   • Admission — Check-In sessions and their operation
   • Reporting — Orders export, audit, notifications
5. 5

   Keep machine access out of the team listCopy Anchor Link

   An API key is Organization-owned machine authority, not a Member and not a Role.

   • Issue time. Its Capabilities and Scopes must be a subset of the issuer's current authority.
   • Afterwards. It survives that person's departure or demotion, which is why administrators holding api_keys.read can revoke keys independently.
   • Secrets and management. Secrets are shown once, key management is session-only, and no key can create, read, or revoke a key whatever it declares.

   If someone needs a scheduled integration, issue a key with the narrowest Capabilities that work. Do not hand out Administrator and rely on trust.

6. 6

   Review what changedCopy Anchor Link

   Membership, Role, and RoleAssignment changes are audited with the actor, the target, and a before/after summary. The activity log has its own screen under Settings → Activity Log, is also one of the catalogue reports, and is gated by audit.read. Order and Registration details show the same entries for their own record, and removing a Member ends access while keeping their name attached to past actions.

RelatedCopy Anchor Link

• Capabilities — the model in full
• Organizations — ownership and tenancy
• Export your data — the activity log as a report