How Permissions and Access Work in BackOps

Permissions in BackOps are the set of actions a person may take in one specific place: an organization, an event, or a collaborator or area inside an event. Live events bring together people with very different stakes in the same job. A producer needs the whole event, a venue contact needs their own advance and files, and a stage manager needs one area. BackOps gives each of them exactly that slice instead of one shared login or one all-or-nothing invite.

Why Permissions Work in Layers

A single "member or not" switch fails on real events. Either the vendor sees everything, including budgets and other vendors' information, or they see nothing and the team goes back to email. BackOps solves this by checking access in layers, each with its own permission set:

• Organization: the organization's own pages, libraries and settings, plus its departments and locations, which have their own permissions.
• Event: everything inside one event.
• Collaborator: one collaborator on an event, such as a venue or a vendor, and its crew, advance and files.
• Area: one area of an event, such as Main Stage or Catering.

The layers do not flow into each other the way you might expect. Being an organization admin does not by itself put you inside an event: inside an event, access comes only from the permissions granted on that event. An organization admin can manage who has access to the organization's events, and can Join event from the organization's events table to be added to one. Joining with a license makes them event admin; joining as a guest gives basic access only.

Inside an event the direction is reversed. An event admin holds every collaborator and area permission on that event without being granted them one by one. Everyone else gets collaborator and area access per collaborator and per area.

flowchart TD
    O["Organization permissions"] --> D["Department permissions"]
    O --> L["Location permissions"]
    E["Event permissions"] --> C["Collaborator permissions (one per collaborator)"]
    E --> A["Area permissions (one per area)"]
    O -. "no carry-over" .-> E

How a Permission Is Granted

Permissions are additive. Each one allows a specific action, such as viewing collaborators, adding activities or approving an advance, and holding more permissions only ever widens what a person can do. Each layer also has an admin permission that covers everything in that layer.

In the app, permissions are presented as a matrix with three levels for each row: View, Edit and Admin. Ticking View or Edit adds the permissions that make up that level, and ticking Admin grants the row's admin permission, which covers everything. Expanding a row shows the individual permissions so you can set a custom mix. List views summarize a person's access with the same words: Viewer, Editor, Admin, or Custom when the mix does not match a level.

You set a person's event and collaborator access from the Permissions tab of their crew record on the event, and their organization access from the Permissions tab of their record in the organization's crew database (Crew in the organization sidebar). The add and invite dialogs carry the same matrix, so access can be chosen at the moment someone is brought on.

How Licenses Limit Permissions

A license decides what a person can reach; permissions decide what they may do there. Most event, collaborator and area permissions need Event Pass working access. A person with a BackOps Pro seat has that access on every event in the organization, and a person without a Pro seat can be given an Event Pass seat on a specific event.

Someone with neither, such as a freelancer or a vendor's staff, can still be invited to an event. They receive only the permissions that do not need Event Pass, and only on their own collaborator: reading it, managing its crew, adding activities, editing its advance, and editing and administering its files. Settings, deletion and advance approval stay with licensed users.

If a license lapses, the permissions it supported stop working but are not deleted. They apply again once the license is restored.

Roles in This Page and Elsewhere

"Role" in this page means a level of access, such as admin or viewer. BackOps also has event roles, which are named parts on an event type (for example Project manager or Production manager) filled by crew or collaborators. Event roles name who owns what on the job, and they are set up with event types rather than in the permission matrix.