To create software accounts for new hires automatically, connect your HR system to a tool that creates the accounts in each app when someone is added. For most growing teams, that's a lightweight IAM tool like AccessOwl, which works without SCIM. Larger companies with a dedicated IT team often use an identity provider like Okta with SCIM instead.

The provisioning flow in one line: a new hire is added in the HR system, their role template picks the apps, accounts are created in each app, anything sensitive goes to an approver in Slack, and every login is ready before day one.

What creating accounts by hand looks like

• A late heads-up: whoever sets up accounts hears about the new hire a few days before the start date, sometimes on the day itself.

• One app at a time: someone logs into each app's admin page, sends an invite and picks a role.

• Copied access: permissions get copied from a teammate in the same role because it's faster than checking.

• Chasing app admins: apps owned by other teams wait until their admin has time to send the invite.

• A slow first week: the new hire gets a Google or Microsoft account on day one, and the rest trickles in.

Based on conversations with 450+ IT buyers who evaluated an access management solution, onboarding one new hire by hand takes about 1.5 hours. Laptop setup comes on top. The person doing it is often not in IT. At growing companies, it usually lands on HR, Ops or a founder.

Motion had no IT team when Ethan Yu, its cofounder and COO, was setting up every new hire himself:

"I hired all our employees, and I had to provision all their accounts, set up their onboarding, and make sure that their experience ramping up in the company was a smooth one."

Ethan Yu, Cofounder & COO, Motion Case Study

Step 1: List the apps new hires need and who manages each one

Start with a list of the apps your company uses beyond Google Workspace or Microsoft 365. For each one, write down who can create accounts in it. That's usually the manager of the team that uses the app, not IT.

The list tends to be longer than people expect. A new full-time employee gets access to a median of 9 apps beyond their main workspace. Access to those 9 apps sits with a median of 5 different app admins.

If you don't have a list yet, start with the apps connected to your Google or Microsoft workspace and the software on your company card statements.

Step 2: Automate account creation (provisioning)

Provisioning means creating a new hire's accounts and permissions in each app automatically. This is where you pick a tool, and the right one depends more on your company than on your apps.

Most teams choose one of three approaches:

• A lightweight IAM tool: like AccessOwl. It creates accounts across your apps when your HR system adds a new hire. It connects through integration accounts, so no SCIM is needed.

• An identity provider with SCIM: like Okta, JumpCloud or Microsoft Entra ID. SCIM is a standard that lets the identity provider create and remove accounts inside each app.

• Your HR system's IT add-on: like Rippling IT or Deel IT. It creates accounts in the apps from its own catalog.

The SCIM approach works well for enterprise companies. If most of your apps are already on enterprise plans and a dedicated IT team runs your identity stack, an identity provider can handle provisioning. Growing teams usually run into two problems with it. Many apps only offer SCIM on their enterprise tier, which is known as the SSO tax. An identity provider also needs someone to run it, and most growing teams don't have that person.

Step 3: Make the HR record the trigger

Account creation should start the moment a new hire is added to your HR system, not when someone remembers to post in Slack. The HR record already holds what the tool needs: name, start date, job title, department and manager. Fill in job title and department the same way every time, because they decide which apps the new hire gets. Our guides for Deel, Personio and BambooHR cover what each HR system can do on its own.

Step 4: Set up access templates for zero-touch onboarding

An access template is the list of apps and access levels for a role. With templates in place, onboarding runs without anyone touching it. The HR record names the role, the template picks the apps, and your provisioning tool creates the accounts before day one. That's zero-touch onboarding.

Keep templates simple. Put the apps everyone gets in one template, then add one per team.

Write down the access level and not just the app name. "Admin" and "Member" in the same app are very different. If new hires in a role keep needing changes after onboarding, update the template instead of fixing each person by hand.

Step 5: Put sensitive apps behind approval

Only part of your app list belongs in a zero-touch template. Those are the apps everyone in a role needs on day one, like email, Slack and the team's main tool. Most other apps should get an approval before the account is created:

• Paid seats: so whoever owns the budget sees the cost first.

• Admin or owner roles: in any app.

• Sensitive data: payroll, finance tools, production systems and customer data.

Approvals are where manual onboarding slows down. Someone has to work out who owns the app, message them and wait. A SaaS access management tool like AccessOwl routes each request to the right manager in Slack, and they approve it in one click.

Extra sensitive apps can go through a chain of approvals. Access to GitHub, for example, might need the engineering manager first and then a security lead.

Step 6: Bring all apps under central management

A common mistake is automating only the day-one essentials. An identity provider or HR add-on creates the Google Workspace and Slack accounts. Everything else still goes through the app admins, so someone ends up chasing five managers for the remaining invites. Robert Pötzsch, office manager at FinCompare, saw this before they moved to a central tool:

"In the end manually delegating between all application admins wasn't feasible anymore."

Robert Pötzsch, Office Manager, FinCompare Case Study

Getting every app into one place depends on the app admins agreeing to it. A SaaS access management tool like AccessOwl gives them a good reason to. Once their app is connected, they no longer handle it day to day:

• Accounts: created and removed automatically, based on the templates.

• A live inventory: of who has access to what, kept up to date without a spreadsheet.

• A log of every permission change: ready when an auditor asks for it.

These are all jobs managers no longer have to do themselves. That makes them much more willing to hand their apps over.

Step 7: Give employees an easy path to request other tools

Templates cover what a role needs on day one. They won't cover everything. A designer might need a stock photo account in week three. An engineer might need access to a new monitoring tool.

Give employees one place to ask, ideally in Slack, where the request goes straight to the app's approver. Without it, requests end up in direct messages to whoever seems to know. Khalifah Alsadah, product manager at Sary, saw the difference:

"Since we started using AccessOwl I haven't received a single direct message to request access to tools."

Khalifah Alsadah, Product Manager, Sary Case Study

Requests also show you when a template is out of date. If every new hire in a role asks for the same app, add it to that role's template.

Comparing 4 Methods to Automate Tool Access for New Hires

Each method can handle part of the steps above. They differ in which apps they reach and who has to run them.

Lightweight IAM tool (AccessOwl)

A lightweight IAM tool focuses on the everyday access work: creating accounts, removing them and handling requests. It leaves out the heavier identity setup an enterprise suite brings. AccessOwl is built this way. It connects to 500+ apps through integration accounts, so no SCIM is needed and you don't have to move apps to enterprise plans.

• HRIS-triggered onboarding: adding a new hire in your HR system starts account creation. Nobody has to file a ticket or post in Slack.

• Access templates: each role gets its own app list, so new hires get the right apps without anyone copying a teammate's access.

• Automated provisioning: accounts and permissions are created in each app, not handed out as tasks for app admins.

• Easy software access requests: employees ask for extra apps in Slack, and the app owner approves them there.

• Audit-ready records: a live inventory of who has access to what, with every change logged.

Harald Prokop, CTO at Just Appraised, explained why it worked for them:

"AccessOwl is lightweight, very easy on the users, and it lets you have a mature process on access without all the downsides of the typical mature process."

Harald Prokop, CTO, Just Appraised Case Study

AccessOwl is built for teams of 30 to 1,000 people. It runs alongside Google Workspace, Microsoft 365 or Okta, so you keep what you already use for sign-in. Pricing is public, and you can test it with your own HR system in a 7-day free trial.

Identity provider with SCIM

An identity provider is the system your team signs in with, like Okta, JumpCloud, Microsoft Entra ID or Google Workspace. With SCIM, it can also create and remove accounts in connected apps.

Works well for: companies with most apps on enterprise plans and a dedicated IT team to run it.

Where it stops:

• Apps without SCIM: the identity provider can't create those accounts, so someone still does them by hand.

• SCIM on enterprise plans: many apps only offer SCIM on their top tier. Connecting them means paying the SSO tax for each one.

• Built for a full identity setup: Okta and JumpCloud are designed to sit at the center of a company's identity and security stack, and they need someone to run them.

• More than growing teams need: many only want the day-to-day account work off their plate. See what Okta costs for a small team.

HR system IT add-on

If your HR platform sells an IT module, like Rippling IT or Deel IT, it's a natural first thing to check. The trigger and the employee data already live there.

Works well for: the apps in its catalog, with no extra system to connect.

Where it stops: apps outside the catalog stay manual. Your account setup is also tied to that HR vendor. If you switch HR systems, you rebuild it.

DIY connectors

With Zapier, Make or a script, you can watch for new hires in your HR system and call each app's API to create the account.

Works well for: a handful of apps, when someone technical owns the setup.

Where it stops: each app is a separate flow to build. Many apps don't let you create users through their API, or only on higher plans. When an app changes its API, the flow can break without anyone noticing. Often nobody finds out until a new hire is missing an account.

Every App Ready on Day One, with AccessOwl

AccessOwl starts onboarding from your HR system and creates accounts in 500+ apps, with no SCIM needed. New hires request extra apps in Slack, and the right person approves them there. Start a 7-day free trial and set up access for your next new hire.

FAQs

Can my HR system create app accounts on its own?

Some can, for a limited set of apps. HR platforms like Rippling and Deel sell IT add-ons that create accounts in the apps from their catalog. Most other HR systems pass the new hire's details to another tool, such as an identity provider or AccessOwl, which then creates the accounts.

Do I need Okta to automate account creation?

No. Okta is one option for apps that support SCIM. Google Workspace and Microsoft Entra ID can do the same for supported apps. AccessOwl creates accounts without SCIM and without an identity provider.

What if an app doesn't support SCIM?

Then an identity provider can't create the account. You can create it by hand, build a connector on the app's API if it has one, or use a tool that reaches the app another way. AccessOwl uses integration accounts for this, so no SCIM is needed.

Can I automate this without an IT team?

Yes. Most of the steps in this guide are decisions about apps and roles, and HR and Ops already know those well. Pick a tool someone on your team can run without writing code.

Is SSO the same as automatic account creation?

No. SSO lets people sign in with one login. It doesn't always create the account in the app, and it doesn't remove it when someone leaves. Some apps create an account the first time someone signs in through SSO. Many need SCIM or another tool for that.