Option Sets
Reusable, versioned lists of choices. Point many fields at one set, and every field that uses it changes together.
An option set is a named, versioned collection of choices that multiple Select and MultiSelect custom fields share. Instead of each field maintaining its own private inline options list, fields bind to an option set version. When business requirements evolve, an administrator creates a new version, updates the choices, and publishes it — immediately updating every bound field across the product without manual field-by-field updates.
Three kinds of Option Sets
SCRIPE distinguishes three kinds of option sets based on their origin, ownership, and editability rules:
| Kind | Owner | Who can edit | Scope |
|---|---|---|---|
| Seeded (Platform-maintained) | Platform | Nobody (Read-only) | Global (All tenants) |
| Platform-created | Platform | Platform administrators | Global or tenant-scoped |
| Tenant-created | Tenant | Tenant administrators | Tenant workspace only |
Version lifecycle and states
Every option set manages its choices through immutable versions. A version moves through four discrete lifecycle states:
| Status | Meaning | Next state |
|---|---|---|
| Draft | Editable draft version. Choices can be added, updated, reordered, or deactivated. Not visible on active record forms until published. | Published (via Publish action) |
| Published | The active, live version. Bound fields render exactly these choices on create and edit forms. Immutable. | Deprecated (when a newer draft is published) |
| Deprecated | Superseded by a newer published version. Historical records referencing choices in this version continue to render correctly. Cannot be bound to new fields. | Archived (when retired) |
| Archived | Permanently retired from active use. Retained strictly for historical audit trails. Immutable. | None (Terminal state) |
Exactly one version can be Published at any time. Publishing a draft automatically deprecates the previously published incumbent version in a single atomic operation.
Creating and editing a draft version
To add or modify choices in an option set, follow the staged versioning workflow:
- Click Create draft version on the option set detail panel. A new draft is initialized.
- Enter a unique Key and English label for each option. Both are required before saving is enabled. You can optionally provide Arabic labels, color tints, icon keys, and sort orders.
- Click Save draft to persist the options list. The draft is saved to the server but remains unexposed to active record forms.
- When ready, click Publish version. The version becomes live and all bound fields immediately serve the updated choices.
Binding fields to an Option Set
Fields with value types Select or MultiSelect can bind to an option set instead of maintaining inline options — either attached in the same step as creating the field, on the create form itself, or through one of three lifecycle actions available afterward on a field that already exists:
| Action | What it does | Effect on existing data |
|---|---|---|
| Bind | Attaches a custom field definition to an option set's published version. | Field switches from inline options to the option set's choices. Previously saved values are preserved. |
| Switch version | Points a bound field to a newer published version of the same or another option set. | Field begins offering the new version's choices. Historical records continue rendering previously selected options. |
| Detach (Unbind) | Removes the option set binding, reverting the field back to standalone inline options. | Field stops querying the option set. Stored record values remain intact. |
Platform administrator capabilities
Platform Super Administrators operate with elevated system-wide governance rights:
- Create global option sets shared across all tenant workspaces.
- Create and publish new versions for platform-owned (non-seeded) option sets.
- Manage option set availability across multi-tenant boundaries.
- Inspect version chains and audit logs for all option sets platform-wide.
- Respect system-managed boundaries: platform-maintained seeded sets remain immutable for platform admins as well.
Key operational rules to remember
- Option sets are versioned, not directly edited: choices are modified by creating a draft and publishing it.
- Keys are permanent identifiers: once an option is published with a key, do not change its key in subsequent versions if you want existing values to remain mapped.
- Deactivate rather than delete: deactivating an option stops it from being offered on new forms while preserving it on historical records.
- Single published version: only one version is active at a time; publishing a draft automatically deprecates the previous version.
- System-managed sets are strictly read-only: seeded standard sets cannot be modified by any user or administrator.