How Labels Differ from Extensible Fields
The PPM module provides two ways to classify projects and work items: labels and extensible fields. They serve different purposes and operate at different scopes. This page explains the distinction.
Labels: free-form tags
Labels are the same tagging mechanism used across the Raytio platform (the FND label system). They are:
- Tenant-scoped — labels are defined at the tenant level and shared across all projects
- Free-form — any user with appropriate permissions can create a new label
- Many-to-many — a work item can have multiple labels, and a label can be applied to many work items
- Flat — labels have no hierarchy or grouping; they are simple name–colour pairs
Labels are best for ad-hoc, cross-cutting classification. Common uses include:
- Tagging work items by technology area (
frontend,backend,database) - Flagging items that need attention (
blocked,needs-design,quick-win) - Marking items for specific workflows (
ready-for-review,needs-qa)
Because labels are tenant-wide, they provide consistency across projects. A blocked label means the same thing in every project.
Extensible fields: structured attributes
PPM extensible fields are different. Attributes are grouped into categories — a named group of related attributes, defined once per tenant and then assigned to the entity types they apply to. Extensible fields are:
- Tenant-level definitions — a category is defined once per tenant and then assigned to the entity types it applies to (
PPM_PROJECT,PPM_WORK_ITEM, optionally restricted to a specific work item subtype such asEPICorBUG) - Structured — each category carries a set of typed attribute definitions (text, number, date, boolean, lookup) rather than a single name–colour pair
- Multi-assignment — a project or work item can have several categories assigned to it at once; one assignment may optionally be marked as the record's primary category for display purposes
- Managed — only tenant administrators can create or modify category and attribute definitions; category assignments follow the same read/write permissions as the project or work item they extend
Extensible fields are best for structured, validated, reportable metadata. Common uses include:
- Classifying work by contract type, cost centre, or regulatory label
- Recording numeric or date-based attributes such as budget amount, story points, or a compliance review date
- Capturing risk rating, priority, or status from a controlled list of values
Because category and attribute definitions live at the tenant level, the same category can be reused consistently across every project, while assignments still let each entity type — or work item subtype — opt into only the categories that apply to it. See Extensible Fields (FND EFF) for the underlying data model.
Comparison
| Aspect | Labels | Extensible fields |
|---|---|---|
| Scope | Tenant-wide | Tenant-level definitions, assigned per entity type |
| Created by | Users with label permissions | Tenant administrators |
| Assignment | Multiple labels per item | Multiple categories per item, one optionally primary |
| Structure | Flat (name + colour) | Structured, typed attribute definitions, grouped by category |
| Best for | Cross-cutting tags and flags | Structured, validated, reportable metadata |
| Shared across projects | Yes | Yes — definitions are tenant-level |
When to use which
- Use labels for cross-cutting concerns that apply across projects — technology areas, workflow states, or ad-hoc tags. A work item can carry many labels at once.
- Use extensible fields to record structured, typed attributes on a project or work item — such as risk rating, budget, or compliance status — that need validation and reporting rather than free-form tagging.