Skip to main content

Work Management use case

Role change and transfer automation

Role change automation adjusts an employee's access, equipment and approvals when they move to a new job, department or location. Kinetic reads the change in the HR system, compares current access with what the new role needs, removes what no longer fits and grants what does, with both managers signing off and every change recorded.

Book a working session

Starts from the job change in Workday or SuccessFactors, and updates Okta, Active Directory and connected applications.

How a transfer updates access

  1. Experience layer

    A change summary for the old and new manager showing access to add, access to remove and items waiting on a decision, plus a request form for changes HR has not recorded yet.

  2. Workflow layer

    Starts from the HR change, builds an add-and-remove list from current access, routes it to both managers at once, then applies removals and additions in the right order across each system.

  3. Integration layer

    Picks up job, department and manager changes from Workday or SuccessFactors, reads current access from Active Directory, Okta and connected applications, and writes each addition and removal back to them.

    • Workday
    • SAP SuccessFactors
    • Okta
    • Active Directory
    • ServiceNow

AI in role change and transfer automation

AI drafts the add-and-remove list, but it doesn't remove or grant anything. Both managers review the list, and anything outside the role template waits for a person.

What AI does

  • Compares current access with the new role and drafts the change list
  • Flags access the employee would keep that the new role does not need
  • Summarizes the change for each approving manager

Decided by people, not by AI

  • Keeping old access through a handover period
  • Additions the new role does not include by default
  • Changes to clearance-dependent systems

The access nobody removes

When a payroll specialist transfers to procurement, HR updates Workday and nothing else happens. Her new manager files tickets for the procurement tools. Nobody files a ticket to remove payroll access, because it is nobody’s job to notice it is still there. Two transfers later she can approve invoices and edit pay rates, and the first person to spot it is an auditor running a segregation-of-duties check.

Missing access gets reported within a day, because the employee can’t do their work. Excess access can sit unnoticed for years. Transfers deserve the same discipline as hires and departures, and they rarely get it.

How a transfer runs

  1. The HR record changes. Workday or SuccessFactors records a new job, department, location or manager, and Kinetic picks up the event. When HR is running behind, a manager can start the change from a form.
  2. Kinetic builds a change list. It reads current access from Active Directory, Okta and the connected applications and compares it with the standard access for the new role. The list has three parts: add, remove, and needs a decision.
  3. Both managers review at once. The old manager confirms removals and can keep an item through a handover, with an end date. The new manager approves additions.
  4. Changes go out in order. Removals that would conflict with the new access run first, then additions. A desk or equipment move goes to facilities and procurement on its own branch so it doesn’t hold up access.
  5. The employee gets a summary of what was added, what was removed and who to ask about anything missing.
  6. Every change is tied to the HR event that started it, which is the link an access review needs.

What makes this work

The workflow is only as good as the role definitions behind it, and most organizations don’t have a clean access template for every job code. That’s normal. The “needs a decision” list catches whatever the templates miss, and a person decides. After a few months of those decisions, the templates are much better than anything written up front.

Role changes share most of their plumbing with access requests and employee offboarding: the same connections to identity and HR systems, the same approvals. Building one gets you most of the way to the other two.

What you can build next

Movers sit between joiners and leavers, and the three workflows share most of their connections.

Questions about role change and transfer automation

Answered by Kinetic Data. Last updated .

  • How does Kinetic stop employees from keeping access after a move?

    The workflow lists the access tied to the old role and removes it unless a person approves keeping it for a set period. That approval carries an end date, so leftover access does not pile up across transfers.

  • Do we need a complete access template for every role before we start?

    No. Start with the roles that move most often. Anything Kinetic cannot classify lands in a 'needs a decision' list for the managers, and those decisions become the templates over time.

  • What if the effective date of the move changes?

    The workflow follows the effective date in the HR record. If HR moves the date, the pending steps move with it. You can also allow the new access to start a few days early for overlap when both managers agree.

  • Which systems does a role change touch?

    Typically the HR system that records the move, Active Directory and Okta for groups and applications, and the applications themselves where roles are assigned inside them. Equipment or desk changes go to ServiceNow or your facilities tool on a separate branch.

Bring one process. Leave with a plan to build it.

Two hours with our team, at no cost. Bring one process that crosses your systems. We map it with you, show what Kinetic would build, and send you a written plan afterward.

Book a working session