Events in BackOps: One Workspace for Every Job

An event is the workspace for one job: a show, a production, a rental, a conference, an activation. Everything your team does for that job lives inside it, from the schedule and crew to collaborators, areas, files, tasks, advances, and procurement.

Without one shared place per job, the details of a production scatter. The run of show is in one spreadsheet, the crew list in another, the client's requests in an email thread, and the load-in time in someone's head. Every person on the job keeps their own partial copy, and the copies drift apart the moment plans change.

Why Events Matter

Giving each job its own event means there is one answer to "where is the information for this show?" The schedule, the people, the spaces, and the paperwork for the job sit together, and everyone on it sees the same version.

It also means each job can be set up the way that kind of job actually runs. A full production needs crew, a venue, rigging details, and a production manager. A rental needs a pickup date and the person collecting the gear. Instead of one generic form that leaves most fields blank on most jobs, your organization defines event types for the kinds of jobs it runs, and each event carries exactly the details its type asks for.

And because every job is its own event, the organization still gets the bird's-eye view. The events table lists every job with its type, status, location, intake progress, and key details side by side, so you can see the whole season at once and jump into any job from there.

How Events Work

flowchart LR
  T[Event type] -->|defines fields, intake, template, effects| E[Event]
  E --> A[Areas]
  E --> C[Collaborators]
  C --> CR[Crew]
  E --> W[Schedule, tasks, advances, files, resources]

Every event starts from a few building blocks.

An event type is your organization's definition of a kind of job. It decides which attributes (details such as the ship date or venue) and roles (named parts such as Project manager) the event shows on its profile, which intake questions are asked when it is created, which base template builds its starting structure, and which effects automate follow-up work. An event can also be created without a type, which is useful for trying things out or building a template, but real jobs should use one. See Event Types.

Collaborators are the companies and groups working the event: your own team, the client, the venue, the audio vendor, the caterer. People on an event always belong to a collaborator as crew. Every event has a default collaborator, the one that represents your organization, so there is always a team for the first person to join. Modeling collaborators as groups rather than fixed roles means a vendor can also be a sponsor, or one company can provide both power and staging, without forcing anyone into the wrong box.

Areas are the spaces inside the event, such as stages, front of house, catering, or breakout rooms. They let the team plan and read one part of the event on its own. See Areas.

An event can also point at a location, one of your organization's saved places such as a venue or warehouse. A location is a real place shared across events; an area is a space inside one event.

The Life of an Event

An event of a type is saved as a draft once someone moves past the first create-event step, and becomes active when they select Create event. A freeform event, created without a type, is active from the start. Drafts keep everything entered so far and can be finished later.

When a job is over, or cancelled, archive it to take it out of active work. Archived events keep all their data and can be unarchived at any time. Delete is for events you never want back, such as test events or duplicates, and cannot be undone.