Organisation and access

HR data in Power BI: security per department and privacy

HR data in Power BI is secure when managers only see their own department through row-level security and the model only holds the fields the report needs. KoppelHet builds that security from the organisation in AFAS, Nmbrs or BuddeeHR and leaves social security number, address, bank account and reason for absence out of the model.

Last updated: 9 November 2026

Discuss your integration All about HR data to BI

What it is

An HR dashboard holds names, absence and sometimes salaries. Without security, anyone with access to the report sees everything. AFAS says so itself about its dashboards without filter authorisation.

On top of that, more ends up in the model than needed. An export from the HR system includes social security number, address and bank account, while no report needs them.

How the integration handles it

KoppelHet builds the security per department from the organisational units in AFAS, so a new department is shielded straight away.
Row-level security in Power BI only applies to viewers, not to admins and members of a workspace. The HR model therefore sits in its own workspace where managers are viewers only.
BuddeeHR has a direct and an indirect manager per job period. From that KoppelHet builds the line, so a head of department sees their own people and those of their team leads.
In the YouForce Data API the customer chooses per configuration which columns are included. Social security number, addresses and private contact details are switched off there, so they never leave YouForce.
Absence goes along without diagnosis or notes, and with Personio only the type of absence, not the reason.
Salaries per person are only visible to roles allowed to see them; managers see totals. Often a salary band is enough instead of the amount.

Edge cases we handle

HiBob silently omits fields the service user has no right to. Workday does the same with fields outside the security group. KoppelHet compares requested and received fields on every run and reports the difference.
In BambooHR what the API returns depends on the rights behind the API key, and datasets need extra rights. KoppelHet checks them at setup, so the first report is not empty.
In the older Personio API only attributes released as readable come along. An attribute added later stays empty until someone releases it; KoppelHet reports an empty column.

What KoppelHet does

You are the controller and KoppelHet is the processor, under a data processing agreement. KoppelHet only requests read access in the HR system to the fields the report needs, agrees upfront who sees which rows and reports when an expected column arrives empty.

Common integrations

AFAS Profit → Power BI

AFAS to Power BI integration: HR data from Profit in Power BI, with history and its own security

Nmbrs → Power BI

Nmbrs to Power BI integration: HR and payroll data ready for reporting per company

BuddeeHR → Power BI

Buddee to Power BI integration: headcount, contracts, absence and turnover from Buddee in one model

Visma Raet YouForce → Power BI

YouForce to Power BI integration: HR and payroll data from Visma Raet in one reporting model

HiBob → Power BI

HiBob to Power BI integration: people data and work history from Bob in Power BI

Workday → Power BI

Workday to Power BI integration: global HR data in Power BI, with retroactive changes handled correctly

Frequently asked questions

Which data ends up in the report?

Only what the report needs. We leave out social security number, address and bank account unless there is a reason to include them.

Do managers only see their own people?

Yes, if they are viewers in the workspace. Per company or department we define who sees which rows.

Why is a column in Power BI suddenly empty?

Usually it is a permissions issue in the HR system, not a data error. KoppelHet checks on every run whether all expected columns are filled and reports the difference.