Employee lifecycle: Mover

TL;DR

Joiner–mover–leaver is one of the key product verticals for the identity industry, and the middle child is overlooked by almost everyone. This means those who change titles or teams keep every access they had and quietly collect more.

We saw a real opportunity in both upselling into existing accounts, and creating an edge in deals that come from having a complete JML vertical. We shipped the mover flow while building the workflow primitive that the rest of the platform now runs on.

Challenges

In discovery I mapped six distinct mover problems across roughly fifteen enterprise accounts. They concentrated into three challenges:

• Fragmented systems - Admins grant access through some combination of IdP, ITSM and bespoke automation, with no single source of truth
• Employee friction - Aggressive automation revokes access prematurely, costing productivity, and admins scramble to fix the gaps until the sprawl is unmanageable
• High cost of ownership - Rulesets and policies live in several tools at once, and nobody has time to revisit them

All of these challenges boil down to two tangible outcomes:

• Access that should arrive doesn't - People wait for weeks for new access
• Access that should be revoked doesn't - When someone changes roles, sensitive permissions need to be revoked immediately but more often than not, people only notice it during an Access Review

Key bets

01Policies are the source of truth

The early prototype let admins manually edit a per-employee mover plan: see what's changing, adjust it, approve it. We maximized for what we thought the user needed the most - the flexibility to change access ad-hoc.

Four design partners reframed the product for us. Editing by hand doesn't survive enterprise volume - it undercuts the authority of the Access Policy and puts an admin in front of every person in transition. What they were really buying was a long-term model, one they could trust to still hold in three years.

Our mental model changed from "policies can be used as a starting point, and admins patch the rest by hand" to "policies are the source of truth, and exceptions become traceable ad-hoc requests against them".

02Our differentiator is time to value

Almost every customer was already handling movers through Okta or Entra rules, which apply changes the instant an attribute flips. That is too aggressive: it cuts access people still need, admins scramble to patch the gap, and eventually those patches become the sprawl.

"How do we make workflows impactful and scalable without it being another burden for admins?"

Visual draw-your-own-flow builders (Make, Tines, Okta) were the obvious reference and the wrong fit. Our admins didn't want a canvas to draw on; they wanted defaults that covered the common case and a short path to value. So I took a deliberate position: usability and speed first, arbitrary composability second.

03Invest in a workflow primitive, not a third bespoke feature

Mover needed custom workflows. Lumos already had two separate, bespoke workflow patterns built for earlier features - each fine in isolation, neither reusable. Adding a third would have been the cheapest thing to do that month and the most expensive thing to own.

I saw the value in building a reusable primitive. I mapped every possible step parameter - native actions, integration actions, expression language, and stress-tested the component against real customer examples before fixing its anatomy.

That work paid off immediately. Since we'd already solidified our platform patterns for Workflow Builder and Workflow Record, we just needed to apply those to this as the first use case, without building bespoke UI from scratch.

Two bespoke patterns, each built for one feature

One step, defined once and reusable everywhere

04The shape of a mover flow

The biggest product and design decision was how to conceptualise a mover flow at all. There were two ways to model it.

• Option 1 - Lumos looks at every piece of access a user has and sorts it into three mini-workflows: grant, revoke and review.
• Option 2 - Lumos focuses on policy-driven access, and treats mini access reviews as a second product entirely.

We went with the second, for three reasons:

• Access can be granted and revoked with no manual step in between
• We get to be more opinionated - everyone should follow access policies, and only more mature customers need recertification, which is the review piece
• A smaller scope meant we could displace Okta and Entra sooner

Future vision

As we gradually rolled this out, the happy path got the attention it deserved. But a major gap became concrete when a single upstream issue produced hundreds of onboarding errors for one large customer: the product could tell you that hundreds of things had failed, but not that they were all the same thing failing.

That incident is what convinced me lifecycle management has to get proactive rather than merely observable - detect the pattern, summarise the problem, propose the fix. I explored what that could look like as a future direction, and I think it's the right next bet.

Impact

"Movers ability to delay access removal in movers is a key differentiator for Lumos which is not supported by Okta." - an enterprise design partner, who added that the delay "effectively buys weeks of time to respond to changes which they don't have now."

Mover completed the JML vertical and turned Lumos into a full IGA solution. Workflow and workflow record became reusable platform primitives that now power onboarding, offboarding, general access provisioning and removal across the product.

• Retained an enterprise compliance-software customer who was on the way out; carried a Fortune 100 airline through a POC
• Mover became the retention layer, not just the completed vertical: its revocation edge cases now sit under "defence" in the following year's strategy

More on the thinking behind this, on the Lumos blog: The Future of Lifecycle Management Is Unified, Intelligent, and Human.