Skip to main content

Picklist

Picklist Attribute​

A Picklist attribute provides a controlled set of selectable values for a business field. Instead of allowing unrestricted text entry, administrators define the available choices so information is captured consistently and can be used reliably in forms, rules, reporting, and process automation.

Picklists can be configured as standard static lists or can draw their choices from supported platform entities, such as Roles, Types, and Templates. This makes the attribute reusable and keeps its options aligned with existing platform configuration.

This capability is useful when a process requires consistent categorisation, assignment, classification, or status-related input.

Key capabilities​

  • Static option lists Create a defined list of business values, such as Incident, Service Request, Change Request, and Query.

  • Platform-driven option sources Populate a picklist from supported configured entities rather than maintaining the values manually. The demonstrated options include:

    • Roles
    • Types
    • Templates

  • Single-select or multi-select Configure the field to accept one value, such as one priority or category, or several values, such as multiple applicable roles or required reviewers.

  • Default option Set a preselected value for new records to reduce repeated data entry and promote consistent starting values.

  • Disable individual options An administrator can disable an option that should no longer be available for new selection while retaining it for historical records. This prevents users from selecting retired or obsolete values without affecting existing data that already uses that option.

  • Rule-based option enablement and visibility Picklist options can be controlled by configured conditions. An option can be enabled, disabled, or made available based on the current record context, such as another attribute value, selected type, lifecycle state, or applicable business condition. Filter conditions follow the same rules, except that a filter condition is not tied to a record, so rules that depend on record data leave the option in the value list — see Picklist Options in Filter Conditions.

  • Display names Configure user-friendly labels for options, so technical or internal values can be presented in business language.

  • Use in business logic The selected value can be used as an input to configured rules, lifecycle actions, notifications, queries, reports, and dashboards.

Use case: Context-driven issue categorisation​

An organisation uses one application for customer service, internal requests, and quality issues. A field named Request Category contains values such as Incident, Service Request, Change Request, and Quality Deviation.

When the user selects a particular request type, rules can enable only the relevant category options and disable those that do not apply. For example:

  • A service-related record can display Incident and Service Request.
  • A quality-related record can display Quality Deviation.
  • An obsolete category can remain visible on existing records but be disabled for new records.

This ensures users choose only valid categories while preserving the historical accuracy of earlier records.

Use case: Role-based process participation​

A process record needs to capture the roles responsible for review or execution. A Picklist attribute named Applicable Roles can use Roles as its option source instead of maintaining a separate manual list.

The process owner can select whether one role or multiple roles are required. Rules can then control the available options based on the process type or current lifecycle state.

For example, during initial planning, users may select Project Manager and Process Engineer. When the record reaches quality review, Quality Reviewer becomes enabled as an available option. If a role is no longer used by the organisation, it can be disabled for future records without removing it from existing process history.

Use case: Template selection by record type​

A Picklist can use Templates as its source to help users select the correct preconfigured template for a record.

For example, when a user creates an inspection record, the available templates can be limited to inspection-related templates. When a user creates a service request, the available values can be limited to service templates. This avoids incorrect template selection and helps ensure each record starts with the appropriate configured structure.