# How to Automate Tool Access for New Hires

> Published 2026-11-10
> Source: https://viktor.com/blog/automate-new-hire-tool-access

An AI agent can automate tool access for new hires by turning a signed offer into a finished access checklist: it reads the role, looks up which apps and permission levels that role gets, creates or requests each account, sends the invites, records what was granted and reminds the hire to finish setup. A person approves admin-level access and anything outside the role template. When the employee leaves, the same record drives offboarding, so every account is removed, not just the ones someone remembers. This guide shows how to set up role-based access templates, which steps to automate, where approvals belong and how to handle the apps that have no single sign-on.

The provisioning flow in one line: trigger (offer signed in the HR system), look up the role template, create accounts through SSO or each app’s admin, set permissions, send invites and a welcome checklist, log everything in an access register, then reverse it all on the last day.

## Why manual provisioning breaks

In a growing company, new-hire access usually lives in someone’s head or an old checklist. The results are familiar:

- The hire spends their first morning waiting for logins.
- Different people in the same role get different access.
- Admin rights get handed out “just to save time”.
- Nobody has a full list of what each person can reach.
- Leavers keep access to tools that are not behind single sign-on.

Each of these is a security problem as much as a productivity one.

## Step 1: Build role-based access templates

List the roles you hire for and, for each, the apps and permission level they need on day one. Keep it in a sheet the operations or IT owner maintains:

```json:object
{
  "_key": "k30",
  "_type": "table",
  "rows": [
    {
      "_key": "k25",
      "_type": "tableRow",
      "cells": [
        "Role",
        "Day-one apps",
        "Permission level",
        "Needs approval"
      ]
    },
    {
      "_key": "k26",
      "_type": "tableRow",
      "cells": [
        "Account executive",
        "Google Workspace, Slack, HubSpot, Gong, Notion",
        "Standard user; HubSpot sales seat",
        "HubSpot paid seat"
      ]
    },
    {
      "_key": "k27",
      "_type": "tableRow",
      "cells": [
        "Engineer",
        "Google Workspace, Slack, GitHub, Linear, AWS, Notion",
        "GitHub org member; AWS read-only",
        "AWS write access"
      ]
    },
    {
      "_key": "k28",
      "_type": "tableRow",
      "cells": [
        "Designer",
        "Google Workspace, Slack, Figma, Linear, Notion",
        "Figma editor",
        "Figma paid seat"
      ]
    },
    {
      "_key": "k29",
      "_type": "tableRow",
      "cells": [
        "Finance",
        "Google Workspace, Slack, QuickBooks, Ramp, Notion",
        "Accountant role",
        "Any admin role"
      ]
    }
  ]
}
```

Templates keep access consistent and make exceptions visible.

## Step 2: Choose the trigger

Provisioning should start from one source of truth, usually the HR or ATS system (BambooHR, HiBob, Rippling, Personio, Ashby, Greenhouse). The trigger is a status change such as “offer accepted” with the start date, role, manager and location. Working from a Slack request or an email invites mistakes.

## Step 3: Automate the account creation

Three paths, from best to fallback:

1. **Single sign-on with SCIM** (Okta, Google Workspace, Microsoft Entra ID). Assign the user to the role’s group and the identity provider creates the accounts in connected apps. This is the cleanest path for the apps that support it.
2. **App admin APIs.** For apps without SCIM, create the user or send the invite through the app’s admin API or integration.
3. **Admin console tasks.** For the rest, the automation prepares the exact steps and asks the app owner to click invite, then confirms it happened.

## Step 4: Put approvals where risk is

Automate standard access without approval; it is already agreed in the template. Require a named approver for:

- Admin or owner roles in any app.
- Paid seats beyond the budgeted number.
- Access to production systems, customer data or finance tools outside the template.
- Anything requested for a contractor.

The approval request should say who, what, why and for how long, with one-click approve or decline.

## Step 5: Welcome the hire with a checklist

On day one, the hire gets one message listing each app, the link to sign in, what to set up (two-factor authentication, profile, notification settings) and who to ask for help. The automation follows up on anything still pending at the end of day two.

## Step 6: Keep an access register

Every grant is logged: person, app, permission, date, who approved. This register is what auditors ask for and what makes offboarding complete. Review it quarterly and remove access nobody has used for 90 days.

## Step 7: Offboard from the same record

On the last day, the same flow runs in reverse: suspend the identity provider account, remove app seats, transfer file and document ownership to the manager, revoke API tokens and shared passwords, and confirm each step in the register. Apps outside single sign-on are where leavers keep access, so the register matters most here. For more on keeping access tight, see the [security checklist for AI tool access](https://viktor.com/blog/security-checklist-for-ai-tool-access).

## Tools for automating new-hire tool access

```json:object
{
  "_key": "k87",
  "_type": "table",
  "rows": [
    {
      "_key": "k81",
      "_type": "tableRow",
      "cells": [
        "Option",
        "Best for",
        "Limits"
      ]
    },
    {
      "_key": "k82",
      "_type": "tableRow",
      "cells": [
        "Viktor (AI employee)",
        "Running the whole checklist across HR, identity, SaaS admin and Slack, including apps without SCIM, with approvals in the channel",
        "Needs admin connections and a clear role template"
      ]
    },
    {
      "_key": "k83",
      "_type": "tableRow",
      "cells": [
        "Identity providers (Okta, Entra ID, Google Workspace)",
        "SSO and SCIM provisioning for supported apps",
        "Many SaaS tools charge extra for SCIM or lack it"
      ]
    },
    {
      "_key": "k84",
      "_type": "tableRow",
      "cells": [
        "HR and IT platforms (Rippling, BambooHR, HiBob)",
        "Triggers and built-in app provisioning",
        "Coverage limited to their app catalog"
      ]
    },
    {
      "_key": "k85",
      "_type": "tableRow",
      "cells": [
        "SaaS management (BetterCloud, Zluri)",
        "Discovery and lifecycle at larger companies",
        "Cost and setup time"
      ]
    },
    {
      "_key": "k86",
      "_type": "tableRow",
      "cells": [
        "Workflow automation (Zapier, Make)",
        "Simple “new hire, create account” flows",
        "Each app is a separate flow to maintain"
      ]
    }
  ]
}
```

Viktor is an [AI employee](https://viktor.com/ai-employee) who lives in Slack and Microsoft Teams and connects to 9,800+ tools, including Google Workspace, Microsoft 365, Okta, Slack, GitHub, HubSpot, Notion, BambooHR and Rippling. An operations lead can write: “When an offer is accepted in Ashby, set up the new hire’s accounts from the role template, ask me before any admin access, and send them the day-one checklist.” He does the steps, logs each grant and asks before anything outside the template. We told the story of one team doing this in [we onboarded a new hire without HR touching anything twice](https://viktor.com/blog/ai-onboarding-without-hr). Read [what an AI employee is](https://viktor.com/blog/what-is-an-ai-employee) for how he works.

## Common mistakes

- **Copying a teammate’s access.** It carries over years of extra permissions. Use templates.
- **No end date for temporary access.** Every exception should expire.
- **Forgetting shared accounts.** Rotate shared passwords when someone leaves.
- **Provisioning from chat requests.** Always start from the HR record.

## FAQ

### Can an AI agent provision SaaS accounts automatically?

Yes, for apps it can reach through single sign-on, SCIM or an admin API. For the rest it prepares the steps and asks the app owner to complete them, then checks they are done.

### What should need human approval?

Admin roles, extra paid seats, access to production or customer data, and anything outside the role template.

### How does this help with offboarding?

Because every grant is logged in one register, offboarding removes all access, including apps outside single sign-on.

### Do we need Okta to automate provisioning?

No, an identity provider helps, but an AI employee can work through each app’s admin integration and the HR system without one.

## Have every login ready on day one

Viktor works in Slack and Microsoft Teams, connects to 9,800+ tools and runs onboarding and offboarding checklists with approvals where they matter. [Start free with up to $100 in credits, no credit card](https://app.viktor.com/signup), and give him your next new hire.