Project.meta_codes roles

by

Provides project role assignment metadata in the standard CDM meta_codes structure, with regional view variants for APC, CAD, USD, UKS, and future IFS-aligned sourcing.

Purpose

The project.meta_codes_roles family provides a standardised project-role metadata pattern for identifying named project responsibilities against a project object.

This allows project role assignments to be consumed consistently across regions even where the underlying operational source differs.

Grain

One row per project role attribute per project.

Business Use

This view family supports:

  • identifying project managers and other accountable role holders against projects
  • standardising regional role assignment data into a common CDM pattern
  • enabling consistent downstream reporting and API use
  • supporting migration from regional/local role sources toward future IFS-aligned sourcing

Consumer Interpretation

Consumers should treat the family as:

  • a standard project role metadata contract
  • regionally sourced but structurally aligned
  • suitable for current-state reporting of project role assignments
  • not a full transactional or historical role event table

Fields

Each regional variant emits the same core structure.

OBJECT_SEQ

Project object identifier in JSON form:

{"COMPANY_ID":"<company>","PROJECT_ID":"<project_id>"}

META_TYPE

Constant value:

ROLE

ATTRIBUTE

Role type, for example:

  • PROJECT_MANAGER
  • FINANCIALLY_RESPONSIBLE
  • CUSTOMER_RESPONSIBLE
  • PROJECT_SPONSOR
  • RESOURCE_MANAGER
  • PROJECT_CONTROLLER

CODE_VALUE

Hashed role-holder identity.
Typically aligned to LINK_KEY EMAIL with Employee where email is available.

VALUE_METADATA

JSON description of role-holder details, typically containing:

  • CODE = hashed role-holder identity (Email)
  • NAME
  • PERSON_ID where available
  • EMAIL where available or regionally derived, and typically used to create CODE

Audit fields

Standard view audit fields, including:

  • CREATE_DATE
  • EXPIRY_DATE
  • ACTIVE_FLAG
  • SOURCE_SYSTEM

CHECKSUM

The CHECKSUM column is used to generate a stable Row Presence Identifier (RPI) for each project-role relationship.

Design Pattern

The family uses a regional role-source variant design.

This means:

  • the output contract remains stable
  • the regional source logic may differ
  • the published view name makes the region explicit
  • migration to future IFS sourcing can happen without breaking the conceptual pattern

Strategic Direction

project.meta_codes_roles_UKS represents the current UK regional basis.

Over time, the future-state target is expected to be:

  • project.meta_codes_roles_IFS

This provides a clear path from region-specific operational sourcing toward a Cloud IFS-aligned enterprise model.

Sample Exec

get.myview '<token>','project','meta_codes','roles'
get.myview '<token>','project','meta_codes','roles_APC'

Regional Variant Naming Pattern

Regional variants are explicitly identified in the published view name.

  • project.meta_codes_roles_APC
  • project.meta_codes_roles_CAD
  • project.meta_codes_roles_USD
  • project.meta_codes_roles_UKS
  • project.meta_codes_roles_IFS

Variants

SourceCurrent Role CoverageIdentity PatternCompany LogicNotes
APCRegional role-source variant for APC projects.pmo.APAC_Project_ListPROJECT_MANAGERUses source project manager email where available, with fallback to project manager name.Company derived through PRU-to-company mapping.Used where APC project role assignment is maintained via PMO-managed source structures rather than core IFS role sources.
CADRegional role-source variant for CAD projects.pmo.Project_Period_Report_CADPROJECT_MANAGERUses parsed manager name to derive a regional person code, then constructs a CAD email pattern:
<first initial><surname>@ca.bmt.org		Fixed company value: 5013This variant uses a derived identity pattern because the source does not expose a directly joined enterprise person/email reference.
USDRegional role-source variant for USD projects.similar regional PMO/project reporting source to CADexpected to mirror CAD-style PROJECT_MANAGER patternExpected to use a similar locally derived role-holder identity approach where direct enterprise person references are not available.Fixed company value: 5088This variant should be documented as structurally similar to CAD unless and until a more authoritative USD source pattern is adopted.
UKSRegional role-source variant for UKS projects.current UKS regional source / legacy IFS-aligned sourcecurrent project role attributes as available in UKS solutionhashed role-holder email identity (LINK_KEY EMAIL with Employee)Derived from project source contextUKS represents the present UK regional pattern and is expected to form the basis of transition towards the future Cloud IFS-aligned solution.
IFSFuture enterprise-aligned variant for Cloud IFS project roles.future Cloud IFS role and project structuresRepresents the target-state enterprise pattern for project role assignments.hashed role-holder email identity (LINK_KEY EMAIL with Employee)Derived from project source contextThis variant will become the long-term strategic basis for project role metadata once Cloud IFS regional alignment is complete.

Caveats

  • Regional variants may differ in metadata richness.
  • CAD and USD may rely on derived person identity logic rather than authoritative enterprise person joins.
  • APC uses local PRU-to-company mapping logic.
  • UKS should be treated as transitional where Cloud IFS adoption is planned.
  • Consumers requiring role history or effective dating should use a more specific history/event-based structure where available.

Leave a Comment