Custom fields, screens and schemes
Custom fields extend work items. Screens decide which fields appear where, and schemes decide which work types, priorities and resolutions a project uses.
Field types
Section titled “Field types”| Type | Value |
|---|---|
| Text, paragraph | A string, with an optional maximum length |
| Number | A finite number, with optional minimum and maximum |
| URL | An absolute http or https address |
| Date, date-time | A calendar date, or a date and time |
| Checkbox (boolean) | true or false |
| User | An active person with access to the project |
| Group | A group |
| Select | One configured option |
| Multi-select | Several unique configured options |
| Cascading | A parent option and a child option |
Select options are unique, non-blank strings. A work item holds at most 250 custom field values.
Contexts, defaults and settings
Section titled “Contexts, defaults and settings”- Context. A field is global or limited to projects and work types. An empty list means all values within the enclosing scope.
- Default values and options are validated on the server and during import.
- Required, optional or hidden. Required fields apply on every write in context. Hidden data cannot be overwritten by accident.
- A field can have a description and renderer settings.
Screens and tabs
Section titled “Screens and tabs”Screens decide which fields appear when a work item is created, edited and viewed. A screen can have tabs. Type-to-screen mappings and field configurations resolve deterministically. The create dialog, the edit form and the side panel follow the project’s screens.
Schemes
Section titled “Schemes”- Work type schemes choose which types a project can use, including admin-defined types with their own names and icons.
- Priority schemes and resolution catalogs are reusable.
- Status categories group statuses for reports and boards.
A project’s priority and work type schemes are assigned in its settings.
Deleting and cleaning up
Section titled “Deleting and cleaning up”Deleting a field keeps its history: historical values stay readable, and search indexes rebuild safely. A field first goes to the bin (trash) and is purged afterwards. Before deletion you can move its values to another field of a compatible type, or replace options. A check shows how many work items would change, stay, or already hold another value.
A usage report for site administrators lists custom fields, schemes, shared workflows, priorities and resolutions with what uses them and which are unused, and offers the request that cleans each unused item up. Cleanup checks the references again and refuses if something has started using the item.
Capacity limits protect the service: a site can hold up to 700 custom fields and a project 200.
Export, import and copy
Section titled “Export, import and copy”A project administrator can export a project’s configuration to a file (orbit.configuration/v1). It contains custom work types, project fields, screens, field configurations, workflows with their rules and approval steps, assignments and schemes. References travel by name, and the file contains no tenant IDs. It lists what another Orbit must already have, and what was left out.
You can load the file into a project, or copy the configuration from another project. Both first run a dry run that reports what will be created, reused and replaced, what is missing, names already taken and work that blocks the change. Applying then checks again. In a company-managed project only a site administrator loads or copies a configuration.
Status
Section titled “Status”All of the above is built.