Types, Attributes, and Roles: How BackOps Records Get Their Shape

A type is your organization's definition of a kind of record: which fields it carries, how those fields are grouped, and, for events, which people it needs and what happens automatically when its details change.

Every live events business tracks different information for different kinds of things. An audio engineer and a runner need different details on file. A venue and a catering vendor answer different questions. A full production and a dry rental need different data, different people, and different follow-up. A single fixed form for each kind of record either leaves most fields blank or forces your team to keep the real information somewhere else.

Why One Pattern Matters

BackOps uses the same building blocks everywhere a record needs a shape of its own. Once you have set up one kind of type, you already know how the others work: you build a library of fields, arrange them on types in sections, and fill in values on each record. The editors look and behave the same way across events, crew, collaborators, resources, and locations, and the vocabulary is the same in every one of them.

The shared pattern also keeps your data comparable. Because a field is defined once and placed on as many types as need it, a "Union local" attribute means the same thing on every crew type that uses it, and a "Dietary requirements" field on two event types can be compared across both.

How the Pattern Works

The pattern has four pieces. Every host uses the first three. Events add the fourth.

• Attributes are typed fields, such as a date, a number, a select list, a file, or a pointer to a crew member. Each kind of record has an organization-wide attribute library, and an attribute is defined there once.
• Types arrange attributes into named sections, such as Staff, Venue details, or Certifications. Placing an attribute on a type is a reference to the library entry, not a copy, so renaming it in the library renames it everywhere. Each placement can carry its own settings, such as Required.
• Roles are named parts an event needs filled by a person or company, such as Project manager, Production manager, or Client. A role links to a real crew member or collaborator rather than storing their name as text. Roles exist on event types only.
• Effects are rules on an event type that act when conditions are met: notify someone, add a person to the event, create an activity, or fill in an attribute or role. Effects exist on event types only.

flowchart LR
    LIB["Attribute library<br/>(defined once)"] --> SEC["Sections on a type"]
    ROLES["Role library<br/>(events only)"] --> SEC
    SEC --> TYPE["Type"]
    TYPE --> REC["Record of that type<br/>(values and role occupants)"]
    FX["Effects<br/>(events only)"] -.act on.-> REC

A record gets its type, and then shows that type's sections with the values your team fills in. Values belong to the record, not to the type, so changing a record's types or removing an attribute from a type does not erase what was already entered.

Where the Pattern Applies

Crew members and collaborators can hold several types at once, each one a profile. A stagehand who is also a rigger can carry both types and show both sets of sections.

Next to types, a second shared rule governs how crew members, collaborators, and resources move between your organization and your events: the organization record is the master, and an event works on a linked copy. See organization records and event copies.