Person Core_Details

by

Overview

The Person Core Details view defines the canonical person object for the IFS and external app-aligned Person domain within the Common Data Model (CDM).

It provides a controlled identity layer for representing a human individual independently of any single employment record, using a stable PERSON_UID and a small set of governed link attributes.

This view exists to support identity resolution, cross-system linking, and restricted people reporting, rather than general workforce or organisational reporting.

Purpose

  • Provide a single canonical person identity independent of workforce assignment structure
  • Support cross-system person matching using stable link keys
  • Establish the core object for the restricted Person domain
  • Separate human identity from employee workforce context
  • Enable governed linkage between person, payroll, and hashed email identities

Key Features

1. Canonical Person Object

The view defines the person object using:

  • OBJECT_CLASS → fixed person-class identifier
  • OBJECT_CODE → PERSON_UID
  • OBJECT_SEQ → JSON object containing:
    • COMPANY_ID
    • PERSON_UID

This ensures a stable and standardised identity structure for person-level reporting and integration.

2. Stable Person Identity

The core identifier is:

  • PERSON_UID

This is intended to act as the canonical person key, allowing a single human identity to be represented consistently even where underlying operational records may vary across systems or employments.

This is the central reason the Person domain exists.

3. Controlled Identity Metadata

OBJECT_METADATA carries a limited set of person-level link attributes, including:

  • PERSON_ID
  • EMAIL
  • PAYROLL_ID

These attributes are included to support:

  • identity reconciliation
  • controlled linking
  • restricted HR and person-based reporting
  • cross-reference to source systems

This metadata is intentionally narrow and identity-focused.

4. Hashed Email Linkage

Email is represented using a hashed email token, rather than relying on unrestricted plaintext identity.

This supports:

  • secure linking across systems
  • reduced exposure of personal data
  • alignment to broader identity and privacy controls

Where needed, the metadata can still retain descriptive context in a governed way.

5. Human-Readable Person Name

OBJECT_NAME provides a safe, readable label for the person object.

This makes the domain usable for controlled reporting and investigation, whilst still maintaining a governed structure for identity keys and link attributes.

6. Identity-Driven Source Layer

The view is sourced from:

This indicates that the view is built from a resolved identity layer, rather than directly from raw HR or workforce assignment sources.

That is appropriate for the Person domain, because the purpose is not to restate employment data but to define the canonical person.

Design Principles

1. Person is not Employee

This view does not describe the person as a worker in a particular organisational context.

It does not aim to be the primary source for:

  • job
  • assignment
  • organisation structure
  • workforce status
  • operational line management

Those belong primarily in the Employee domain.

2. Identity Before Assignment

The Person domain exists to answer:

  • who is this human?
  • how do we resolve this person across systems?
  • what stable identifiers can we use to govern person-level reporting?

This is a fundamentally different question from:

  • what is this employee’s current job or position?

3. Minimal Core, Richer Meta

person.core_details should remain deliberately compact.

Its role is to provide:

  • canonical object identity
  • safe object naming
  • essential link metadata

Any extension of the Person domain should happen carefully through:

  • person.meta_codes
  • person.meta_dates
  • restricted item layers where justified

This keeps the core stable and avoids it becoming a mixed-purpose HR record.

4. Governed Identity Domain

The Person domain is best treated as a controlled identity and restricted people domain, not as a broader convenience layer for general reporting.

That means:

  • identity keys belong here
  • sensitive linkage belongs here
  • workforce-operational reporting does not primarily belong here

Usage Guidance

Use this view when:

  • establishing a canonical person reference
  • linking multiple source identities to one person
  • supporting restricted people reporting
  • resolving person-level identity across systems

Use employee.core_details instead when the requirement is:

  • workforce reporting
  • organisational assignment
  • line management
  • employment context
  • broad operational reporting

Do not:

  • treat this view as a replacement for employee identity
  • use it as the main workforce reporting object
  • overload it with assignment or organisation detail

What This View Is Not

  • Not the main employee reporting view
  • Not the organisational assignment layer
  • Not a transactional HR fact view
  • Not the primary source for workforce structure

It is the canonical person identity layer.

Summary

person.core_details provides the foundation of the Person domain, defining a governed and canonical representation of an individual using PERSON_UID and a controlled set of identity link attributes.

Its purpose is to separate human identity from employment context, so that:

  • Person remains the trusted identity domain
  • Employee remains the trusted workforce domain

That boundary is what gives both domains a clear reason to exist.

Leave a Comment