# Fluid Configuration Field Reference Guide

**Understanding every configurable field, its purpose, and its downstream impact.**
A configuration inventory and governance guide for administrators.

> Generated from the Fluid product configuration as at August 2026. Labels shown are the
> product defaults; your instance may display renamed labels (see [Section 12](#section-12--field-labels--renaming-project-labels--field-names)).

---

## Contents

- [Introduction](#introduction)
  - [How the guide is organised](#how-the-guide-is-organised)
  - [How to read the reference tables](#how-to-read-the-reference-tables)
  - [Understanding cross-functional impact](#understanding-cross-functional-impact)
  - [Three principles that apply to almost everything in this guide](#three-principles-that-apply-to-almost-everything-in-this-guide)
- [Section 1 — Project Classification & Portfolio Structure](#section-1--project-classification--portfolio-structure)
- [Section 2 — Project Lifecycle, Status & Governance Fields](#section-2--project-lifecycle-status--governance-fields)
- [Section 3 — Project Community & Ownership](#section-3--project-community--ownership)
- [Section 4 — Financial Configuration](#section-4--financial-configuration)
- [Section 5 — Metadata Management (Master Data)](#section-5--metadata-management-master-data)
- [Section 6 — Custom Properties](#section-6--custom-properties)
- [Section 7 — Resource & Organisation Configuration](#section-7--resource--organisation-configuration)
- [Section 8 — Timesheet Configuration](#section-8--timesheet-configuration)
- [Section 9 — Boards & Workflow Configuration](#section-9--boards--workflow-configuration)
- [Section 10 — Catalogs](#section-10--catalogs)
- [Section 11 — Governance Assessments](#section-11--governance-assessments)
- [Section 12 — Field Labels & Renaming](#section-12--field-labels--renaming-project-labels--field-names)
- [Section 13 — Cleanup & Rationalisation Playbook](#section-13--cleanup--rationalisation-playbook)
- [Final Recommendation](#final-recommendation)

---

## Introduction

Configuring Fluid is much more than setting values in administration pages. Many fields
influence multiple areas of the platform, including:

- Project workspaces
- Governance processes and approval workflows
- Timesheets and resource planning
- Financial management and capitalisation
- Portfolio reporting, dashboards and executive reporting
- Board workflows and project intake pipelines
- Security and project visibility

This guide documents every configurable project property in Fluid so that administrators can
review, rationalise, and clean up their configuration with confidence. For each field it explains:

- What the field is and what it controls
- Where it is configured and where it appears
- How it is typically used, with realistic business examples
- What other areas it impacts across the platform
- What should be considered before changing or removing it

The guide is written for both system administrators and business users. It uses business
terminology wherever possible, and it is intended to function as both a configuration inventory
and a governance guide — enabling you to assess which fields should be retained, modified,
consolidated, or removed during a cleanup exercise.

### How the guide is organised

| Section | Covers |
|---|---|
| 1. Project Classification & Portfolio Structure | The built-in fields that classify and group every project |
| 2. Project Lifecycle, Status & Governance | Status, methodology, phases, dates and stage gates |
| 3. Project Community & Ownership | The people fields that drive accountability and security |
| 4. Financial Configuration | Cost, funding, capitalisation and currency fields |
| 5. Metadata Management (Master Data) | The admin-maintained lookup lists behind the dropdowns |
| 6. Custom Properties | Your own fields — every setting, data type and downstream flow |
| 7. Resource & Organisation Configuration | Divisions, departments, teams and rate cards |
| 8. Timesheet Configuration | Time capture, deadlines and compliance settings |
| 9. Boards & Workflow Configuration | Intake boards, pipelines, approval routing and project sync |
| 10. Catalogs | Organisation-wide reference data (applications, vendors, KPIs…) |
| 11. Governance Assessments | Assurance models, criteria and manage-by-exception |
| 12. Field Labels & Renaming | Renaming built-in fields — and what to watch for |
| 13. Cleanup & Rationalisation Playbook | Decision framework, safety matrix and review checklist |

### How to read the reference tables

Each section presents its fields in a structured table with these rows:

| Row | Meaning |
|---|---|
| **Field Type** | Text, Number, Date, Dropdown, Multi-select, Boolean (Yes/No toggle), Lookup, Currency, User (person picker), Rich Text, Calculated |
| **Description** | What the field represents and why an organisation uses it |
| **Location** | Where it is configured and where it is visible |
| **Functional Impact** | How it affects the rest of the system — workflows, reports, permissions, calculations, dashboards, filtering, notifications, integrations. Where a field has no downstream impact, this is stated explicitly |
| **Dependencies** | Required fields, related fields, lookup lists, validation, parent–child relationships |
| **Example** | A realistic business example |
| **Cleanup Considerations** | What to check before modifying or deleting |
| **Best Practice** | Recommendations for use, naming, standardisation and governance |

Field names are the defaults as they appear in Fluid — many labels are renameable, see
[Section 12](#section-12--field-labels--renaming-project-labels--field-names). Where a field
needs more explanation than a table cell allows, a detailed note follows beneath the table.

### Understanding cross-functional impact

A cross-functional impact occurs when a configuration field is used outside the area where it is
maintained. A good configuration decision always considers its downstream impact.

| Field | Configured in | Also impacts |
|---|---|---|
| Portfolio | Project Settings → Portfolios and SubPortfolios | Security (who can see projects), approvals, reporting, dashboards, financial roll-ups, resource planning |
| Project Type | Project Settings → Project Types | Which workspace sections appear, timesheet booking categories, governance scoping, reporting |
| Funding Source | Project Types page → Funding Source tab | Financial reporting, budget reviews, portfolio analysis |
| Custom Property | Data Administration → Custom Properties | Reporting, workflows, approvals, dashboards, board-to-project synchronisation, calculated expressions |

### Three principles that apply to almost everything in this guide

Before reading the field-by-field reference, understand three behaviours of the platform that
shape nearly every cleanup decision:

**1. Projects store the name of a lookup value, not a link to it.**
When you set a project's Portfolio, Project Type, Category, Funding Source, Status or similar,
the project records the *text* of the chosen value. If you later rename or delete the value in
administration, existing projects keep the old text. They still display and export it, but they
no longer match the configured list — so they silently drop out of list-driven filters, and users
will be forced to pick a valid value the next time they edit the project.

Only three areas automatically update existing records when values change: methodology phase
renames, division/department/team renames, and project status activation changes. Everywhere
else, a rename or delete requires you to re-stamp affected projects yourself (the bulk-edit tools
are the usual way).

**2. Deactivating is almost always safer than deleting.**
Many lists have an Active flag (or a "User Locked" flag). Deactivating removes a value from
pickers for new records while historical records keep working. Deleting is permanent, is not
usually blocked by usage, and leaves orphaned values behind on existing records. Prefer
deactivation; treat deletion as a final step done only after existing data has been migrated.

**3. Bulk uploads replace the whole list.**
Most metadata bulk-edit workbooks work on a *replace* basis: any row you omit from the uploaded
sheet is deleted, with the same cascade effects as deleting it on screen (for example, omitting a
Portfolio also deletes its SubPortfolios). Always start from a fresh export, edit it, and
re-upload the complete sheet. The Division/Department/Team workbook is the exception — it uses an
explicit "Delete Record" column.

---

## Section 1 — Project Classification & Portfolio Structure

**Purpose:** these built-in fields determine how projects are grouped, governed, secured and
reported across the organisation. They are set on each project (Project Workspace → Settings →
Edit Details) and their available values are maintained by administrators
([Section 5](#section-5--metadata-management-master-data)).

### Title

| | |
|---|---|
| **Field Type** | Text (required) |
| **Description** | The project's name — the primary identifier users see everywhere |
| **Location** | Project Settings → Key Details; set at creation |
| **Functional Impact** | Drives search, all report output, notification subject lines. No calculations |
| **Dependencies** | Required; up to 510 characters |
| **Example** | "ERP Modernisation — Phase 2" |
| **Cleanup Considerations** | Renaming changes how the project appears in every report and email; historic exports keep the old name |
| **Best Practice** | Agree a naming convention (e.g. `<Portfolio> – <Initiative> – <Phase>`); publish it in the Project Creation Instructions field |

### Code

| | |
|---|---|
| **Field Type** | Text (required, 6 chars) |
| **Description** | Short prefix used to build the unique IDs of the project's risks, issues and schedule items |
| **Location** | Project Settings → Key Details |
| **Functional Impact** | Every risk/issue/schedule item reference (e.g. `ERP-124`) starts with this code |
| **Dependencies** | Required; max 6 characters |
| **Example** | `ERP` |
| **Cleanup Considerations** | Changing it changes the prefix of future item references; existing references remain — avoid changing once items exist |
| **Best Practice** | Use short, stable, unique mnemonics; never recycle a code from a closed project |

### Portfolio

| | |
|---|---|
| **Field Type** | Dropdown (lookup) |
| **Description** | Strategic grouping of the project, aligned with business structure |
| **Location** | Project Settings → Key Details; values from Project Settings → Portfolios and SubPortfolios |
| **Functional Impact** | Security (portfolio Viewers/Administrators gain access to all projects in the portfolio), approvals (portfolio Approver), governance model scoping, portfolio dashboards, financial and resource roll-ups, filters |
| **Dependencies** | Parent of SubPortfolio; changing it re-derives project permissions (applied within minutes, not instantly) |
| **Example** | "Digital Transformation" |
| **Cleanup Considerations** | Deleting a portfolio also deletes its sub-portfolios and can silently remove users' access to its projects; projects keep the old name and drop out of filters |
| **Best Practice** | Keep the portfolio list short and stable — it is your security and reporting backbone. Review Viewers/Administrators/Approver whenever the org changes |

### Sub portfolio

| | |
|---|---|
| **Field Type** | Dropdown (cascading) |
| **Description** | Secondary grouping within the chosen portfolio |
| **Location** | Project Settings → Key Details |
| **Functional Impact** | Reporting hierarchies, dashboards, portfolio analysis, resource dashboards, filters |
| **Dependencies** | Child of Portfolio — only values belonging to the selected portfolio are valid; an invalid combination is cleared on save |
| **Example** | "Customer Platforms" under "Digital Transformation" |
| **Cleanup Considerations** | Deleted with its parent portfolio; projects keep the old text |
| **Best Practice** | Mirror a real organisational or investment structure; avoid duplicating portfolio names at sub-portfolio level |

### Tier

| | |
|---|---|
| **Field Type** | Dropdown (lookup) |
| **Description** | Priority, scale or governance band of the project |
| **Location** | Project Settings → Key Details; values from Project Settings → Tiers and Business Drivers |
| **Functional Impact** | Governance intensity, reporting, filters, available in governance/reporting expressions (e.g. `[Tier] = "Gold"`) |
| **Dependencies** | Parent of Business Driver — drivers can be linked to a tier; changing tier clears a driver that is not valid for it |
| **Example** | Tier 1 / Tier 2 / Tier 3 |
| **Cleanup Considerations** | Tiers are add/deactivate only (no rename). Before deleting a tier, first unlink or delete all business drivers linked to it — otherwise drivers can be left stranded and disappear from pickers |
| **Best Practice** | Keep to 3–4 tiers with documented entry criteria (budget, risk, complexity); use tiers to drive governance intensity, not reporting categories |

### Business driver

| | |
|---|---|
| **Field Type** | Dropdown (lookup) |
| **Description** | The strategic objective or justification behind the project |
| **Location** | Project Settings → Key Details; values from Tiers and Business Drivers |
| **Functional Impact** | Investment prioritisation, executive reporting, filters. Editable by anyone who can edit the project (not locked by the admin-field lock) |
| **Dependencies** | Optionally linked to a Tier (blank = all tiers) |
| **Example** | "Regulatory Compliance", "Revenue Growth", "Cost Reduction" |
| **Cleanup Considerations** | Add/deactivate only (no rename); deactivated values stay on existing projects |
| **Best Practice** | Standardise on a small strategy-aligned set; revisit annually alongside strategic planning |

### Project Type

| | |
|---|---|
| **Field Type** | Dropdown (lookup) |
| **Description** | The primary classification of the project — and the field with the largest downstream footprint in Fluid (see detailed note below) |
| **Location** | Project Settings → Project Administration; values from Project Settings → Project Types |
| **Functional Impact** | Controls which workspace sections users see, which activities can be booked on timesheets, governance scoping, reporting, filters, chart colours |
| **Dependencies** | Required. Cannot be switched between a Project and a Program type. Deleting a type also deletes its timesheet activities |
| **Example** | "Strategic Initiative", "Business As Usual", "Application Development" |
| **Cleanup Considerations** | Deleting/renaming does not update existing projects; renames also orphan timesheet exclusion settings that reference the old name |
| **Best Practice** | Keep types few and meaningfully different — each should genuinely need different workspace sections, activities or governance. Don't use Project Type as a reporting category (that's what Category and custom properties are for) |

### Project Category

| | |
|---|---|
| **Field Type** | Dropdown (lookup) |
| **Description** | Secondary business classification for analysis |
| **Location** | Project Settings → Project Administration; values from Project Types page → Project Category tab |
| **Functional Impact** | Dashboard filtering, investment analysis, resource demand reporting; also scopes which project-workflow boards apply to a project |
| **Dependencies** | None required |
| **Example** | "Cyber Security", "Customer Experience" |
| **Cleanup Considerations** | Renaming/deleting silently unbinds any intake board configured to apply to that category — the board disappears from those project workspaces |
| **Best Practice** | Standardise values before rolling out boards that depend on them; document which boards reference each category |

### Discretionary

| | |
|---|---|
| **Field Type** | Dropdown (fixed) |
| **Description** | Whether the investment is discretionary or non-discretionary |
| **Location** | Project Settings → Key Details |
| **Functional Impact** | Budget reviews, portfolio rationalisation and cost-saving analysis; filterable; available in expressions |
| **Dependencies** | Fixed two-value list (not configurable): "Discretionary" / "Non-discretionary" |
| **Example** | "Non-discretionary" for a regulatory programme |
| **Cleanup Considerations** | None — the list is fixed; clearing values on projects only affects analysis |
| **Best Practice** | Agree a definition with Finance (e.g. "mandated by regulation or contract") and apply it consistently |

### External Reference

| | |
|---|---|
| **Field Type** | Text |
| **Description** | Identifier linking the project to external systems (finance ledger, CRM, other PPM tools) |
| **Location** | Project Settings → Project Administration |
| **Functional Impact** | Integrations, cross-system reconciliation, the key column for bulk edit |
| **Dependencies** | Auto-generated (`<prefix><project number>`) if left blank; prefix set in Project Labels & Field Names |
| **Example** | "SAP-100442" |
| **Cleanup Considerations** | It is the matching key for the Project Details bulk upload — changing it breaks the link to previously exported sheets and external systems |
| **Best Practice** | Populate from the system of record; never reuse references |

### Alternate External Reference

| | |
|---|---|
| **Field Type** | Text |
| **Description** | A second external identifier for another system |
| **Location** | Project Settings → Project Administration |
| **Functional Impact** | Integrations and exports; available to reporting expressions |
| **Dependencies** | None |
| **Example** | "JIRA-PORT-88" |
| **Cleanup Considerations** | Same as External Reference |
| **Best Practice** | Only enable/populate when you genuinely have two external systems of record |

### Confidential

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Restricts project visibility to named members only |
| **Location** | Project Settings → Project Administration (Project Administrators only; requires the Confidential Projects feature) |
| **Functional Impact** | Security and hierarchy: switching it on removes general/portfolio-based access **and** permanently detaches the project from any parent, program and reporting program |
| **Dependencies** | Feature-dependent; Project Administrator only |
| **Example** | An M&A due-diligence project visible only to the deal team |
| **Cleanup Considerations** | Switching it on de-links all hierarchy (this is **not** restored by switching it off) and strips inherited access; plan membership before enabling |
| **Best Practice** | Use sparingly; maintain an explicit member list and review it regularly; expect the project to be absent from roll-ups |

### Description / Requirements / Proposed Solution

| | |
|---|---|
| **Field Type** | Rich Text |
| **Description** | Narrative fields describing the project, its requirements and intended approach |
| **Location** | Project Settings (main page) |
| **Functional Impact** | Displayed in the workspace, searchable, included in exports. No workflow or calculation impact |
| **Dependencies** | None |
| **Example** | A one-paragraph business case summary |
| **Cleanup Considerations** | None significant — free text |
| **Best Practice** | Use the Project Creation Instructions ([Section 12](#section-12--field-labels--renaming-project-labels--field-names)) to tell PMs what "good" looks like for these fields |

### Show Promoted Items on Parent Dashboards

| | |
|---|---|
| **Field Type** | Dropdown (Yes/No) |
| **Description** | Whether items promoted from this project (risks, milestones) roll up to parent/program dashboards |
| **Location** | Project Settings → Key Details |
| **Functional Impact** | Parent and program dashboards — controls upward visibility of promoted items |
| **Dependencies** | Meaningful only for projects in a hierarchy |
| **Example** | "Yes" for projects in a programme |
| **Cleanup Considerations** | None significant |
| **Best Practice** | Default to Yes inside programmes so programme boards see escalations |

### Detailed note — Project Type: the biggest blast radius in Fluid

Project Type is not just a label. Each type carries a **Workspace Components** map that decides,
per section of the project workspace, whether it is *shown to all users*, *shown to
administrators only*, or *hidden for all*. The sections controlled this way are: Methodology,
Governance, Status, Actions & Decisions, Schedule, Impacts, Financials, Revenue, Funding,
Community, Benefits, Ongoing Costs, Boards, Sub Projects, Sub Projects Health Summary, Meetings,
and Documents — 17 in total.

> **Note:** 17 is the maximum. Ten of those sections only appear in the map when the matching
> feature is switched on for the instance (Schedule, Impacts, Financials, Revenue, Funding,
> Community, Benefits, Ongoing Costs, Boards, Meetings). Methodology, Governance, Status,
> Actions & Decisions, Sub Projects, Sub Projects Health Summary and Documents are always
> present. The "Governance" section also displays under your configured Governance label, so it
> may appear under a different name in your instance.

In addition:

- **Timesheets.** Each Project Type owns its list of Project Activities (booking categories). A
  project's type therefore decides what people can book time against
  ([Section 5.3](#53-project-activities-timesheet-booking-categories)). Project types can also be
  excluded from timesheets entirely ([Section 8](#section-8--timesheet-configuration)).
- **Governance.** Governance assessment models are scoped by Project Type (together with Status
  and Portfolio) — [Section 11](#section-11--governance-assessments).
- **Intake.** Board-to-project pipelines match a card property value against the Project Type
  list; a value that doesn't match is silently skipped
  ([Section 9](#section-9--boards--workflow-configuration)).

**Business example.** Project Type = "Strategic Initiative" shows the Benefits, Financials and
Governance sections, requires stage-gate approvals, and offers activities "Business Analysis /
Design / Build / Test / Deploy" on timesheets. Project Type = "Small Change" hides Financials and
Benefits, has no gates, and offers a single "Delivery" activity. Same platform, two very
different experiences — all driven by one field.

**Cleanup guidance.** Because so much hangs off Project Type, treat a change to the type list as
a mini-project: inventory which workspace-component settings, activities, governance models,
timesheet exclusions and boards reference each type before consolidating.

### Detailed note — Portfolio is a security container, not just a grouping

The Portfolio field is unique among classification fields: the portfolio definition carries
**Administrators**, **Viewers** and an **Approver**
([Section 5.1](#51-portfolios--subportfolios-admin-definition)). Assigning a project to a
portfolio grants those people access to it (administrators get full control, viewers get read
access), and the portfolio Approver receives status-change approval requests when the status
approval workflow is enabled. Permission changes triggered by moving a project between
portfolios are applied by a background process — allow a few minutes.

**Risk of deletion.** Deleting a portfolio cascades to its sub-portfolios, and the access users
held through that portfolio is removed on the next permissions maintenance run. Projects keep the
old portfolio name as text, so dashboards that group by the configured list stop counting them.
Always: (1) re-stamp projects to their new portfolio via bulk edit, (2) verify access for
affected users, (3) then delete.

---

## Section 2 — Project Lifecycle, Status & Governance Fields

**Purpose:** these fields determine where a project is in its lifecycle and how it progresses —
and several of them actively change system behaviour when set.

### Status

| | |
|---|---|
| **Field Type** | Dropdown (lookup, colour-coded) |
| **Description** | The project's current lifecycle stage |
| **Location** | Project Settings → Project Administration; values from Metadata Management → Project Status |
| **Functional Impact** | **Very high.** An inactive status (e.g. Closed, Cancelled) deactivates the project — removing it from pickers, search, timesheets and resourcing. Status changes fire notifications, can require portfolio-approver sign-off (when the status approval workflow is on), and scope dashboards, filters, governance models and timesheet restrictions |
| **Dependencies** | Default status applied at creation; "Archived" additionally requires the archive feature and a Project Administrator, and detaches sub-projects |
| **Example** | Proposed → Approved → Active → On Hold → Complete → Cancelled |
| **Cleanup Considerations** | Statuses can be deactivated but not renamed; deactivating a status immediately deactivates every project sitting on it (a background job updates them all) — check the project count first. Deleting a status leaves projects orphaned on a value that no longer syncs |
| **Best Practice** | Keep a lean lifecycle (6–8 statuses). Before deactivating a status, filter the portfolio by it and move projects off it. Document which statuses are "inactive" and what that means for timesheets |

### Methodology

| | |
|---|---|
| **Field Type** | Dropdown (lookup) |
| **Description** | The delivery lifecycle applied to the project (its set of phases and gates) |
| **Location** | Project Settings → Project Administration; values from Project Settings → Methodologies, Phases and Stage Gates |
| **Functional Impact** | Changing it **rebuilds the project's phases**: existing phase records are removed and re-created from the new methodology (dates carry over only where phase names match), and stage gates are re-applied. It also filters which Capitalisation Profiles can be selected |
| **Dependencies** | Phases, stage gates and capitalisation profiles all belong to a methodology; a project template can force the methodology at creation |
| **Example** | "Waterfall" with phases Design → Build → Test → Deploy; "Agile" with a single Delivery phase |
| **Cleanup Considerations** | Deleting a methodology removes its phases, phase tasks and gate links but does **not** touch projects — they keep pointing at a lifecycle that no longer exists (the noisiest failure mode in this area). Renaming a methodology also breaks capitalisation-profile matching |
| **Best Practice** | Never delete a methodology that live projects use — migrate projects first. Standardise phase names across methodologies where phases mean the same thing, so methodology changes carry dates over |

### Start Date

| | |
|---|---|
| **Field Type** | Date (required) |
| **Description** | The project's planned/actual start |
| **Location** | Project Settings → Dates & Phases; also at creation |
| **Functional Impact** | Anchors the schedule/Gantt, % complete, baselines and phase date calculations. A significant move can trigger a date-change approval workflow |
| **Dependencies** | Must be before End Date; phase dates must fall on/after it. Can be locked to Project Administrators (feature) |
| **Example** | 01 Mar 2026 |
| **Cleanup Considerations** | Moving dates on in-flight projects may require approval (if the workflow feature is on) and shifts phase-derived calculations |
| **Best Practice** | Baseline before changing; use the approval workflow if date discipline matters to your PMO |

### End Date

| | |
|---|---|
| **Field Type** | Date |
| **Description** | The project's planned finish |
| **Location** | Project Settings → Dates & Phases |
| **Functional Impact** | Same consumers as Start Date; drives overdue/at-risk indicators |
| **Dependencies** | Must be on/after Start Date; same locking and approval behaviour |
| **Example** | 20 Dec 2026 |
| **Cleanup Considerations** | As Start Date |
| **Best Practice** | As Start Date |

### Implementation Date

| | |
|---|---|
| **Field Type** | Date (month or full date) |
| **Description** | The go-live / in-service date |
| **Location** | Project Settings → Dates & Phases |
| **Functional Impact** | Financial: it is the default trigger for when capitalised costs start amortising; material changes can trigger the date-change approval workflow |
| **Dependencies** | Entry granularity (month vs exact date) depends on a tenant setting |
| **Example** | Jul 2026 |
| **Cleanup Considerations** | Moving it changes when amortisation begins — involve Finance |
| **Best Practice** | Align with Finance's definition of "in service"; don't use it as a delivery milestone field |

### Project Phases (per-phase dates)

| | |
|---|---|
| **Field Type** | Date pairs per phase |
| **Description** | Start/end of each lifecycle phase |
| **Location** | Project Settings → Dates & Phases (visible when the methodology has phases) |
| **Functional Impact** | Drive capitalisation eligibility (which costs can be capitalised depends on the phase), the calculated Current Phase, stage-gate evaluation; phase moves can trigger approval workflow |
| **Dependencies** | In the default month-based mode phase starts are derived automatically (each phase starts after the previous ends); a date-based mode allows free entry. Phases must not overlap and must start on/after the project start |
| **Example** | Design: Mar–Apr; Build: May–Aug; Test: Sep–Oct; Deploy: Nov |
| **Cleanup Considerations** | Phase date changes ripple into capitalisation calculations — coordinate with Finance on capitalising projects |
| **Best Practice** | Keep phase dates current — they are financial data, not just schedule decoration |

### Current Phase

| | |
|---|---|
| **Field Type** | Calculated (admin override available) |
| **Description** | The phase the project is currently in |
| **Location** | Displayed on the project; calculated by the stage-gate engine |
| **Functional Impact** | Phase analytics, filters, gate dashboards; changes are broadcast live to open dashboards |
| **Dependencies** | Derived from phase dates and gate completion; administrators can manually override, but the engine may recalculate it later |
| **Example** | "Build" |
| **Cleanup Considerations** | Manual overrides are temporary by design — fix the underlying dates/gates instead |
| **Best Practice** | Treat a wrong Current Phase as a data-quality signal, not a field to hand-edit |

### Reporting Program

| | |
|---|---|
| **Field Type** | Lookup (program picker) |
| **Description** | Associates the project with a program for reporting purposes without moving it in the delivery hierarchy |
| **Location** | Project Settings → Programs (feature-dependent) |
| **Functional Impact** | Program roll-up reporting; refreshes the reporting hierarchy on save |
| **Dependencies** | Target must be a Program; unavailable on programs themselves and on confidential projects |
| **Example** | A shared-infrastructure project reports under the "Cloud Migration" programme while being delivered elsewhere |
| **Cleanup Considerations** | Removing it silently drops the project from that programme's reporting |
| **Best Practice** | Use only when delivery and reporting hierarchies genuinely differ; document why |

### Primary Program

| | |
|---|---|
| **Field Type** | Read-only (derived) |
| **Description** | The program the project belongs to via the project hierarchy |
| **Location** | Displayed in Project Settings → Programs |
| **Functional Impact** | Roll-ups, health summaries, promoted items |
| **Dependencies** | Set by managing sub-projects, not editable here |
| **Example** | "Digital Workplace Programme" |
| **Cleanup Considerations** | Managed through the hierarchy — see the Confidential note in [Section 1](#confidential) (confidential projects are detached) |
| **Best Practice** | Keep hierarchy authoritative; use Reporting Program for exceptions |

### Detailed note — Stage Gates and Stage Gate Packages

Stage gates are checkpoints attached to methodology phases, configured under Project Settings →
Methodologies, Phases and Stage Gates. Each gate is configurable with: name and description,
active flag, whether it blocks phase progression, gate type and mode, an approver (a named
person, a community role such as the portfolio approver, or a routing to a named approval board),
a decision SLA in days, conditional/completion expressions (dynamic logic deciding when the gate
applies or auto-completes), a restart policy, and promotion to parent programmes.

**Stage Gate Packages** bundle gates into a reusable, ordered set that can be attached to phases,
optionally allowing multiple instances per phase (with min/max counts) — the standard way for a
PMO to implement a consistent gating model.

Cleanup considerations:

- Deleting a phase removes its gate links from projects, but deliberately **preserves gates that
  are already closed or have an approval in flight** — history is protected.
- Deleting a gate definition leaves already-created gate instances on projects untouched.
- Gate expressions reference custom properties and project fields **by name** — renaming those
  fields breaks the expressions silently (see [Section 6](#section-6--custom-properties) and the
  Project Workflow Inspector note in
  [Section 9.4](#94-the-project-workflow-inspector--your-impact-analysis-tool)).

### Detailed note — the Status approval workflow (how four settings combine)

If your PMO wants status changes reviewed before they take effect, four pieces of configuration
work together:

1. **Setup Project Features → Lock Project Admin Fields** — PMs can no longer set Status directly.
2. **Setup Project Features → Status Report Driven Project Status Change Workflow** — status
   changes are proposed via the status report.
3. **Metadata Management → Status Report RAGs → Valid Project States** — links a report RAG to
   the project status it proposes.
4. **Portfolios → Approver** — the person who receives the approval request.

If you rename or remove any of the linked values (RAG names, statuses, portfolios) the chain
breaks silently. Re-test the workflow after any change to these lists.

---

## Section 3 — Project Community & Ownership

**Purpose:** the community fields define accountability — and they simultaneously grant security
permissions. Every person added here gains access to the project; that is the single most
important thing to understand before cleaning these fields up.

### Primary PM

| | |
|---|---|
| **Field Type** | User picker |
| **Description** | The person(s) responsible for managing and driving the project |
| **Location** | Project Settings → Project Stakeholders |
| **Functional Impact** | Grants **edit (Manage)** access. Drives "My Projects", reporting by PM, status-report compliance chasing; add/remove can send notifications (feature) |
| **Dependencies** | Can be limited to a single person (feature); existing multi-PM projects are grandfathered — you can remove but not add. A feature carve-out can let PMs hand over Primary PM even when other fields are locked |
| **Example** | Jordan Lee (Programme Manager) |
| **Cleanup Considerations** | Removing a PM removes their edit rights; where the person has resource forecasts, the role is **closed** rather than deleted so financial history is preserved |
| **Best Practice** | One accountable PM per project where possible; run a periodic "projects without an active PM" review |

### Owner

| | |
|---|---|
| **Field Type** | User picker (multi) |
| **Description** | The individual(s) accountable for the project's overall success |
| **Location** | Project Settings → Project Stakeholders |
| **Functional Impact** | Grants **read** access; reporting and accountability dashboards |
| **Dependencies** | None |
| **Example** | Head of Operations |
| **Cleanup Considerations** | Read access is removed with the person |
| **Best Practice** | Keep to genuine accountability — not a distribution list |

### Business Owner

| | |
|---|---|
| **Field Type** | User picker |
| **Description** | The person who owns the business problem or opportunity |
| **Location** | Project Settings → Project Stakeholders |
| **Functional Impact** | Grants **read** access; used in workflow approval routing options (e.g. board approvals can route to the Business Owner); editable by anyone with edit rights |
| **Dependencies** | Same single-person restriction option as Primary PM |
| **Example** | Head of Sales for a CRM programme |
| **Cleanup Considerations** | If board/workflow approval routing points at Business Owner, an empty field **breaks the routing** — check intake boards before clearing |
| **Best Practice** | Populate consistently if any workflow routes approvals to this role |

### Executive

| | |
|---|---|
| **Field Type** | Multi-select (restricted list) |
| **Description** | The executive sponsor(s) overseeing the project |
| **Location** | Project Settings → Project Stakeholders |
| **Functional Impact** | Grants **read** access; executive-level reporting and dashboards; available as an approval-routing target |
| **Dependencies** | Only users flagged as executives (via the Executive person property maintained by user administrators) can be selected; others are dropped on save |
| **Example** | Chief Revenue Officer |
| **Cleanup Considerations** | The pick-list is driven by the Executive flag on user records — clean that flag list first, then project assignments |
| **Best Practice** | Maintain the executive flag centrally; audit sponsorship annually |

### Editors

| | |
|---|---|
| **Field Type** | User picker (multi) |
| **Description** | Additional people who can maintain the project |
| **Location** | Project Settings → Project Stakeholders |
| **Functional Impact** | Grants **edit (Manage)** access — same rights as a PM |
| **Dependencies** | The label can be renamed but the underlying role is fixed |
| **Example** | PMO analysts supporting the PM |
| **Cleanup Considerations** | Removing someone removes their ability to edit — verify they shouldn't retain access via another route (portfolio admin, etc.) |
| **Best Practice** | Review quarterly; prefer portfolio-level admin for PMO staff rather than per-project Editors everywhere |

### Viewers

| | |
|---|---|
| **Field Type** | User picker (multi) |
| **Description** | People with read-only access to the project |
| **Location** | Project Settings → Project Stakeholders |
| **Functional Impact** | Grants **read** access only |
| **Dependencies** | In bulk edit, an *omitted* Viewers column leaves viewers untouched; an intentionally *empty* list removes everyone |
| **Example** | Steering-committee attendees |
| **Cleanup Considerations** | Bulk-edit behaviour above matters during cleanup — an empty column is not the same as no column |
| **Best Practice** | Use portfolio Viewers for broad visibility; per-project Viewers for exceptions |

### Team Members

| | |
|---|---|
| **Field Type** | Community list (workspace) |
| **Description** | Delivery team members added via the project Community section |
| **Location** | Project Workspace → Community |
| **Functional Impact** | Grants workspace access without a resource allocation |
| **Dependencies** | Removal is blocked while the person has forecasts or submitted timesheets |
| **Example** | Developers and analysts on the delivery team |
| **Cleanup Considerations** | Members with time/forecast history cannot simply be removed — close their involvement instead |
| **Best Practice** | Keep Community aligned with the actual team; it feeds meeting invites and collaboration |

### Detailed note — community cleanup and financial history

When a person in a community role also has resource forecasts against the project, removing them
does **not** delete history: the role is *closed*, and only future forecast plans (after the
financial lock date) are removed. This protects actuals and past forecasts.

Practical implication for cleanup: don't try to "tidy" community lists by deletion expecting
history to disappear — and don't fear breaking financial history by removing leavers; it is
preserved by design.

---

## Section 4 — Financial Configuration

**Purpose:** these fields control budgeting, forecasting, capitalisation and currency behaviour.
Most project-level financial fields are visible and editable only by Financial Administrators.

### 4.1 Project-level financial fields

#### Cost Centre

| | |
|---|---|
| **Field Type** | Lookup (searchable) |
| **Description** | The cost centre accountable for the project's spend |
| **Location** | Project Settings → Key Details; values from Metadata Management → Cost Centers – Project |
| **Functional Impact** | Financial accountability reporting; available to reporting expressions; matched **by code** in board-to-project sync |
| **Dependencies** | Values carry a code and a name; retire with the Active flag |
| **Example** | "TEC-100 Technology" |
| **Cleanup Considerations** | Cost centre names can't be edited after creation — deactivate and create anew; projects keep the old code as text |
| **Best Practice** | Mirror the finance system's cost centre codes exactly; sync the list when Finance restructures |

#### Funding Source

| | |
|---|---|
| **Field Type** | Dropdown (lookup) |
| **Description** | The funding bucket financing the project |
| **Location** | Project Settings → Project Administration; values from Project Types page → Funding Source tab |
| **Functional Impact** | Financial dashboards (spend by funding bucket), portfolio investment reporting, filters |
| **Dependencies** | **No Active flag exists** — the only way to retire a value is deletion |
| **Example** | "Capital Budget", "Opex", "Innovation Fund" |
| **Cleanup Considerations** | Deleting leaves the old text on projects (historical extracts still show it) while removing it from pickers and filters — re-stamp projects first |
| **Best Practice** | Keep the list aligned with Finance's funding structure; review at budget-cycle boundaries |

#### Is Eligible to Capitalize Costs

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Whether the project may capitalise costs |
| **Location** | Project Settings → Financial Management (Financial Administrators; capitalisation feature) |
| **Functional Impact** | Gates the entire capitalisation calculation for the project; switching it off removes capitalised P&L entries from the lock date forward |
| **Dependencies** | Becomes read-only once amortisation has started |
| **Example** | Yes for a software build; No for a process-improvement project |
| **Cleanup Considerations** | Turning it off on a live project actively rewrites capitalised entries — a Finance decision, not an admin tidy-up |
| **Best Practice** | Set at approval time with Finance sign-off; avoid mid-flight changes |

#### Capitalization Profile

| | |
|---|---|
| **Field Type** | Dropdown (lookup) |
| **Description** | The capitalisation schedule applied (what % capitalises in which phase/role) |
| **Location** | Project Settings → Financial Management; profiles maintained per methodology |
| **Functional Impact** | Drives forecast/actual capitalisation percentages by phase and role |
| **Dependencies** | The available profiles are filtered by the project's Methodology; profiles match methodology and phase **by name** |
| **Example** | "Standard SDLC Capitalisation" |
| **Cleanup Considerations** | Renaming methodologies or phases breaks profile matching; verify profiles after any lifecycle rename |
| **Best Practice** | One profile per methodology unless Finance genuinely differentiates |

#### Amortization Period (months)

| | |
|---|---|
| **Field Type** | Number |
| **Description** | How many months capitalised costs amortise over |
| **Location** | Project Settings → Financial Management |
| **Functional Impact** | Amortisation calculations and financial reporting |
| **Dependencies** | Amortisation typically starts at the Implementation Date |
| **Example** | 60 |
| **Cleanup Considerations** | Changing after amortisation starts affects P&L projections — Finance owns this |
| **Best Practice** | Default from your accounting policy (e.g. 5 years for software) |

#### Generate Actuals from Forecast

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Automatically creates actuals from the project's forecast |
| **Location** | Project Settings → Financial Management (feature-dependent) |
| **Functional Impact** | Removes the need to import actuals — the forecast becomes the actual each period |
| **Dependencies** | Instance default is set by a feature setting at creation |
| **Example** | On for internal-labour-only projects |
| **Cleanup Considerations** | Switching mid-project changes where actuals come from — reconcile with Finance before toggling |
| **Best Practice** | Decide per operating model, not per project; document which project types use it |

#### Include Below-the-Line for Budget Variance

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Whether below-the-line costs count in budget variance and EAC |
| **Location** | Project Settings → Financial Management (feature-dependent) |
| **Functional Impact** | Changes budget variance and estimate-at-completion maths and the funding comparison reports |
| **Dependencies** | Below-the-line categories are flagged on Expense Categories ([Section 4.2](#42-financial-master-data)) |
| **Example** | Exclude contingency lines from variance |
| **Cleanup Considerations** | Toggling changes reported variance overnight — communicate before changing |
| **Best Practice** | Agree one convention portfolio-wide |

#### Show financials in (secondary currency)

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Displays this project's financials in the secondary currency |
| **Location** | Project Settings → Key Details |
| **Functional Impact** | Financial displays and extracts for that project switch currency presentation |
| **Dependencies** | Requires a secondary currency to be configured in Currency Management |
| **Example** | A UK subsidiary project shown in GBP on a USD instance |
| **Cleanup Considerations** | None significant — presentation only |
| **Best Practice** | Use for genuinely local-currency projects; keep conversion rates current |

#### Accept Overtime Hours

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Whether timesheets on this project can include overtime |
| **Location** | Project Settings → Financial Management (hidden if overtime is disabled instance-wide) |
| **Functional Impact** | Timesheet entry and overtime costing |
| **Dependencies** | Overtime label and rules are set in Timesheet settings and rate cards |
| **Example** | Yes for a go-live cutover project |
| **Cleanup Considerations** | None significant |
| **Best Practice** | Enable only where overtime is contractually chargeable |

#### Allow Time Booking to Child Projects

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Lets team members book time directly to child projects |
| **Location** | Project Settings → Financial Management (feature-dependent) |
| **Functional Impact** | Changes which projects appear on timesheets and whether child allocations are required |
| **Dependencies** | Requires timesheets and the sub-project booking feature |
| **Example** | A programme allowing booking to its workstreams |
| **Cleanup Considerations** | None significant |
| **Best Practice** | Decide per programme structure; consistent use makes utilisation reporting cleaner |

### 4.2 Financial master data

#### Expense Category

| | |
|---|---|
| **Field Type** | List entry (+ "Show in footer / Below the Line" flag) |
| **Description** | Top level of the financial chart of accounts used in forecasts and actuals |
| **Location** | Financial Administration → Expense Types (parallel sets exist for Revenue, Benefits and Ongoing Costs) |
| **Functional Impact** | Portfolio financial roll-ups report at category level; the Below-the-Line flag controls placement in the financials grid and variance treatment |
| **Dependencies** | **Category names cannot contain commas** (the save is rejected); deleting a category deletes all its expense types |
| **Example** | "Labour", "Software", "Hardware", "Contingency (BTL)" |
| **Cleanup Considerations** | Historic financial rows keep the old category text — totals survive, but rows no longer roll up under a renamed category |
| **Best Practice** | Mirror Finance's reporting lines; changes belong in a period-end window with Finance |

#### Expense Type

| | |
|---|---|
| **Field Type** | List entry with financial attributes |
| **Description** | Second level of the chart of accounts; carries Expense Class (e.g. Cash vs Resource), Capitalisation %, amortisation trigger and period, ordering, and a User Locked flag |
| **Location** | Financial Administration → Expense Types |
| **Functional Impact** | Rate cards must point at a **Resource-class** expense type; the capitalisation engine reads the type's settings; forecasts, actuals and extracts all classify by it |
| **Dependencies** | Belongs to a category; "User Locked" hides it from user pickers (the retire mechanism — there is no Active flag) |
| **Example** | "Contractor" (Resource class, 80% capitalisable) |
| **Cleanup Considerations** | Deleting leaves old text on financial rows; rate cards referencing it stop resolving |
| **Best Practice** | Use User Locked to retire; keep capitalisation settings reviewed annually with Finance |

#### Currency

| | |
|---|---|
| **Field Type** | List entry (code, name, symbol, flags, rates) |
| **Description** | A currency available in Fluid, with conversion rates to the default currency (current and restated), plus monthly rate overrides |
| **Location** | Financial Administration → Currency Management |
| **Functional Impact** | Every financial figure shown or extracted in converted form uses these rates; rate cards snapshot conversion rates when saved |
| **Dependencies** | One **Default** currency (the reporting base); optionally one **Secondary**; monthly rates override the header rate for that month |
| **Example** | USD (default), GBP (secondary) at 1.27 |
| **Cleanup Considerations** | Deleting a currency that has monthly rates fails silently — remove the rates first or just deactivate. Changing the default currency re-bases every conversion on the instance — never do this casually. Existing rate cards keep their snapshot rates |
| **Best Practice** | Maintain rates on a monthly cadence; deactivate rather than delete; treat a default-currency change as a formal restatement project |

#### Rate Card

| | |
|---|---|
| **Field Type** | Dated rate definition |
| **Description** | Cost rates for a classification of resource (hourly/daily/monthly, currency, capitalisation eligibility, overtime rules, capping, utilisation) valid between a start and end month |
| **Location** | Rate Card Management (Financial or User Administrators) |
| **Functional Impact** | Forecast costs from allocations, actual costs from timesheets, capitalisation split, over/under-allocation reporting, delivery-team default costing |
| **Dependencies** | Multiple cards may share a classification if date ranges don't overlap; each card references an Expense Category/Type; the card whose dates cover the entry is used |
| **Example** | "Senior Developer 2026: £800/day, capitalisable" |
| **Cleanup Considerations** | Deleting is **not usage-checked**: resources on a deleted card silently fall back to the card named "Default". Renaming a classification detaches every resource assigned to it. Already-generated actuals are not recalculated |
| **Best Practice** | Never rename or delete the "Default" card — it is the instance-wide fallback matched by name. Version rates by adding a new dated card rather than editing the old one |

#### Cost Code

| | |
|---|---|
| **Field Type** | List entry (code, label, external reference, Active) |
| **Description** | General-ledger cost codes for cost-code distribution reporting |
| **Location** | Metadata Management → Cost Codes |
| **Functional Impact** | Cost code distribution panels and financial extracts |
| **Dependencies** | Names not editable after creation; retire via Active |
| **Example** | "CAPEX-IT-001" |
| **Cleanup Considerations** | Distribution records keep old codes as text |
| **Best Practice** | Mirror the GL; deactivate rather than delete |

#### Line of Business

| | |
|---|---|
| **Field Type** | List entry (code, name, Active) |
| **Description** | Business lines for allocating project costs across the organisation |
| **Location** | Metadata Management → Line of Business |
| **Functional Impact** | Line-of-business allocation panels and reporting |
| **Dependencies** | Names not editable after creation |
| **Example** | "Retail Banking", "Wealth" |
| **Cleanup Considerations** | Allocation records keep old values |
| **Best Practice** | Align with management-accounting structure |

---

## Section 5 — Metadata Management (Master Data)

**Purpose:** metadata management maintains the lookup lists behind the dropdowns documented in
Sections 1–4. This section covers the lists themselves — what an administrator can set on each
entry and what happens when entries change.

Unless noted, lists are maintained under Administration Console → Data Administration →
Metadata Management, by Data Administrators.

> **A rule that surprises everyone:** on the Metadata Management page, an entry's display name
> **cannot be edited after creation** — lists there are add / deactivate / delete only. If a value
> is misspelled, create the correct one, migrate projects (bulk edit), then deactivate the old
> one.
>
> (Portfolios, Project Types, Categories, Funding Sources, Methodologies, Phases, Rate Cards and
> Currencies use different admin screens and *can* be renamed — with the "renames don't
> propagate" caveat from the introduction.)

### 5.1 Portfolios & SubPortfolios (admin definition)

Configured at Project Settings → Portfolios and SubPortfolios (Project Administrators).

| Attribute | Type | What it does |
|---|---|---|
| Portfolio Name | Text (unique) | The value offered on projects; renameable — but renames do not update existing projects |
| Administrators | User list | Full administrative control of every project in the portfolio |
| Viewers | User list | Read access to every project in the portfolio |
| Approver | User | Receives status-change approval requests for the portfolio's projects |
| SubPortfolios | Child list | Each has a name and belongs to exactly one portfolio |

**Impact:** security, approvals, reporting, dashboards, resource and financial roll-ups (see the
[Section 1 detailed note](#detailed-note--portfolio-is-a-security-container-not-just-a-grouping)).

**Cleanup:** deleting a portfolio cascades to its sub-portfolios; access held through it is
removed by the next permissions run; bulk upload is replace-by-omission. Migrate projects first,
then delete.

**Best practice:** one owner (the PMO) for the portfolio list; change it through a controlled
process, never ad hoc.

### 5.2 Project Types (admin definition)

Configured at Project Settings → Project Types (see the
[Section 1 detailed note](#detailed-note--project-type-the-biggest-blast-radius-in-fluid) for
downstream impact).

| Attribute | Type | What it does |
|---|---|---|
| Project Type Name | Text (unique, max 120) | The classification value; cannot duplicate the Program label |
| Set As Default | Boolean | Pre-selected for new projects (single default) |
| Color | Colour | Chart and card colouring |
| Workspace Components Visibility | Per-component setting | *Show to all* / *Show for admins* / *Hide for all* — for each of the workspace sections available on your instance (up to 17) |

**Cleanup:** you cannot delete the last type; the built-in "Program" type is protected and
reappears if removed. Deleting a type also deletes its Project Activities. Existing projects keep
the old type name.

### 5.3 Project Activities (timesheet booking categories)

Configured on the Project Types page → Project Sub Activities tab. Each activity has: a name
(unique within its project type), the project type it belongs to, an optional list of profile
roles allowed to book it, and a User Locked flag to hide it from selection.

**How the gating works:** if a project's type has **at least one** activity defined, timesheet
users must book against one of them (optionally restricted by their profile role). If the type
has **none**, the global Activity Types list (Metadata Management) applies instead.

**Impact:** timesheet validity, utilisation analysis, effort forecasting, capitalisation
alignment (activities often mirror capitalisable phases).

**Cleanup considerations:** historic time entries keep the old activity name forever — reporting
on history is safe. But adding the *first* activity to a hitherto-empty project type silently
switches every project of that type from the global list to the restricted list, and
copied-forward timesheets drop activities that are no longer valid.

**Best practice:** keep activities to the level Finance and resourcing actually analyse (5–8 per
type); align names with capitalisable phases; never delete an activity mid-timesheet-period —
retire with User Locked.

### 5.4 Tiers & Business Drivers, Funding Sources, Project Categories

Covered field-by-field in [Section 1](#section-1--project-classification--portfolio-structure);
admin specifics worth repeating for cleanup:

- **Tiers / Business Drivers:** add/deactivate only (no rename). Delete a tier only after
  unlinking all of its business drivers — linked drivers can otherwise be stranded invisibly.
- **Funding Sources:** no Active flag — deletion is the only retirement, so plan a re-stamping
  exercise first.
- **Project Categories:** renameable, but intake boards that "apply to" a category reference it
  by name and silently unbind on rename.

### 5.5 Impact (RAID) configuration

Three related surfaces configure risks, issues and other impacts:

**Enabled Impact Types** (Project Settings → Project Labels & Field Names → Impact Types). Tick
which impact types the organisation uses: Relationship, Risk, Change, Assumption, Dependency,
Decision, Issue, Lessons Learned, Variation, Schedule. **Risks and Issues are mandatory and
cannot be disabled.** Disabling a type stops new items; existing items keep it.

**Impact Sub Types** (Metadata Management). A flat list categorising impacts (e.g. "Vendor Risk",
"Data Privacy"). Add/deactivate only. Historic impacts keep old sub-type names.

> *Business example:* sub-type "Vendor Risk" lets the PMO report supplier dependency trends and
> concentration of supplier risk across the portfolio.

**Impact / Probability / Risk Rating scales** (Project Settings → Impact, Probability and Risk
Rating). For each scale: a description, weighted options (weight + label, e.g. 1-Low … 5-Critical),
a default value, the applicable impact types, and — for Risk Rating — the calculation function
(multiply, average or sum of Impact × Probability) and the rating bands (score range → label).

**Impact of changes:** ratings are stamped on each impact when it is saved. Re-weighting or
re-banding changes **future** calculations only — existing impacts are not recalculated, so a
heat map can legitimately contain items rated under the old scale. If you change scales, note the
date and expect mixed vintages, or ask item owners to re-assess.

**Best practice:** match your corporate risk-appetite matrix (typically 5×5); change scales at
most annually.

### 5.6 Project Status list, Status Report RAGs, Status Component RAGs

**Project Status** (Metadata Management → Project Status). Each status has: name (create-only),
colour, display order, Active flag, Is Default flag. See
[Section 2](#section-2--project-lifecycle-status--governance-fields) for downstream impact. The
critical admin behaviour: toggling **Active** updates the active/inactive state of *every project
currently on that status* via a background job — the UI warns you, take the warning seriously.

**Status Report RAGs** (Metadata Management → Status Report RAGs). The overall report statuses
(e.g. Red / Amber / Green plus custom ones). Each has: name, description, weight/order, colour,
Active, Is Default, and **Valid Project States** (the link used by the status approval workflow —
[Section 2](#detailed-note--the-status-approval-workflow-how-four-settings-combine)). Rules: the
four system RAGs (None, Red, Amber, Green) and the default RAG cannot be deleted; a RAG ordered
above Green automatically prompts a "Path to Green" plan.

**Status Component RAGs** (Metadata Management → Status Component RAGs). The component dimensions
on a status report — e.g. Timeline, Scope, Financials, Resourcing. Which components are *primary*
(drive the auto-calculated overall RAG and roll up to parent projects) is set on the Project
Labels & Field Names page ("Primary Status Component RAGs"). Old reports keep deleted component
names, so history still renders.

**Best practice:** treat RAG definitions as portfolio-wide standards; publish the meaning of each
RAG and each component so reports are comparable. Avoid renaming RAGs — governance assessments
and the status approval workflow reference them **by name**
(Sections [2](#section-2--project-lifecycle-status--governance-fields) and
[11](#section-11--governance-assessments)).

### 5.7 Global admin lists (reference)

Metadata Management also maintains flat lists used on resources, documents and meetings — same
rules (name create-only, Active to retire, bulk upload replaces the list):

Activity Types (global timesheet fallback), Benefits Types, Countries, Regions, Document Status,
Document Types, Engagement Types, Profile Roles, Profile Status, Project Roles, Relationship
Types, Schedule Sub Types, Skills, Task Types, Meeting Types and Themes.

---

## Section 6 — Custom Properties

**Purpose:** custom properties extend Fluid's standard data model with your organisation's own
fields. Unlike standard fields, they can flow through almost every area of Fluid — which makes
them both the most powerful configuration tool and the one that most needs governance during a
cleanup.

**Where configured:** Administration Console → Data Administration → Custom Properties
(Application Administrators). Choose the entity first — custom properties can be added to
Projects, Impacts (RAID), Schedule Tasks, Status Reports, Resource Plans, Financials, Revenue,
Benefits, Ongoing Costs, People (users), Actions, Boards (per-board card fields), Meetings,
WorkHubs and Documents — plus any Catalog you have created.

### 6.1 Where custom properties are used across Fluid

| Area | How custom properties are used |
|---|---|
| Projects | Additional project metadata ("Data Fields" panel in the workspace) |
| Dashboards & list views | Report filters, grouping, columns (Reportable properties only) |
| Excel reporting | Columns in exports (Reportable properties only; bulk edit includes all properties) |
| Boards & intake | Card fields; card values sync to project fields when a pipeline creates/updates a project |
| Approval processes | Routing and governance logic via expressions referencing property values |
| Stage gates | "Required data fields" governance checks; property values copied to approval cards |
| Governance assessments | Criteria that test whether properties are set |
| Resource management | Skills and person attributes (People properties) |
| Financials / Benefits / Risks | Additional dimensions on those records |
| Dynamic logic | Calculated values, conditional visibility, filtered option lists |

### 6.2 Settings on a custom property definition

#### Name

| | |
|---|---|
| **Field Type** | Text (letters, numbers and spaces only, max 100) |
| **Description** | The property's unique system identifier |
| **Location** | Edit Property → Property Details |
| **Functional Impact** | Used by filters, saved views, expressions, exports and integrations to identify the property |
| **Dependencies** | Unique per entity; **cannot be changed after creation** |
| **Example** | `GovernanceLevel` |
| **Cleanup Considerations** | Because everything keys on the name, it is deliberately immutable — plan names before creating |
| **Best Practice** | Short, PascalCase or plain words, no abbreviations only one team understands |

#### Label

| | |
|---|---|
| **Field Type** | Text (max 150) |
| **Description** | Friendly display name shown to users instead of the Name |
| **Location** | Property Details |
| **Functional Impact** | Shown on forms and reports; **also used to match card properties to project fields in pipeline sync**, and usable as a token in expressions |
| **Dependencies** | Optional |
| **Example** | "Governance Level" |
| **Cleanup Considerations** | Renaming a label can silently break pipeline field mapping and expressions that reference the label — check intake boards and expressions first |
| **Best Practice** | If the Name is user-friendly, skip the label; one property = one label everywhere |

#### Description

| | |
|---|---|
| **Field Type** | Text (max 500) |
| **Description** | Help text explaining what the property is for |
| **Location** | Property Details |
| **Functional Impact** | Shown to users as guidance; no downstream impact |
| **Dependencies** | None |
| **Example** | "Set by the PMO at approval; drives governance tier." |
| **Cleanup Considerations** | None |
| **Best Practice** | Always fill it in — it is your data dictionary |

#### Category

| | |
|---|---|
| **Field Type** | Dropdown/creatable (max 100) |
| **Description** | Groups related properties under one heading on the record |
| **Location** | Property Details |
| **Functional Impact** | Grouped display; **also defines the aggregation scope for Scored Option (Calc) properties** — the calculation sums/averages the scored options in the same category |
| **Dependencies** | Optional |
| **Example** | "Governance", "Compliance" |
| **Cleanup Considerations** | Renaming a category changes which scored options feed any calculated score in it — re-verify calculated properties after regrouping |
| **Best Practice** | Group deliberately; keep calculation categories dedicated (only the inputs plus the calc) |

#### Data Type

| | |
|---|---|
| **Field Type** | Dropdown |
| **Description** | Determines how values are captured, stored and displayed (full list in [6.3](#63-data-types-available)) |
| **Location** | Property Details |
| **Functional Impact** | Controls rendering, validation, filterability, export format |
| **Dependencies** | Restricted after creation — only closely-related conversions are allowed (the text family: Text ↔ Text Area ↔ Rich Text ↔ Hyperlink ↔ Document; and Person ↔ Person Multiselect). **Option ↔ Multi-select Option is not permitted** |
| **Example** | Option list for "Governance Level" |
| **Cleanup Considerations** | A wrong type usually means create-new-and-migrate, not convert — decide types carefully up front |
| **Best Practice** | Prefer Option lists over free text wherever values should be comparable across projects |

#### Options / Valued Options

| | |
|---|---|
| **Field Type** | List |
| **Description** | The selectable values (Option types); scored options carry a numeric weight each |
| **Location** | Property Value |
| **Functional Impact** | Filters and dashboards offer exactly this list; pipeline sync only copies values that exist in the target list |
| **Dependencies** | Bulk view available (one per line; `score:label` for scored) |
| **Example** | Low / Medium / High / Critical |
| **Cleanup Considerations** | Removing or renaming an option leaves old text on existing records: still displayed, but unmatchable by list-driven filters and rejected on the next edit. Update records first |
| **Best Practice** | Standardise values; avoid near-duplicates ("On hold" vs "On Hold"); reuse Shared Lists |

#### Shared List

| | |
|---|---|
| **Field Type** | Link |
| **Description** | Connects the property's options to a centrally managed list reused by many properties |
| **Location** | Property Value |
| **Functional Impact** | Update the list once — every linked property updates everywhere immediately |
| **Dependencies** | Available for option-based and cascading types; linking replaces the property's own list |
| **Example** | One "Business Unit" list used by five properties |
| **Cleanup Considerations** | Deleting a shared list unlinks every property and clears their option configuration. Edits propagate instantly to all linked properties — a quick edit is a portfolio-wide change |
| **Best Practice** | The single best consolidation tool: converge duplicate lists into shared lists during cleanup |

#### Default Value

| | |
|---|---|
| **Field Type** | Per type |
| **Description** | Value pre-populated on new records |
| **Location** | Property Value |
| **Functional Impact** | Reduces empty data; no other impact |
| **Dependencies** | Not available for calculated, table, cascading, document or multi-person/project types |
| **Example** | Default "Medium" |
| **Cleanup Considerations** | None significant |
| **Best Practice** | Default to the safest common value, not the most optimistic one |

#### Required

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Value must be present before the record can be saved |
| **Location** | Property Settings |
| **Functional Impact** | Blocks saves of incomplete records; feeds the "required data fields" governance check |
| **Dependencies** | Can be narrowed with *Required for statuses* |
| **Example** | Required once a project is "Approved" |
| **Cleanup Considerations** | Turning Required on retroactively blocks edits of records that lack a value — combine with status scoping or run a data-fill first |
| **Best Practice** | Require as little as possible, as late as possible (use status-based requirement) |

#### Applicable for statuses

| | |
|---|---|
| **Field Type** | Multi-select |
| **Description** | Shows the property only when the record is in the selected statuses (project statuses, or board columns for card properties) |
| **Location** | Property Settings |
| **Functional Impact** | Dynamic forms that grow as work progresses; hidden properties are also not written |
| **Dependencies** | Empty = all statuses. Status names are stored as text — renaming a status/column breaks the binding |
| **Example** | Benefits fields appear from "Business Case" onward |
| **Cleanup Considerations** | Review bindings after renaming board columns or statuses — a broken binding silently hides (or always shows) the property |
| **Best Practice** | Design intake forms in status layers; audit bindings whenever board columns change |

#### Required for statuses

| | |
|---|---|
| **Field Type** | Multi-select |
| **Description** | Makes the property mandatory only in the selected statuses |
| **Location** | Property Settings |
| **Functional Impact** | Progressive data quality gates |
| **Dependencies** | Only relevant while *Required* is on; applicability wins over requirement |
| **Example** | Mandatory at "Approval" column |
| **Cleanup Considerations** | Same rename fragility as above |
| **Best Practice** | Pair with stage gates for governance checkpoints |

#### Reportable

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Includes the property in reports, Excel exports, list views, filters and dashboards |
| **Location** | Property Settings |
| **Functional Impact** | The master switch for analytics visibility |
| **Dependencies** | Off ≠ deleted: data is intact, just invisible to reporting |
| **Example** | On for "Governance Level" |
| **Cleanup Considerations** | Turning it off removes the column from every export and filter overnight — check report consumers first |
| **Best Practice** | Make analytical properties Reportable; keep operational scratch fields off to reduce report noise |

#### Visibility mode

| | |
|---|---|
| **Field Type** | Dropdown (4 options) |
| **Description** | Who can see/edit: *Editable by all* · *Hidden from non-admin users* · *Read-only for non-admin users* · *Read-only for all users* |
| **Location** | Property Settings |
| **Functional Impact** | Access control per property. "Admin" depends on the entity: Project Administrators for project-family records, User Administrators for people, Application Administrators for boards/actions/meetings |
| **Dependencies** | *Read-only for all users* properties are excluded from pipeline sync |
| **Example** | A compliance flag editable only by the PMO |
| **Cleanup Considerations** | Hidden properties silently ignore non-admin edits (including via bulk edit and API) — worth knowing when a "field won't save" |
| **Best Practice** | Use for compliance flags, financial controls, and any field the PMO must own |

#### Lookup filter (Person types)

| | |
|---|---|
| **Field Type** | Field + value/expression |
| **Description** | Restricts the person search to users matching a person attribute |
| **Location** | Property Settings |
| **Functional Impact** | Ensures pickers only offer valid people |
| **Dependencies** | The value can be a fixed text or an expression using other properties on the same form |
| **Example** | "Approver" limited to Department = "Finance" |
| **Cleanup Considerations** | Depends on the person attribute staying populated |
| **Best Practice** | Prefer this over training users which names to pick |

#### Applicable types

| | |
|---|---|
| **Field Type** | Multi-select |
| **Description** | Restricts the property to certain sub-types of the entity: impact types (RAID), card types (boards), engagement types (people), qualitative/quantitative (benefits) |
| **Location** | Property Settings |
| **Functional Impact** | The property only appears/applies for those sub-types |
| **Dependencies** | Empty = all |
| **Example** | A "Vendor" property only on Risk-type impacts |
| **Cleanup Considerations** | Deleting a sub-type strands the binding |
| **Best Practice** | Scope tightly — fewer irrelevant fields per form |

#### Expression

| | |
|---|---|
| **Field Type** | Dynamic-logic expression |
| **Description** | Auto-calculates the property's value (making it read-only), or — with an `OPTIONS(...)` expression — dynamically filters which options are selectable |
| **Location** | Property Settings (feature-dependent) |
| **Functional Impact** | Calculated fields, derived scores, context-sensitive option lists |
| **Dependencies** | Supported for Text, Number, Option, Yes/No (and dates server-side); references other properties by name/label |
| **Example** | Risk score = `[Impact] * [Probability]`; options for "Sub-team" filtered by "Team" |
| **Cleanup Considerations** | Renaming any referenced property breaks the expression **silently** (it evaluates as empty) — inventory expressions before renames |
| **Best Practice** | Keep expressions simple; document each one; test after any related rename |

#### Conditional Property (Property Dependency)

| | |
|---|---|
| **Field Type** | Parent property + values |
| **Description** | Shows this property only when another property has one of the selected answers |
| **Location** | Conditional Property panel |
| **Functional Impact** | Dynamic, skip-logic forms |
| **Dependencies** | Parent must be an Option / Scored Option / Yes-No property in the same entity, not hidden; **one level only** (no chains); a property that others depend on cannot itself be conditional |
| **Example** | "Vendor Name" appears when "Uses External Vendor" = Yes |
| **Cleanup Considerations** | Deleting the parent property clears the dependency (the child becomes always-visible) |
| **Best Practice** | Use to keep forms short; avoid deep webs of dependencies — one level is all you get, design accordingly |

### 6.3 Data types available

| Data type | Use for | Notes for cleanup |
|---|---|---|
| Text / Text Area / Rich Text | Free-form entries | Free text can't be standardised — a prime consolidation target (convert to Option lists where values repeat) |
| Number / Percentage | Numeric values | Stored numerically — changing type away from Number strands the numeric value |
| Date | Calendar dates | As Number — date values live in a dedicated slot |
| Yes/No | True/false toggles | The best parent for conditional properties |
| Option List / Multiselect Option | One / several from a defined list | The workhorse types; pair with Shared Lists |
| Cascading Option | Dependent multi-level lists (Region → Country → City) | Levels and keys are **positional** — reordering levels after launch invalidates saved values; add/remove options carefully (removing a parent removes its whole branch) |
| Scored Option / Scored Option (Calc) | Weighted options and auto-calculated scores | Calc aggregates scored options in the same Category (sum / average / multiply / lowest / highest); changing option weights silently re-bands future calculations |
| Person / Person Multiselect | User references | Supports the lookup filter |
| Project / Project Multiselect | Links to other projects | Useful for dependency mapping |
| Hyperlink | URL + display text | — |
| Table | A structured mini-table (own columns, per-column types, required/read-only flags, row/column totals, default rows) | Powerful but heavy — prefer separate properties unless genuinely tabular |
| Document | A file attachment of a required document type | Document types come from Metadata Management |
| Catalog types | Pickers against your catalogs (Applications, Vendors…) | Appear automatically once catalogs exist ([Section 10](#section-10--catalogs)) |

### 6.4 Cleanup considerations specific to custom properties

**Deleting a property does not delete its data.** The stored values remain in the database
(invisible in the UI). Two consequences matter: (1) audit history is preserved; (2) creating a
new property later **with the same Name silently re-adopts the orphaned old values** — which can
resurrect stale data on hundreds of records. During cleanup, keep a register of deleted property
names and avoid reusing them (or deliberately reuse them if re-adoption is what you want).

**What deletion does not clean up:** expressions that referenced the property, saved filters and
bookmarked dashboard URLs keyed on it, governance criteria that test it by name, report templates
using its column, and pipeline mappings. Sweep these manually — the *Project Workflow Inspector*
([Section 9.4](#94-the-project-workflow-inspector--your-impact-analysis-tool)) exports a
dependency graph that shows expression references, shared-list usage and board-to-property
mappings, and is the fastest way to find them.

**The board "Copy from" tools are bulk operations.** Copying properties between boards in
*replace* mode deletes every property on the target first — same orphaning behaviour at scale.
Use *merge* unless you truly mean replace.

**Consolidating duplicates (the most common cleanup task).** If several properties capture the
same data (e.g. three variants of "Business Unit"): pick the survivor, convert its list to a
Shared List, bulk-migrate values into it (Data Administration bulk edit), point any
expressions/filters at the survivor, then delete the duplicates. Reporting only aggregates
cleanly when one property holds the data.

### 6.5 Example — one property, many uses

**Custom Property: "Governance Level"** (Option List: Low / Medium / High / Critical; Reportable;
Required from status "Approved"; visibility Read-only for non-admin users)

- Executive dashboards group and filter the portfolio by it
- An intake board routes approvals to different approvers when the level is High or Critical
  (expression-based routing)
- A governance assessment criterion checks it is set, and recommends a Red status when missing
- Stage gates require it before the "Initiate" gate can close
- The PMO owns the value (read-only for everyone else)

A single custom property becomes a reporting, governance and workflow tool — which is exactly why
renaming or deleting one deserves impact analysis.

---

## Section 7 — Resource & Organisation Configuration

**Purpose:** defines the organisational structure resources belong to, and the ownership of
resource capacity. Configured at User Management → Division, Department and Team (labels
renameable).

### Division

| | |
|---|---|
| **Field Type** | List entry (name, Active, owners/viewers) |
| **Description** | Top level of the resource hierarchy |
| **Location** | Division, Department and Team page |
| **Functional Impact** | Resource dashboards, capacity reporting, org-level filters |
| **Dependencies** | Parent of Departments |
| **Example** | "Technology" |
| **Cleanup Considerations** | Renames **propagate automatically** to active resources and resource plans (the well-behaved exception); inactive resources keep the old name |
| **Best Practice** | Mirror the HR org structure; rename rather than delete-recreate |

### Department

| | |
|---|---|
| **Field Type** | List entry |
| **Description** | Second level, belongs to a Division |
| **Location** | Same page |
| **Functional Impact** | Resource reporting and filters |
| **Dependencies** | Child of Division |
| **Example** | "Architecture" |
| **Cleanup Considerations** | Same rename propagation |
| **Best Practice** | Keep in sync with HR feeds |

### Team

| | |
|---|---|
| **Field Type** | List entry (name, division/department, owners, facilitators, viewers, default rate card, request-based flag, Active) |
| **Description** | Delivery team with its own workspace and capacity |
| **Location** | Same page |
| **Functional Impact** | Capacity planning, team dashboards, team placeholders, allocation requests; the default rate card prices team-level (unnamed) allocations |
| **Dependencies** | Belongs to a department; team reference auto-generated |
| **Example** | "Enterprise Architecture" team, default rate card "Architect 2026" |
| **Cleanup Considerations** | Deletion is guarded: **blocked entirely** while current/future resource plans exist; **deactivate-only** when historical plans exist; deletable only if never used. Deactivating also retires the team's placeholder |
| **Best Practice** | The safest area to tidy — the system enforces the right order. Assign owners (full team admin) vs facilitators (day-to-day allocations) deliberately |

### Team Owner / Facilitators / Viewers

| | |
|---|---|
| **Field Type** | User lists |
| **Description** | Who manages the team workspace, manages allocations day-to-day, and who can view |
| **Location** | Team entry |
| **Functional Impact** | Team governance and allocation approval |
| **Dependencies** | None |
| **Example** | Resource manager as owner |
| **Cleanup Considerations** | Access is removed with the person |
| **Best Practice** | Review alongside line-management changes |

### Default Rate Card

| | |
|---|---|
| **Field Type** | Lookup |
| **Description** | The rate card used when the team (rather than a person) is allocated |
| **Location** | Team entry |
| **Functional Impact** | Generates forecast cost estimates for unnamed demand |
| **Dependencies** | References a rate card classification **by name** |
| **Example** | "Architect 2026" |
| **Cleanup Considerations** | If the referenced card is deleted, team costing falls back to the instance "Default" card silently |
| **Best Practice** | Re-point before retiring rate cards |

### Request-based allocation

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Whether allocations to this team must go through requests |
| **Location** | Team entry |
| **Functional Impact** | Changes the resourcing workflow for the team |
| **Dependencies** | None |
| **Example** | On for shared-services teams |
| **Cleanup Considerations** | None significant |
| **Best Practice** | Use for contended, centrally-managed teams |

---

## Section 8 — Timesheet Configuration

**Purpose:** instance-wide (per-division) controls for time capture and compliance. Configured at
Timesheet → Settings (Timesheet Administrators). These are settings, not per-project fields — but
they change what every timesheet user experiences.

### Timesheet start date

| | |
|---|---|
| **Field Type** | Date |
| **Description** | Earliest bookable week |
| **Functional Impact** | Blocks retro-entry before the date |
| **Example** | 01 Jan 2025 |
| **Cleanup / Change Considerations** | Moving it later hides earlier weeks from entry |
| **Best Practice** | Set once at go-live |

### Hours per day

| | |
|---|---|
| **Field Type** | Number (1–24) |
| **Description** | Standard working day used in validation and conversions |
| **Functional Impact** | Entry validation, day/hour maths, capacity |
| **Example** | 8 |
| **Cleanup / Change Considerations** | Changes apply going forward; submitted sheets untouched |
| **Best Practice** | Match employment standard |

### Minimum time interval

| | |
|---|---|
| **Field Type** | Dropdown (15 / 30 / 60 min) |
| **Description** | Granularity of entries |
| **Functional Impact** | Entry precision |
| **Example** | 30 minutes |
| **Cleanup / Change Considerations** | Coarsening prompts a warning — existing finer entries may not be representable |
| **Best Practice** | Choose once; 30 min suits most |

### Week range / Recall week range

| | |
|---|---|
| **Field Type** | Numbers |
| **Description** | Weeks visible around the current week; how far back managers can recall approved sheets |
| **Functional Impact** | Usability & correction window |
| **Example** | 4 / 2 |
| **Cleanup / Change Considerations** | None significant |
| **Best Practice** | Keep recall short for ledger stability |

### Use project allocation

| | |
|---|---|
| **Field Type** | Boolean (feature) |
| **Description** | Pre-fills sheets from allocations |
| **Functional Impact** | Compliance and speed of entry |
| **Example** | On |
| **Cleanup / Change Considerations** | Turning off removes pre-fill — expect compliance dip |
| **Best Practice** | On, if resourcing data is mature |

### Allow corrections / Copy timesheet

| | |
|---|---|
| **Field Type** | Booleans (features) |
| **Description** | Post-approval corrections; copy previous week |
| **Functional Impact** | Correction workflow; convenience |
| **Example** | On / On |
| **Cleanup / Change Considerations** | Corrections interact with locked financial periods |
| **Best Practice** | Enable corrections with a clear cut-off policy |

### Allow future booked weeks

| | |
|---|---|
| **Field Type** | Number |
| **Description** | How many weeks ahead booking is allowed |
| **Functional Impact** | Forward-load visibility vs speculative entries |
| **Example** | 2 |
| **Cleanup / Change Considerations** | None significant |
| **Best Practice** | Small numbers; forecasts belong in resourcing, not timesheets |

### Maximum user allocation

| | |
|---|---|
| **Field Type** | Decimal |
| **Description** | Over-allocation threshold as a multiple of capacity |
| **Functional Impact** | Over/under-allocation reporting |
| **Example** | 1.2 |
| **Cleanup / Change Considerations** | Changing redefines "over-allocated" in reports overnight |
| **Best Practice** | Agree with resource management |

### Overtime settings

| | |
|---|---|
| **Field Type** | Toggles + label + instructions |
| **Description** | Disable overtime; aggregate at project level; eligibility rules; the label used for overtime |
| **Functional Impact** | Overtime booking and costing; the label is stamped on generated actuals |
| **Example** | Overtime label "OT" |
| **Cleanup / Change Considerations** | The label becomes part of financial actuals — change it and old/new actuals carry different labels |
| **Best Practice** | Set label once; keep instructions current |

### Excluded project status / types

| | |
|---|---|
| **Field Type** | Multi-select |
| **Description** | Statuses and project types that cannot be booked (or corrected) against |
| **Functional Impact** | Immediately blocks new bookings on matching projects |
| **Example** | Exclude "On Hold", "Cancelled"; exclude type "Internal" |
| **Cleanup / Change Considerations** | References status/type names — renamed or deleted values silently fall out of the exclusion, reopening booking. **Also avoid commas in status and project type names**: these exclusion lists are stored as a single comma-joined string, so a name containing a comma is split into fragments when read back and the exclusion stops matching |
| **Best Practice** | Re-check after any change to the status or project-type lists |

### Submission / previous-week / approval deadlines + reminders

| | |
|---|---|
| **Field Type** | Day/time + toggles |
| **Description** | Weekly compliance deadlines and automated reminder emails |
| **Functional Impact** | Drives reminder emails and compliance reporting |
| **Example** | Submit by Friday 17:00; approve by Monday 12:00 |
| **Cleanup / Change Considerations** | Deadlines feed scheduled jobs — verify reminders after changes |
| **Best Practice** | Align to payroll/finance calendar |

### Miscellaneous tasks & intervals

| | |
|---|---|
| **Field Type** | List |
| **Description** | Non-project tasks (leave, training) and preset intervals |
| **Functional Impact** | Non-project time capture |
| **Example** | "Annual Leave" 7.5h preset |
| **Cleanup / Change Considerations** | New misc tasks appear automatically with a zero interval — review the list periodically |
| **Best Practice** | Keep the misc list short; everything else should be a project |

### Timesheet instructions

| | |
|---|---|
| **Field Type** | Text |
| **Description** | Guidance shown on the sheet |
| **Functional Impact** | User guidance only — no downstream impact |
| **Example** | "Book actual hours, not planned." |
| **Cleanup / Change Considerations** | None |
| **Best Practice** | Keep to three lines |

> **Multi-division note:** timesheet settings are stored **per division**. In a multi-division
> instance, repeat configuration (and cleanup checks) for each division.

---

## Section 9 — Boards & Workflow Configuration

**Purpose:** boards support intake, approvals and workflow automation — including Project
Pipelines that create projects and keep their fields synchronised with intake cards. Board
settings are configured on the board itself (Create Board / Board Settings); the Workflow Type is
visible only to Project Administrators.

### 9.1 Board-level settings

#### Board Title / Description / Category

| | |
|---|---|
| **Field Type** | Text |
| **Description** | Identity and grouping of the board |
| **Functional Impact** | The Category groups boards so users can find them |
| **Dependencies** | None |
| **Example** | "Project Intake", category "PMO" |
| **Cleanup Considerations** | None significant |
| **Best Practice** | Consistent naming per business area |

#### Board Function

| | |
|---|---|
| **Field Type** | Dropdown |
| **Description** | Agile board, Flex Work board, or Project Pipeline |
| **Functional Impact** | Project Pipeline enables project creation/sync from cards |
| **Dependencies** | Pipeline behaviour also needs a project-creation column (below) |
| **Example** | Project Pipeline for intake |
| **Cleanup Considerations** | Changing function on a live board changes card behaviour — avoid |
| **Best Practice** | One pipeline per intake route |

#### Workflow Type

| | |
|---|---|
| **Field Type** | Dropdown |
| **Description** | Generic Workflow, Project Workflow, or Stage Gate Workflow |
| **Functional Impact** | Project Workflow boards appear in project workspaces and can create/update projects; Stage Gate boards receive gate approvals |
| **Dependencies** | Project Workflow boards can be scoped by Project Category |
| **Example** | Project Workflow |
| **Cleanup Considerations** | See the Category note below |
| **Best Practice** | Set once at design time |

#### Applies to Project Category

| | |
|---|---|
| **Field Type** | Multi-select |
| **Description** | Scopes a Project Workflow board to certain project categories |
| **Functional Impact** | The board appears only on matching projects' workspaces |
| **Dependencies** | References Project Category **names** |
| **Example** | Applies to "Cyber Security" |
| **Cleanup Considerations** | Renaming/deleting the category silently unbinds the board |
| **Best Practice** | Freeze category names before wiring boards to them |

#### Is this board private?

| | |
|---|---|
| **Field Type** | Dropdown |
| **Description** | Private / Limited request / Public request |
| **Functional Impact** | Who can see the board and raise requests |
| **Dependencies** | None |
| **Example** | Public for an idea-intake board |
| **Cleanup Considerations** | Opening a private board exposes its history |
| **Best Practice** | Least visibility that still serves the intake |

#### Hide from Home Widget

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Hides board cards from the Home page widget and request dialogs |
| **Functional Impact** | Card visibility on users' home pages |
| **Dependencies** | None |
| **Example** | Hide internal triage boards |
| **Cleanup Considerations** | None |
| **Best Practice** | Hide plumbing boards |

#### Work request instructions

| | |
|---|---|
| **Field Type** | Rich text |
| **Description** | Guidance in the request dialog |
| **Functional Impact** | User guidance only |
| **Dependencies** | None |
| **Example** | "Describe the outcome, not the solution." |
| **Cleanup Considerations** | None |
| **Best Practice** | Keep current |

#### Allow assignees to update card status

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Whether assignees can move cards |
| **Functional Impact** | Workflow discipline |
| **Dependencies** | None |
| **Example** | Off for approval-controlled boards |
| **Cleanup Considerations** | None |
| **Best Practice** | Off where columns imply approvals |

#### Skip backlog

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | New requests go straight to the first open sprint |
| **Functional Impact** | Sprint boards only |
| **Dependencies** | None |
| **Example** | On for operational queues |
| **Cleanup Considerations** | None |
| **Best Practice** | — |

#### Project Methodology / Project Template

| | |
|---|---|
| **Field Type** | Lookups |
| **Description** | Applied to projects the pipeline creates |
| **Functional Impact** | New projects arrive with the right lifecycle and content |
| **Dependencies** | Reference the methodology/template lists |
| **Example** | Methodology "Waterfall", template "Standard Project" |
| **Cleanup Considerations** | Deleting the referenced methodology or template leaves the board pointing at nothing — pipeline project creation degrades or fails. Re-point boards before deleting either |
| **Best Practice** | Review board references whenever templates/methodologies change |

### 9.2 Column-level settings

| Field Name | Field Type | Description | Functional Impact | Cleanup Considerations |
|---|---|---|---|---|
| Column name / status / order | Text | The workflow stages of the board | Card status values; custom-property status bindings reference column names | Renaming a column breaks "Applicable/Required for statuses" bindings on card properties and orphans cards on the old status — review property bindings after renames |
| Mark as complete / Resolution time (SLA days) | Flags | Which columns mean "done"; SLA tracking | Cycle-time and SLA reporting | None significant |
| Column owners / team | User lists | Who owns cards in this column | Approval routing target; notifications | Owners leaving the organisation silently weaken routing — review periodically |
| Quick Assign rule | Dropdown (+ expression) | Auto-assigns cards entering the column (creator, column owner, project PM, business owner, executive, portfolio-based, or a dynamic expression) | Removes manual triage | Expression rules reference properties by name — renames break them |
| Approval assignee mode | Dropdown (+ expression) | Who decision requests go to when a card needs approval in this column | Governance routing (e.g. to the project's Business Owner, or dynamically by a property value) | Routing to a community role fails silently when the role is empty on the project — keep community fields populated ([Section 3](#section-3--project-community--ownership)) |
| Move when approved / rejected / conditional | Dropdowns (+ expressions) | Where the card goes after each decision outcome | Automates workflow progression; dynamic expressions allow value-based routing with the fixed state as fallback | Target states are column names — renaming columns breaks the movement rules |
| Enable column to create projects | Boolean | Marks this column as the project-creation stage of a pipeline | When a card reaches this column, Fluid creates (or syncs) the project | Deleting or unticking this column stops pipeline project creation with no warning — treat as a controlled change |
| Project handling (Create vs Sync) | Dropdown | Create a project (and sync afterwards) vs only sync an already-linked project | Controls whether the pipeline can create new projects | — |
| Default project status | Dropdown | Status stamped on the created project | New projects arrive at the right lifecycle stage | References a status **name** — see [Section 5.6](#56-project-status-list-status-report-rags-status-component-rags) |

### 9.3 How card-to-project property sync works (and why field names matter)

When a pipeline creates or updates a project, two passes run:

1. **First-class mapping.** Card properties whose **Name or Label** matches a built-in project
   field's label (Portfolio, Sub-portfolio, Tier, Business Driver, Project Type, Category, Funding
   Source, Cost Centre — by code, Methodology, Template, dates, community roles, External
   Reference, and more) populate that field — **but only when the card's value exists in the
   configured lookup list**. A value that doesn't match is *silently skipped*: no error, no log.
   This is the most common cause of "why didn't my pipeline populate the field".

2. **Generic property copy.** Remaining card properties copy to project properties by matching
   Name and Label (case-insensitive, in both directions). Option values are copied only if they
   exist in the target property's list. Properties set to "Read-only for all users" are excluded
   from sync. Cascading properties map level-by-level, so a single Region → Country → City cascade
   can populate several project fields at once.

**Cleanup implications:**

- Renaming a built-in field label
  ([Section 12](#section-12--field-labels--renaming-project-labels--field-names)), a custom
  property, or its label can silently break pipeline population.
- Keeping card option lists and project option lists identical (ideally via one Shared List) is
  what keeps sync lossless.

### 9.4 The Project Workflow Inspector — your impact-analysis tool

Administration Console → **Project Workflow Inspector** (`/Admin/ProjectWorkflowConfig`, Project
Administrators) produces a read-only export of the whole configuration graph: project and person
custom properties, boards with their columns and card properties, stage gates, portfolios (with
administrators/viewers/approvers), built-in fields with their allowed values, shared lists with
usage — plus a **dependency graph** showing which expressions reference which properties, which
properties share option lists, and which board fields map to which project fields.

Run it **before and after** any cleanup exercise. It is the fastest way to answer "what will
break if I rename this?"

---

## Section 10 — Catalogs

**Purpose:** catalogs standardise the wider environment your projects operate in — Applications,
Offices, Vendors, Strategic Drivers, KPIs — as managed reference data that can be tagged to
projects, schedule tasks, impacts, boards and resources. Configured at Data Administration →
Catalogs.

### Catalog name

| | |
|---|---|
| **Field Type** | Text (unique) |
| **Description** | The category of items being managed |
| **Functional Impact** | Becomes a selectable **data type** for custom properties — that is how catalogs are exposed on records |
| **Dependencies** | Unique across the instance |
| **Example** | "Applications" |
| **Cleanup Considerations** | Renaming is safe (items link by identity, not name) |
| **Best Practice** | Name in the plural, business-friendly |

### Active

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | Whether the catalog is in use |
| **Functional Impact** | Inactive catalogs stop being assignable; history preserved |
| **Dependencies** | None |
| **Example** | — |
| **Cleanup Considerations** | Prefer deactivation to deletion |
| **Best Practice** | — |

### Metadata Only

| | |
|---|---|
| **Field Type** | Boolean |
| **Description** | *Yes*: taggable/reportable only. *No*: items can also be impact owners or dependencies in risk management |
| **Functional Impact** | Controls whether risk registers can point at catalog items |
| **Dependencies** | Toggling to Yes does not remove existing impact links — only blocks new ones |
| **Example** | Vendors: No (vendors own risks); Strategic Drivers: Yes |
| **Cleanup Considerations** | None significant |
| **Best Practice** | Set No only where items genuinely participate in RAID |

### Catalog items (values)

| | |
|---|---|
| **Field Type** | Records (name, reference, external reference, Active, custom properties) |
| **Description** | The individual entries; maintained via the catalog's Bulk Edit; each item has its own custom properties and a Catalog Workspace showing usage across the portfolio |
| **Functional Impact** | Everywhere a catalog-typed property is used: project tagging, impact ownership, dashboards |
| **Dependencies** | Items are full records, not simple list values |
| **Example** | "SAP ERP", "Salesforce" in Applications |
| **Cleanup Considerations** | **Deleting a catalog is blocked while any item exists** — the strongest guard in the product. Deactivate items to retire them; their historical values remain intact |
| **Best Practice** | Assign a data owner per catalog; use the Catalog Workspace to review usage before retiring items |

> **Business example.** An "Applications" catalog with 200 entries lets every project tag which
> applications it touches; the Applications workspace then answers "what is our total change
> exposure on SAP this year?" — a question no free-text field can answer reliably.

---

## Section 11 — Governance Assessments

**Purpose:** Fluid's assurance engine. Assessment templates automatically evaluate projects
against weighted criteria, producing scores, pass/fail results and recommended RAG statuses — the
platform's manage-by-exception mechanism. Configured at Project Settings → Governance Assessments.

### Template name

| | |
|---|---|
| **Field Type** | Text |
| **Description** | The named assessment model |
| **Functional Impact** | Appears on project governance sections and PMO dashboards |
| **Dependencies** | None |
| **Example** | "Tier 1 Assurance Model" |
| **Cleanup Considerations** | Prefer disabling to deleting; historical scores survive deletion but lose drill-down |
| **Best Practice** | One template per governance tier |

### Inclusion criteria

| | |
|---|---|
| **Field Type** | Query (Project Type / Status / Portfolio) |
| **Description** | Which projects the template automatically applies to |
| **Functional Impact** | Determines assessment scope portfolio-wide |
| **Dependencies** | Stores type/status/portfolio **names as text** — renaming any of those silently narrows or empties the scope, with no warning |
| **Example** | Type = "Strategic Initiative" AND Status = "Active" |
| **Cleanup Considerations** | After any rename in Sections 1/2/5, re-open each template and re-verify its scope |
| **Best Practice** | Re-test template scope as part of every metadata change |

### Priority

| | |
|---|---|
| **Field Type** | Number |
| **Description** | Which template wins when a project matches several |
| **Functional Impact** | Ensures one authoritative assessment per project |
| **Dependencies** | None |
| **Example** | Tier 1 model priority over the default model |
| **Cleanup Considerations** | None |
| **Best Practice** | Explicitly order your templates |

### Pass score

| | |
|---|---|
| **Field Type** | Number |
| **Description** | The threshold for an overall pass |
| **Functional Impact** | Pass/fail reporting |
| **Dependencies** | None |
| **Example** | 75 |
| **Cleanup Considerations** | Changing re-baselines compliance reporting |
| **Best Practice** | Change at review points, not mid-cycle |

### Criteria (per template)

| | |
|---|---|
| **Field Type** | Weighted checks |
| **Description** | Each criterion has a group (Governance, Impacts, Financials, Resourcing, Schedule, Collaboration), a weight, success/fail messages, an optional applicability expression, and can test built-in conditions, required custom properties, or a custom expression |
| **Functional Impact** | The score, the per-group scores, and the recommendations shown to PMs |
| **Dependencies** | Criteria that test custom properties reference them **by name**; RAG bindings reference RAG names |
| **Example** | "All required data fields set", weight 10 |
| **Cleanup Considerations** | Renaming a custom property or a Status Report RAG silently breaks criteria that reference it |
| **Best Practice** | Keep criteria actionable — each failing check should tell the PM exactly what to fix |

### RAG binding & RAG recommendation

| | |
|---|---|
| **Field Type** | Lookups |
| **Description** | Ties a criterion to a status-report component and recommends a RAG when it fails |
| **Functional Impact** | Manage-by-exception: failed criteria surface as recommended status downgrades |
| **Dependencies** | References RAG names ([Section 5.6](#56-project-status-list-status-report-rags-status-component-rags)) |
| **Example** | Failed financials checks recommend Amber on the Financials component |
| **Cleanup Considerations** | As above — re-verify after RAG list changes |
| **Best Practice** | Bind only criteria a PM can act on |

---

## Section 12 — Field Labels & Renaming (Project Labels & Field Names)

**Purpose:** almost every built-in field label in this guide can be renamed to match your
organisation's language, at Project Settings → Project Labels & Field Names. This is a strength —
and a cleanup consideration of its own.

**Renameable labels include:** Title, Portfolio, Sub portfolio, Tier, Business Driver, Proposed
Solution, Line of Business, External Reference (and Alternate), Project Reference Prefix, Program,
Currency Symbol, Cost Code, Financial Reference, Invoice Number, Impact, Probability, Risk Rating,
Primary PM, Owner, Executive, Business Owner, Status Report labels (frequency, strapline length,
executive summary label and help), Enabled Impact Types, Primary Status Component RAGs, Default
Watchlist Page, and the Project/Program/Status-Report creation instruction texts.

| Consideration | Why it matters |
|---|---|
| Labels change everywhere at once | Screens, dialogs, and column headings in bulk-edit workbooks all follow the label — previously downloaded workbooks will no longer match |
| Pipeline sync matches on labels | Card properties populate built-in fields by matching the configured label ([Section 9.3](#93-how-card-to-project-property-sync-works-and-why-field-names-matter)) — renaming a label breaks existing board mappings until the card properties are renamed to match |
| Labels are presentation, roles are not | Renaming "Editors" changes only the display; the underlying permission role is unchanged. You cannot change what a field *does* by renaming it |
| Instructions fields are free governance | Project Creation / Program Creation / Status Report Instructions appear in the corresponding dialogs — use them to publish your naming conventions and data standards where users actually see them |

**Best practice:** set labels once during implementation, keep a change log, and treat any later
rename as a change with the same impact analysis as renaming a custom property.

---

## Section 13 — Cleanup & Rationalisation Playbook

### 13.1 Classify every field before touching it

Think of every configuration field as belonging to one of three categories:

- **Classification** — used to categorise work: Portfolio, Project Type, Category, Business
  Driver, Tier
- **Governance** — used to control oversight: Tier, Methodology, Stage Gates, Status workflow,
  Governance Level-style properties, visibility modes
- **Reporting** — used to analyse and measure: Funding Source, Cost Centre, Impact Sub Types, most
  Reportable custom properties

A field that serves **none** of the three — nobody filters by it, no workflow reads it, no report
shows it — is a candidate for removal. A field that serves **all three** is critical
infrastructure: change it only through a controlled process.

### 13.2 The decision ladder: retain → standardise → consolidate → deactivate → delete

1. **Retain** — the field has a clear purpose, an owner, and clean values. Document it and move on.
2. **Standardise** — right field, messy values. Fix the option list, convert free text to options,
   correct near-duplicate values via bulk edit.
3. **Consolidate** — several fields capture the same thing. Choose a survivor, convert its options
   to a Shared List, migrate data, repoint expressions/filters/boards, then remove the duplicates.
4. **Deactivate / lock** — the field or value is no longer used for new work but history matters.
   Use Active flags, User Locked, or Reportable = off.
5. **Delete** — only after data migration, dependency sweep (Project Workflow Inspector), and
   stakeholder sign-off. Remember: **deletion rarely deletes data — it orphans it.**

### 13.3 Safety matrix — what happens on rename / delete

| Configuration area | Rename in UI | Rename reaches existing records? | Delete guard | What deletion leaves behind |
|---|---|---|---|---|
| Portfolio / SubPortfolio | Yes | No | None | Old names on projects; access removed; sub-portfolios deleted with parent |
| Project Type | Yes | No | Must keep at least one; "Program" protected | Old names on projects; its timesheet activities deleted |
| Project Category | Yes | No | None | Old names on projects; boards scoped to it unbind |
| Business Driver / Tier | No (create-only) | — | None | Old names on projects; tier deletion can strand linked drivers |
| Funding Source | Yes | No | None (and no Active flag) | Old names on projects and financial extracts |
| Cost Centres / Cost Codes / LOB | No (create-only) | — | None | Old codes on projects/resources |
| Impact Sub Types | No (create-only) | — | None | Old names on historic impacts |
| Risk rating scales | Edit weights/labels | Existing ratings not recalculated | None | Mixed-vintage ratings |
| Expense Category / Type | Yes | No | None | Old text on financial rows; category delete removes its types |
| Currency | Yes | No | Monthly rates block deletion (silently) | Unconvertible financial rows |
| Rate Card | Yes | No — detaches resources | None | Fallback to the "Default" card |
| Division / Department / Team | Yes | **Yes** — propagates to active resources | Team delete blocked by resource plans | The safest area |
| Project Status | No (create-only) | Active toggle syncs all projects on it | None | Orphaned projects on deleted status |
| Status Report RAGs | No (create-only) | — | System RAGs + default protected | Broken workflow/assessment references |
| Methodology | Yes | No | None | Projects pointing at a missing lifecycle — migrate first |
| Phase | Yes | **Yes** — propagates | None | Delete also propagates, preserving closed/in-approval gates |
| Custom property (Name) | Immutable | — | None | Orphaned values (re-adopted if name reused); broken expressions/filters/criteria |
| Custom property (Label) | Yes | n/a | — | Broken pipeline mappings and label-based expressions |
| Shared List | Edit propagates instantly | **Yes** (all linked properties) | None | Deletion unlinks and clears every linked property |
| Catalog | Yes (safe) | Items link by identity | **Blocked while items exist** | — |
| Board / columns | Yes | Cards keep old status text | None | Broken property status-bindings, movement rules |
| Governance template | Yes | No | None | Orphaned criteria; scope silently broken by upstream renames |

### 13.4 Configuration review checklist

Before creating, changing or deleting any configuration value, ask:

**Governance**
- Does this support a governance model or stage gate? Will approval processes be affected?
- Is the value referenced by name in any expression, routing rule, RAG binding or assessment scope?

**Reporting**
- Will dashboards or scheduled reports use this information? Is it a reporting dimension?
- Are there saved filters or bookmarked views keyed on it?

**Financial management**
- Does it influence forecasting, capitalisation, amortisation or actuals? Is Finance aware of the
  change?

**Resource planning**
- Does it impact allocations, capacity reporting or timesheet validity?

**Security**
- Does it influence portfolio access or project visibility? Who gains or loses access?

**Workflow automation**
- Is the field used in board workflows, pipeline sync mappings, or dynamic-logic expressions?
  (Run the Project Workflow Inspector.)

**Data integrity**
- Which existing records carry the value as text? What is the re-stamping plan (bulk edit)?
- Is the bulk-upload sheet complete? (Omitted rows are deleted.)

**Future growth**
- Will this still make sense in two years? Can users understand it consistently without training?

### 13.5 Recommended cleanup sequence

1. **Export the baseline** — run the Project Workflow Inspector and the metadata exports; snapshot
   before touching anything.
2. **Fix values before fields** — standardise option values and re-stamp orphaned text on projects
   via bulk edit.
3. **Consolidate duplicates into Shared Lists** — the highest-value, lowest-risk win.
4. **Deactivate, observe, then delete** — retire values with Active/User Locked flags, wait a
   reporting cycle, delete only what nobody missed.
5. **Re-test the wiring** — status approval workflow, pipeline field population, governance
   template scopes, timesheet exclusions.
6. **Document ownership** — every list and property gets an owner and a review cadence.

---

## Final Recommendation

The most successful Fluid implementations treat configuration as **enterprise data architecture**,
not administration settings. Every field should have a clear purpose, a defined owner, and an
understood impact across governance, reporting, financial management, resource planning and
portfolio decision-making.

Three habits keep a configuration healthy:

1. **One concept, one field, one list.** Duplicated fields and near-duplicate values are the root
   cause of most unreliable reporting. Shared Lists and catalogs exist to prevent them.
2. **Names are contracts.** Statuses, RAGs, categories, property names and labels are referenced
   *by name* throughout workflows, expressions and assessments. Treat renames as changes with
   dependencies, not cosmetic edits.
3. **Deactivate first, delete last.** Almost nothing in Fluid blocks a destructive change on your
   behalf. Active flags, User Locked flags and Reportable switches let you retire configuration
   reversibly — use them, observe a full reporting cycle, and delete only then.

Used this way, this guide is both your configuration inventory and the governance standard for
keeping it clean.