Sections and Attributes: Building Types from a Shared Library
How the attribute library, type sections, and placement settings work across BackOps, what Required, Visible, and Editable mean, and what archiving keeps.
Every type in BackOps is built the same way: attributes come from a shared library, and the type arranges them into sections. This page explains that structure once, for events, crew, collaborators, resources, and locations. The pages for each kind of record cover its own editor and screens.
The Attribute Library
An attribute is a typed field, such as a date, a select list, or a file. Each kind of record has one attribute library for the whole organization: event attributes, crew attributes, collaborator attributes, resource attributes, and location attributes are separate libraries.
You define an attribute once, with a name and a field type. The field type is fixed when the attribute is created, because values already entered depend on it. To change it, create a new attribute. A Select or Multi-select attribute also carries its list of options. When a value is picked, BackOps stores which option was chosen rather than its text, so editing an option's wording, where the editor allows it, keeps every saved value pointing at the right choice.
In the API and some older screens, collaborator and location attributes are called properties. They are the same thing: the app calls them attributes.
Sections and Placements
A type is laid out in named sections, in an order you control. A new type starts with one section named Details, and you add more as the data grows: Staff, Venue details, Certifications, Billing.
Putting an attribute into a section is a placement. A placement points at the library entry, so the same attribute can sit on several types and its values stay comparable across all of them. Renaming the attribute in the library renames it on every type that uses it.
Each placement carries its own settings. They live on the placement, not on the attribute, so the same attribute can be required on one type and optional on another.
| Host | Placement settings | What they do |
|---|---|---|
| Events | Required, Tracked, Review, due date, assignee | Required details must be filled to create the event. Tracked details become tasks until they are filled. Review sends changes to a reviewer. Tracked items can carry a due date and a default assignee. Event types also place roles in the same sections. |
| Crew | Required, Visible, Editable | Visible shows the field to the crew member. Editable lets them change their own value. |
| Collaborators | Required, Visible, Editable | Visible shows the field to the collaborator. Editable lets them change their own value. |
| Resources | Required, Procurement, Inventory, Pricing | Procurement and Inventory choose where the field appears. Pricing makes the attribute drive variants, price modifiers, or units. |
| Locations | None | A placement only sets the field's position. |
The event settings are explained in detail in setting up an event type and tracking defaults. Resource pricing is covered in resource types and attributes.
Values Belong to the Record
A record's values are stored on the record itself. The type only decides which fields are shown. That has three practical effects:
- Removing an attribute from a type, or deleting a whole section, hides the field but keeps the values already entered. Placing the attribute again brings them back. Some placements are protected: on an event type, an attribute that another placement's due date is calculated from, or a role named as another placement's default assignee, cannot be removed until that dependency is cleared, and on a resource type an attribute that variants are built on cannot be removed until the variants are reworked.
- Taking a type off a crew member or collaborator keeps their values. They reappear if a type that shows those fields is assigned again.
- Changing an event's or a location's type keeps the values filled in under the old type.
Deleting, Archiving, and Restoring
BackOps never deletes data your team has entered just because a definition is removed. When you delete something still in use, it is archived instead.
- Attributes. Deleting an attribute that holds a value on any record archives it. Event and crew attributes are also archived while they are placed on a type, and resource attributes while a variant or price modifier uses them. Otherwise the attribute is deleted and removed from every type. An archived attribute keeps its values but cannot be placed on a type again until it is restored.
- Types. Deleting a type that records still use archives it. An archived type keeps those records' values but cannot be assigned to new records until it is restored.
Event, crew, collaborator, and resource attributes can be restored, as can event, crew, and collaborator types. Location types and attributes can be archived but not restored. Resource types are not archived: a resource type is deleted outright, and the delete is refused while another type uses it as a component or a resource uses one of its rate cards.