At 50 employees, manual provisioning breaks. At this stage teams on Personio may have partial automation of onboarding and offboarding but start to look for a more mature SaaS provisioning process. One where SaaS accounts are automatically set up for new hires, managers approve the sensitive ones in a click, and a departure revokes every SaaS app automatically.

But Personio alone will not accomplish that. Personio knows a new finance hire starts Monday. It has their record, their onboarding workflow, and a task waiting for whoever owns IT. What it cannot do is put that person into your accounting suite and expense tool on the first morning. That still falls to a human, working through each admin console one account at a time.

The usual approach to automate this is SCIM/SAML provisioning. But analysis of our own customer data found that a typical organization only automates about 25% of their apps with SCIM. This is to avoid upgrading every app to the enterprise tier SCIM needs (the SSO tax) and a long tail of apps is left uncovered. It works, but is not always the best identity governance automation approach for teams smaller than 300 employees.

In this blog:

• SaaS access management with Personio's native features and where it's limited

• Automating SaaS provisioning with Personio and AccessOwl

• Onboarding and offboarding with Personio and DIY automation (scripts, API connectors)

Approach 1 - SaaS access management with Personio's native features

What Personio handles on its own

For onboarding and offboarding automation, Personio handles the HR half. It is the system of record for who works at the company: their role, team, department, legal entity, custom fields, and the exact start and end dates.

From there it fires onboarding and offboarding workflows: task templates with due dates, assignees, and automatic reminders, including the task that tells IT to set up a new person's accounts. What it automates is the process around the person, not the accounts across your apps.

Does Personio have an IT module to automate SaaS provisioning?

There is no Personio IT product or access-management add-on. Personio does not provision your SaaS apps itself, and it points customers to a dedicated tool to do it. AccessOwl is listed on Personio's own Marketplace, where Personio describes it as managing employees' access to applications with request and approval workflows in Slack.

Personio can create and deactivate the account in two directories itself, Google Workspace and Microsoft Entra, and hand other apps to the identity provider you already run. That works the same way it does for most HR tools, and it only reaches the apps wired to your IdP. Everything past those two directories stays manual, and Personio has no way to see Shadow IT, the apps people sign up for outside of IT.

One more thing worth knowing is the tier. Personio gates its onboarding and offboarding workflows, its SSO, and its Okta and Entra integrations behind the paid Pro plan, not the entry-level Core plan.

Partial automation of onboarding and offboarding is a common wall teams hit with their HR tools. One IT lead at a software company we talked to told us that even with their HR system in place, what they still needed was "programmatic onboarding, offboarding, and Shadow IT," all of it still handled by hand.

Why teams add a dedicated access management tool on top of Personio

From conversations with our own customers, ~50 employees is the point where a team starts to feel like SaaS account provisioning is eating up considerable time. You'll find offboarded employees still have access to tools. There isn't a central place where you can clearly see "who has access to what". And you lose track of DMs from employees requesting access.

Just Appraised, a 133-person govtech company, hit this as it scaled (hear how Just Appraised handles it):

"People just reached out on Slack to someone that had access and could give you access, and we did not track that."

Harald Prokop, CTO, Just Appraised

A dedicated tool takes Personio's joiner and leaver events and turns them into access across 400+ apps, and AccessOwl publishes its full integrations list so you can check your stack against it before you commit.

Approach 2 - Automating SaaS access with Personio + AccessOwl

AccessOwl layers on top of Personio to handle access management for SaaS onboarding, offboarding, and access controls.

The stack most teams actually want is straightforward: your HRIS (here Personio), your IdP (Google Workspace or Microsoft Entra), and your third-party apps all stay in sync. Access should follow templates rather than someone creating accounts and setting permissions for each new hire. Who has access to what, along with access requests, approvals, and remediations, should be logged for access controls instead of scattered across tickets and spreadsheets.

AccessOwl is the layer that does that:

• A start or end date in Personio triggers the whole workflow.

• Access templates are matched to HR attributes (role, team, department, entity) and can be tweaked per person.

• Requests and approvals happen in Slack or the dashboard, and employees can self-serve.

• Onboarding drops to minutes, and offboarding can be one click or fully hands-off.

• Every action is logged as it happens, so access reviews become evidence you already have.

• You get one place to see who has access to what, including apps outside SSO or SCIM, like internal tools.

• Shadow IT that your HRIS and IdP never see gets surfaced.

What onboarding and offboarding looks like with Personio + AccessOwl

Onboarding, start to finish:

1. Personio says a finance hire starts Monday.

2. AccessOwl loads the access template: the accounting suite, the expense tool, and the finance Slack channels.

3. The relevant managers approve with one click in Slack (or another channel).

4. AccessOwl provisions each app through its own connected integration, so no one on your team opens an admin console. Every action is logged for audit evidence later.

Offboarding runs the same way in reverse. On the termination date in Personio, AccessOwl removes the person's licenses across their apps and reassigns their owned assets to their manager. It also runs a free Shadow IT scan that catches apps your IT team may not have known those employees signed up for, including free accounts or accounts with a username and password that sit outside SSO. That completeness is the point, because leftover access is where risk concentrates, and the cost of getting it wrong is real. The 2025 Cost of a Data Breach Report by IBM put the global average breach at USD 4.44 million (IBM, 2025).

The security payoff is concrete. Viafintech, a 90-person fintech, reduced the cases of former employees keeping access after they left to zero once it automated with AccessOwl, and its access process now runs in under a minute (Viafintech customer story).

What access review compliance looks like with Personio + AccessOwl

Because every grant, approval, and removal is logged, an access review for SOC 2 or ISO 27001 becomes a report you pull, not a spreadsheet you build. Instead of exporting a user list from each app, screenshotting the ones with no export, and pasting it all together, you have one record of who has access to what and how they got it. In practice that takes a review from around 2 hours per app down to about 10 minutes per app (Benefits of an Access Review Automation Tool).

How AccessOwl is different from Personio's native onboarding

The core difference is simple: Personio reminds a person to create the account, or deactivates the two directories it can reach. AccessOwl creates and removes access across your whole stack, with no checklist handed off to a human in the middle.

It provisions across 400+ apps without requiring SCIM or SAML, including the long tail of tools that hide provisioning behind an enterprise plan. What makes that work well for SMBs is how it connects: instead of relying on SCIM or SAML, AccessOwl works through admin-level service accounts and browser-based automation. It works at the permission level, not just account creation, so a role change updates what someone can do and not only whether an account exists. It surfaces Shadow IT, and it lets you customize a template per person.

AccessOwl does not replace your IdP or handle logins, passwords, or multi-factor authentication, and it does not manage devices. It sits on top of the Google Workspace or Microsoft Entra you already run and automates the access lifecycle, keeping your HRIS, your IdP, and your apps in sync.

How AccessOwl integrates with Personio (and Google Workspace or Microsoft Entra)

Personio stays your source of truth for joiners and leavers. AccessOwl reads those events and works alongside your existing Google Workspace or Microsoft Entra, and Okta too if you run it, rather than replacing any of them. AccessOwl has native integrations with Google Workspace, Microsoft 365, and Okta, and it is listed on Personio's own Marketplace.

Who this is best for

AccessOwl plus Personio fits a growing team (30+ people) running Personio, with a mix of third-party SaaS apps. You may have a small IT team owning device and software provisioning, or this might sit with a non-technical operations person.

Approach 3 - Managing SaaS accounts with Personio + DIY automation

Another route teams on Personio can take is to layer do-it-yourself automation on top of Personio. If you have technical people on your team, they might own this: tickets in Jira or Linear, spreadsheets, Zapier or Make on Personio events, or scripts against Personio's API (which itself needs the Pro plan). Microsoft shops often lean on PowerShell, Google shops on GAM (Google Apps Manager), wiring the APIs themselves.

To be fair, under roughly 30 people or 5 third-party apps, with someone technical who owns it, this is genuinely workable.

Where it breaks as you grow:

• No audit trail when a review comes around.

• Missed offboarding, the scary one, when a script does not cover an app.

• Shadow IT stays invisible.

• Brittle maintenance every time an app changes its API.

• No approvals and no self-serve.

• Key-person risk when the one person who understood the scripts leaves.

Which approach is right for you?

The right approach depends mostly on your headcount and how many apps you run. As a rough guide:

FAQs

How do I automate onboarding with Personio without manually creating software accounts and adjusting permissions?

Connect Personio to a lifecycle tool that turns the start date into access. With AccessOwl, Personio signals the new hire, a template based on their role loads the right apps and permission levels, the manager approves in Slack, and AccessOwl provisions each app for you. Because templates carry permissions and not just accounts, you are not going back in to set roles by hand.

Does Personio offer features to automate provisioning of SaaS apps to automate onboarding and offboarding?

In part. Personio automates the HR side (the employee record, e-signatures, and onboarding and offboarding workflows with reminders), and it can create or deactivate the account in Google Workspace and Microsoft Entra, or hand a joiner or leaver to your IdP for the apps that IdP already covers. What it does not do is provision the rest of your SaaS stack itself. To automate that, you connect a dedicated tool. AccessOwl reads Personio's start and end dates and provisions and deprovisions across 400+ apps, without requiring SCIM or SAML.

If I'm using Personio, why use AccessOwl over Okta?

Okta Workforce Identity Cloud is the right call for some teams: large or regulated companies with a dedicated identity team and a multi-IdP setup get real value from its depth. For a growing company on Personio, it is usually more platform than you need, and it carries the SSO tax, where each app is upgraded to an enterprise tier just to connect. If you already run Okta, AccessOwl layers on top of it and adds app coverage and lifecycle automation without ripping anything out. If you have not rolled out Okta yet, AccessOwl gives you the onboarding, offboarding, and access control you were after for a fraction of the cost, live in days rather than a months-long rollout.

Can Personio automatically create and delete SaaS accounts in Google Workspace, Microsoft 365, or Slack?

Partly. Personio can create and deactivate accounts in Google Workspace and Microsoft Entra, but the sync runs one way, from Personio outward, and it stops at those two directories. It does not reach Slack or the rest of your apps, and deactivating the Entra account revokes access rather than deleting the mailbox. Provisioning to everything else is manual, and switching it on app by app usually means paying for each one's enterprise tier. AccessOwl provisions across 400+ apps without requiring SCIM.

Our team uses Personio, how do I make sure all app access is revoked when an employee leaves?

Personio flags the departure and can deactivate the Google Workspace or Entra account, but it does not remove access across your third-party stack. AccessOwl uses the termination date in Personio to remove licenses across every connected app and reassign owned assets to the manager, and it surfaces Shadow IT accounts your HRIS never saw, so offboarding is complete and logged. You can see the shape of a full process in our offboarding automation guide.

What are the best tools that integrate with Personio to provision accounts automatically for onboarding and offboarding?

For automatic provisioning and deprovisioning specifically, you want a tool that turns Personio's start and end dates into action across your whole app list. AccessOwl does this on top of Personio, is listed on Personio's Marketplace, and reaches apps outside SSO and SCIM.

How do I manage access for someone who isn't in Personio yet, like a contractor?

It happens: a contractor sits in a different system, or a new hire needs access before they are added to Personio. Personio can only act on people in its own records, so anyone outside it is invisible to its workflows. With AccessOwl you can add that person directly and provision their access from the same templates, then let Personio take over once they land in the HR record. Access is still requested, approved, and logged the same way.