Personio
Let hires look people up in Personio and see absences and attendance, read only, with personal data kept to a minimum.
Explore 4 actions and their permissionsExact inputs, sign-in scopes, access limits and approval rules.
With Personio connected, a hire can:
- look people up: name, status, position, department and manager,
- see absences in a date range (or who's off on a day), and whether they're approved,
- see attendance: hours worked and breaks, per person and day,
- be woken when an absence is requested or changes.
Hires can't change anything in Personio, whatever access you give them.
Personal data: the minimum, unless you widen it
HR data is about people, and much of it is sensitive. Personio sends everything it holds about a person (gender and every custom field, bank details included if you keep them there), so Roster cuts each record down before a hire sees it:
- By default a hire sees only names, status, positions, departments and managers.
- Never by default: email addresses, gender, pay, bank details, birth dates, addresses, any custom field, why someone is off (the absence type, like "Sick leave") and comments on absences or attendance.
- You widen it on purpose, on the connection: More fields hires may see for ordinary
fields (like
emailoremployment_start_date), and Sensitive fields hires may see for the rest (likeabsenceType,absenceComment,attendanceComment,gender, or a custom field by its name in Personio, likeIBAN). A sensitive field typed in the ordinary list is refused, so it always takes a deliberate second step. - When comments are shown, phone numbers and email addresses in them are taken out.
- Hires are told that personal data stays inside your team.
1. Make API credentials in Personio
Personio's credentials page is on your company's own address: sign in at login.personio.com and follow the steps below.
- In Personio, open Settings → Integrations → API credentials and click Generate new
credentials. Name them
Roster. - Give them read access to persons, employments, org units, absences and attendances, and nothing else.
- Copy the client ID and client secret.
2. Connect it in Roster
- Open Integrations → Tools → Add a tool, search for Personio and choose it.
- Client ID and Client secret: paste them.
- More fields hires may see and Sensitive fields hires may see: leave them empty unless a hire's job needs more.
- Click Connect.
Roster checks the key when you click Connect. Once it's accepted, the connection shows Connected as your Personio account. If it's refused, Roster says what to fix (a mistyped key, a missing permission) and saves nothing.
3. Give hires access
On the hire's Tools tab, click Give access on Personio. Read only and Read and write give the same tools here, since nothing is ever changed.
- Departments: departments whose people it may see, by name or ID as Personio shows them. Leave it empty for everyone. Anyone in another department is refused, in every list and lookup.
Watching absences
A hire's responsibility can watch Personio: it's woken when someone in its departments requests an absence or one changes.
Tools and permissions reference
This reference is built from the same definitions Roster uses to connect Personio and give hires access. It updates with each release.
Authentication and requested permissions
The account or app you connect sets the outer limit. Each hire's access can narrow it further. Connecting a tool gives it to no hire until you give access on that hire's Tools tab.
OAuth client credentials
From Personio: Settings → Integrations → API credentials → Generate new credentials. Give them read access to persons, employments, org units, absences and attendances only.
When making a key, use these permissions from the connection guide:
- Persons: read
- Employments: read
- Org units: read
- Absences: read
- Attendances: read
Connection fields
| Field | What to provide |
|---|---|
Client IDclientIdOptional | From Personio: Settings → Integrations → API credentials → Generate new credentials. Give them read access to persons, employments, org units, absences and attendances only. |
Client secretclientSecretOptional · sealed secret | Use the value for your account or connection. |
More fields hires may seemoreFieldsOptional | By default hires see only names, status, positions, departments and managers. Add ordinary fields here by their name, like email, employment_start_date, weekly_working_hours. Sensitive ones go in the next list. |
Sensitive fields hires may seesensitiveFieldsOptional | Only if a hire's job needs them: pay, identity numbers, birth dates, home addresses, private contact details, notes. Like absenceType, absenceComment, gender. Leave empty unless you mean it. |
Per-hire limits
Read-only hires receive only actions that read. Read-and-write access also allows actions that change things, where the connection itself permits them. An empty resource allowlist usually means everything the connected account can reach; each field below explains its meaning.
| Field | What to provide |
|---|---|
DepartmentsdepartmentsOptional | Departments whose people it may see, by name or ID as Personio shows them. Leave empty for everyone. |
Actions
4 actions: 4 only read and 0 change something. A read action may still need approval when your workspace or hire is set to ask. A locked approval requirement always applies.
4 of 4 actions. Open an action for its arguments and full input schema.
list_employeesRead only
Active people in Personio, found by words in their name. Only the fields this connection allows are shown; personal data stays inside your team, so don't repeat it outside.
Approval: Uses your workspace and hire approval settings.
| Argument | Type | Details |
|---|---|---|
wordsOptional | string | See input schema below. |
limitOptional | integer | See input schema below.Default: 20 |
Full input schema (JSON)
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"words": {
"type": "string",
"maxLength": 200
},
"limit": {
"default": 20,
"type": "integer",
"minimum": 1,
"maximum": 50
}
}
}get_employeeRead only
One person in Personio by their ID, with the fields this connection allows. Only the fields this connection allows are shown; personal data stays inside your team, so don't repeat it outside.
Approval: Uses your workspace and hire approval settings.
| Argument | Type | Details |
|---|---|---|
idRequired | string | See input schema below. |
Full input schema (JSON)
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"id": {
"type": "string",
"pattern": "^[\\w-]{1,64}$"
}
},
"required": [
"id"
]
}list_absencesRead only
Absences overlapping a date range (the next 14 days by default; give one day to see who's off then): who, from when to when, and whether it's approved. Why someone is off is shown only if this connection allows it.
Approval: Uses your workspace and hire approval settings.
| Argument | Type | Details |
|---|---|---|
startOptional | string | See input schema below. |
endOptional | string | See input schema below. |
personOptional | string | See input schema below. |
Full input schema (JSON)
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"start": {
"type": "string",
"pattern": "^\\d{4}-\\d{2}-\\d{2}$"
},
"end": {
"type": "string",
"pattern": "^\\d{4}-\\d{2}-\\d{2}$"
},
"person": {
"type": "string",
"pattern": "^[\\w-]{1,64}$"
}
}
}list_attendancesRead only
Attendance (hours worked and breaks) recorded in Personio for a date range (the last 7 days by default), per person.
Approval: Uses your workspace and hire approval settings.
| Argument | Type | Details |
|---|---|---|
startOptional | string | See input schema below. |
endOptional | string | See input schema below. |
personOptional | string | See input schema below. |
Full input schema (JSON)
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"start": {
"type": "string",
"pattern": "^\\d{4}-\\d{2}-\\d{2}$"
},
"end": {
"type": "string",
"pattern": "^\\d{4}-\\d{2}-\\d{2}$"
},
"person": {
"type": "string",
"pattern": "^[\\w-]{1,64}$"
}
}
}Watches and incoming events
- This integration supports a responsibility that watches for changes. The guide above explains what it checks and how to limit it.
- No incoming webhook handler is declared for this integration.
Limits and troubleshooting
- Permission errors: check both the connected account's rights and the hire's resource and read/write limits.
- Expired or revoked access: reconnect or replace the key on the connection.
- Rate limits and unavailable services can interrupt work. The hire's timecard records the outcome.
- The action schema describes accepted inputs. It does not grant additional access or bypass approvals.