# Organisational Model

The Digital Post Platform is built around a hierarchical organisational model that reflects how digital communication is governed and operated across different markets and participants.

This model defines how organisations, sender identities, and system integrations are structured, and how responsibilities and permissions are distributed.

Understanding this model is required before integrating with the platform.

## Platform Holder

Each deployment of the Digital Post Platform is operated under a platform holder.

The platform holder is responsible for:

- Overall governance of the platform
- Market specific configuration
- Onboarding of organisation accounts
- Definition of operational and compliance policies


In some markets, e-Boks acts as platform holder.
In other markets, this role is held by a partner or customer, while e-Boks operates the platform on their behalf.

All organisations and sender identities exist under the authority of a platform holder.

## Organisation Accounts

An organisation account represents a legal, administrative, or operational entity that participates in the platform.

Organisation accounts are used to group related sender identities and system integrations.

Typical examples include:

- Public authorities
- Financial institutions
- Utility providers
- Private enterprises


Each organisation account:

- Belongs to exactly one platform holder
- May contain one or more sender identities
- May contain one or more system integrations


### Organisational Hierarchy

Organisation accounts may be structured hierarchically.

A parent organisation may contain one or more subordinate organisations.

This supports modelling of:

- Corporate group structures
- Departments
- Subsidiaries
- Cost centres


Configuration and permissions defined at a parent level are inherited by subordinate organisations unless explicitly overridden.

To reduce complexity, organisation hierarchies should be kept as flat as possible and only extended where there is a clear governance requirement.

## Sender Identities

A sender identity represents a logical communication identity within an organisation account.

Sender identities define how messages appear to receivers.

Each sender identity:

- Belongs to exactly one organisation account
- Has its own name and branding
- Defines message capabilities and features
- Controls subscription behaviour


An organisation account may operate multiple sender identities for different purposes, services, or business units.

Examples include:

- Billing communications
- Regulatory notifications
- Service updates
- Contractual documents


Sender identities are used in all message deliveries.

## Receivers

Receivers are the intended recipients of digital messages.

Receivers interact with the platform through client applications and services provided by the platform holder.

Receivers are not part of the organisational hierarchy.

They are external to organisations and represent the endpoint of digital communication.

Messages are always delivered to receivers under a specific sender identity.

## System Integrations

System integrations represent technical clients that authenticate and interact with the platform APIs.

A system integration:

- Belongs to an organisation account
- Is associated with a client certificate
- Has a unique machine identifier
- Is granted specific permissions


System integrations are used for:

- Submitting deliveries
- Retrieving reports
- Accessing mailbox or file APIs
- Performing automated operations


Each integration acts on behalf of its organisation and sender identities.

## Access Control and Permissions

Access to platform functions is controlled through permissions assigned at organisational and integration level.

Permissions determine:

- Which APIs may be accessed
- Which sender identities may be used
- Which administrative functions are available
- Which reporting data can be retrieved


Permissions are typically assigned and maintained by the platform holder.

Depending on market governance, platform holders may grant limited administrative access to organisation representatives.

## Inheritance and Governance Principles

The organisational model follows these core principles:

### Hierarchical Inheritance

Permissions and configuration flow from parent to child organisations.

This ensures consistent governance and reduces duplication.

### Separation of Responsibilities

- Platform holders govern the platform
- Organisation accounts operate sender identities
- System integrations perform technical operations
- Receivers consume messages


Each role has clearly defined responsibilities.

### Controlled Delegation

Access may be delegated to subordinate organisations or integrations, but remains bounded by higher level policies.

This ensures traceability and accountability.

## Relationship Overview

The main relationships are:

pre
Platform Holder
└── Organisation Account
    ├── Sender Identity
    └── System Integration
        └── API Access

Receiver (external)
← Receives messages from Sender Identities

All message deliveries originate from a system integration acting on behalf of a sender identity within an organisation account.

## Implications for Integrators

For system integrators, this model implies:

- Every API call is associated with an organisation account
- All deliveries reference a sender identity
- Authentication is tied to a system integration
- Permissions limit accessible functionality


Before starting development, integrators must ensure that:

- Organisation accounts are created
- Required sender identities are configured
- System integrations are active
- Appropriate permissions are assigned


These prerequisites are managed according to the governance model of the relevant platform holder.

## Related Documentation

For more information, see:

- Message Delivery Model
- Message Lifecycle
- Authentication Setup
- Getting Started Guides