What this view is for
Project.meta_codes provides the categorical and classification attributes for projects.
Where Project.core_details defines what a project is,
Project.meta_codes defines how a project is described and grouped.
If you’re asking “what type of project is this?”, “which programme does it belong to?”, or “how should this project be categorised?” — this is where you look.
Architectural maturity
This view is delivered as a cvw (collated view).
It is assembled from regional shards, allowing us to:
- Blend RPV/MDM-aligned sources where available
- Fall back to snapshot (mvw) sources where required
- Harmonise regional coding differences into a single logical structure
- Improve classification quality over time without breaking reports
This supports regional variation today while converging on a consistent global coding model.
Level of detail (grain)
- One row per project per code attribute
- Each row represents a single classification applied to a project
- No aggregation
- Multiple rows per project are expected (one per attribute)
This design avoids wide tables and allows new classifications to be added without changing report schemas.
What you’ll find in this view
Each row contains:
- OBJECT_SEQ – the project identifier (company + project)
- META_TYPE – the category of classification (e.g. PROGRAMME, REGION, BUSINESS_TYPE)
- ATTRIBUTE – the name of the specific attribute within that category
- CODE_VALUE – the coded value (ID or short code)
- VALUE_METADATA – descriptive or structured metadata (often JSON)
Typical examples include:
- Programme
- Project type
- Strategic pillar
- Sales region / delivery region
- Business line or capability group
- Risk or status classifications (where categorical)
This view standardises how project classifications are exposed, regardless of how they are stored in source systems.
How to join this view
Always join to Project.core_details using:
OBJECT_SEQ
This ensures:
- Classifications attach to the correct project
- Company boundaries are respected
- The join pattern is consistent with Busopp, Order and Invoice
- Regional shard differences are abstracted away
In reports, this view is usually pivoted or filtered by META_TYPE and ATTRIBUTE.
How this view is commonly used
Report writers typically use Project.meta_codes to:
- Group projects by programme, region or business unit
- Filter projects by type or strategic classification
- Apply organisational hierarchies in reporting
- Provide slicers and legends in dashboards
- Enrich project lists with business meaning
It is almost always used alongside:
- Project.core_details (identity)
- Project.meta_dates (timing)
- Project.item_values (financials)
What this view does not contain
By design, meta_codes does not include:
- Numeric measures
- Dates or time logic
- Financial values
- Calculations
It contains labels, codes and categories only.
This separation keeps classification stable while values and dates evolve independently.
How this differs from core_details
- core_details = what the project is
- meta_codes = how the project is classified
core_details gives you the object.
meta_codes tells you how to organise it.
Where this fits in a report build
A typical pattern looks like:
- Start with Project.core_details
- Join Project.meta_codes for classification
- Add Project.meta_dates for lifecycle timing
- Add Project.item_values for cost and revenue
- Build measures and visuals using meta_codes for grouping and filtering
If a report needs to answer “how are our projects distributed by type, programme or region?”, this view provides the structure to do that.
Key takeaway
Project.meta_codes gives you a flexible, extensible way to classify projects without changing the project object itself.
Use it to group, filter and organise projects consistently across regions, and to keep business meaning separate from financial logic.