Onboarding and offboarding with AI — from an employee list to reliable access management

Our company has a file of employees and a list of tools. There is Google Workspace: email, calendar, documents, and spreadsheets. There are also computers, phones, Google Cloud, GitHub, Jira, and other applications. When someone joins, their workstation and appropriate access must be prepared. When they leave, that access must be removed, equipment recovered, and any materials they leave behind dealt with.

Every one of these actions can be done. The difficult part is making sure the whole process is covered: who has to do what, in which system, by when, and how we will know it was actually done.

With AI—artificial intelligence—I have already done a small part of that work. In one conversation, I asked it to organise a list of accounts. I then indicated which entries should be listed for further handover. I made the selection, and the chat helped prepare a readable list. Preparing the list did not itself delete any accounts.

I want to develop this way of working: connect employee information with a tool catalogue, access rules, and confirmations of execution. Below, I describe an idea for such a process, not an account of deploying a full automation in my company. In the article on preparing a company for secure collaboration, I describe how assigning an owner, evidence, and a next step can help organise tasks.

Let us walk through it using Anna as an example. Anna, her roles, and every result below are fictional examples, prepared to show the process without disclosing employee data.

Two lists are a starting point. We still need rules

Here, onboarding means preparing someone to work, from equipment to access to the information they need. Offboarding means organising their departure, including removing access and handing over resources.

The fact that “Anna works in operations” does not yet say which Jira projects she should access. A list of applications does not settle that either. We need an approved role profile: the set of tools and permissions that follows from the role’s responsibilities. AI can help describe it, but it should not invent company rules for every new employee.

To start, I would organise four things in the existing spreadsheet or system:

A stable identifier helps link an employee record to their accounts even if their surname or address changes. Where a match is ambiguous, AI should flag the problem. A similar-sounding surname is not enough to disable an account.

Likewise, a person being absent from a random export cannot by itself trigger offboarding. We need confirmed information about the change, its timing, and the right approver. An empty row may mean a data error.

Anna joins the team

In our example, Anna starts as an operations specialist. Her manager confirms the role and starting date. AI compares that information with the approved profile and prepares a plan:

“Not applicable” is a fully valid outcome here. The process should assess every catalogue item, but it should not create accounts in every tool. Copying a colleague’s permissions could copy their old exceptions too.

The plan goes for approval. The manager confirms the business need, and the administrator or system owner checks the scope and method of execution. Approval should cover a specific person, organisation, resources, and permissions. A whole clearly described package can be approved; every click does not need a separate decision.

Once approved, available integrations perform the indicated operations. Where there is no integration, or it does not support a given action, a task is created for an administrator. Issuing a laptop remains a physical action, even if AI prepares the request perfectly.

What AI does, what an integration does, and what a person does

I would keep this division throughout the process:

AI may use integrations, but the sentence “the account was created” is not evidence on its own. The report should identify the account, the operation result, and a second check of its state in the system. Manual work needs an administrator’s confirmation; equipment needs confirmation of receipt or return.

Implementation must also respect existing account management. If the company already has a central identity directory and synchronisation, the new process should use them. Making parallel manual changes to the same accounts can create inconsistent states. The availability of automation needs checking for the services used, their configuration, and the integration’s permissions.

Anna changes role. What has to be removed?

After some time, Anna moves to the analytics and automation team. She already has an account, computer, and phone. We do not start onboarding from scratch. We compare current access with the needs of the new role.

In the example, the plan looks like this:

• keep the Google Workspace account and assigned equipment;
• add access to new-team materials and the relevant Jira project;
• remove memberships and permissions connected only with old duties;
• grant approved access to the specified GitHub repository and required GCP resources;
• set an expiry date for any transitional access needed for handover.

GCP should not be described with one field saying “has access.” We need to know which resources and which permissions. In Google Cloud, rights can be inherited from higher levels: the organisation, folder, or project. Checking one place is therefore not enough to establish the full scope of access. The Google Cloud documentation on the access hierarchy explains this.

AI can prepare the difference: keep, add, remove, clarify. For exceptions, it gives the reason and a date for review. The administrator confirms that the new scope works and that unnecessary old access was actually removed.

This kind of review during a role change helps avoid a situation where someone accumulates access to successive teams for years and none of the earlier access ever disappears.

Anna leaves. Access and resources are two task lists

When someone leaves, we need a confirmed time, including the hour and time zone, and a current account list. AI compares the register with available system reads and identifies discrepancies. A system that was not checked receives the status “not confirmed.”

In the example, Anna owns working documents and looks after a report automation. Simply disabling her sign-in does not answer who will take over those duties.

The plan therefore separates two things. First, removing a person’s access: accounts, memberships, active sessions, and related credentials—the data that permits authentication. Second, preserving needed resources: documents, reports, tasks, and automations, with a named new owner.

For a planned departure, we prepare the handover beforehand. It must not, however, delay removal of access at the approved time. If the situation requires immediate disablement, authorised administrators do the remaining clean-up afterwards.

Several differences between tools matter in practice:

• Google Workspace: suspending an account blocks access to services while retaining data. It does not necessarily end every ongoing session: Google points out an exception for an already-started Google Chat conversation. Sessions and credentials therefore need separate checking. Deleting an account has different consequences and requires deciding beforehand what to transfer or preserve. Data transfer is not one operation covering every resource. See Google’s rules on suspension and deleting a user.
• GitHub: removing membership in a company organisation is different from deleting an employee’s personal account. It also does not remove their local copies of repositories. The instructions for removing an organisation member describe this.
• Jira and Atlassian: removing access to the company environment does not have to mean disabling the entire Atlassian account. The outcome depends, among other things, on whether the company manages that account. The distinction is described in the instructions for removing access and deactivating a managed account.

I would not assume that disabling email automatically closes every other route of access. The plan should cover each system in use and credentials linked to the employee, including any additional administrator account. An administrator checks their revocation and effect according to the tool’s configuration.

Anna’s report requires separate attention. Which account runs the automation? Who will maintain it? Must the authentication method be changed and a test run performed? Technical accounts used by programs should be distinguished from employee accounts. The fact that Anna prepared a process does not mean its technical account should be deleted. Her ability to use it must be removed, though, and the fate of credentials to which she had access must be decided.

There are also the phone and computer: confirmation of return, settlement of the number, and securing company data under the agreed procedure. Handing a device, number, or mailbox contents to another person should not happen automatically. It requires a named recipient and approved scope; private data must not be transferred with company materials.

The report should show state, not good intentions

An example report for Anna’s offboarding might look like this. It remains an illustration of the process, not the result of operations in my company:

In a real report, each item should have an owner, deadline, operation or request identifier, and verification evidence. Access data and passwords are not such evidence and should not go in the report.

I would distinguish these statuses: proposed, approved, in progress, completed, confirmed, error, missing data. A failed action remains visible. Retrying after an error should first check the current state, so it does not create a second account or repeat a completed operation.

A complete set of green rows matters only for the scope that was checked. If the catalogue omits a tool or a system read failed, the report must show that gap. A responsible person closes offboarding after checking the scope and resolving exceptions, not AI merely after it sends the last request.

Where I would start in my own work

I would limit the first version to preparing a plan and comparing it with an administrator’s work. One role, one fictional person, and a few tools. This makes it possible to check missing data and mistaken assumptions before connecting operations that change permissions.

For the trial, prepare an approved role profile and anonymised data. Process real employee data only in an environment approved by the company, and only to the extent needed for the task. Do not paste passwords, keys, or tokens into the prompt.

Help prepare an access-management plan for one person.
At this stage, do not perform anything or send any requests.

Event: [joining / role change / departure].
Person: [test identifier].
Change time: [date, time, time zone].
Input data: [approved role profile, tool catalogue,
current accounts, permissions, and equipment, and the date they were checked].

Compare the current state with the target state. Indicate: keep, add,
remove, hand over, or needs clarification.
Do not invent missing permissions or account matches.

For every item, state:
- the person and the relevant system, organisation, project, or device;
- the exact action and its justification;
- who approves, who performs it, and by when;
- whether an available integration or an administrator can perform it;
- how we will check the outcome and where we will record confirmation.

Separate access removal from account deletion and data preservation.
Include documents, automations, and technical accounts to check.
List every gap, ambiguity, and unchecked system.
Clearly distinguish proposed results from completed and confirmed ones.

Only after such a trial would I select one well-described operation to automate, with approval of the scope and a check of the result. I would add subsequent systems once we know what each integration performs and what it cannot confirm.

Today I have a concrete starting point: using AI to organise the list of accounts I identified. The next step is to bring that list to a state in which I can see a responsible person, completed action, and confirmation for every item. Then the question “did we remove all access?” has an answer based on checking, with exceptions clearly shown.