People lifecycle
People lifecycle is where you decide what happens as people join, move and leave. Owlie places everyone in a lifecycle state from their HR data, such as Pre-hire, Active, Leaving or Terminated. Each state has a page that shows what people in it hold, what runs when someone enters or leaves it, and what runs on a date. You change behavior there, and every row is the real policy or reaction, so opening a row opens the object that runs.
Joining, moving and leaving aren't separate pages. Joining is a move into Active, leaving is a move into Terminated, and a move between teams is a change of someone's details while they are Active.
For example, Priya Raman's HR record says she starts on 3 November. Until then she is Pre-hire. At midnight on 3 November, in her time zone, she becomes Active and receives everything Active holds, such as Google Workspace and Slack. When her end date is 14 days away she becomes Leaving, and on her end date she becomes Terminated: her access is removed, except what you keep for a handover, and her open work moves to her manager.
The section is under People lifecycle in the admin rail.
How behavior attaches to a state
You can attach three kinds of behavior. Each is an ordinary Owlie object you can also open from Governance > Policies or People lifecycle > Automate > Reactions:
| Attach it to | What it means | What Owlie creates |
|---|---|---|
| A state | What people in the state hold, for as long as they are in it | A policy whose condition names the state |
| A move | Something that runs once, when someone enters or leaves the state | A reaction on that lifecycle transition |
| A date | Something that runs on a day counted from one of the person's dates | A reaction that runs on a date |
Access always follows the state. When Priya leaves Engineering for Design while Active, the policies for Engineering stop matching her and the ones for Design start, without anything to run. Reactions are for things that happen once, such as a welcome message or a notice to a manager.
How Owlie works out each person's state, and how to override it for one person, is in Lifecycle state and overrides.
Overview
People lifecycle > Overview shows where everyone is today:
- The state strip. Every state with the number of people in it now. Select a state to open its page. When people are in Unknown, it reads "needs mapping": their HR data matched no rule. The strip also draws the moves between states, and marks any move people made that the built-in model doesn't expect, with how many people made it.
- Transitions. The most recent moves: who moved, from which state to which, and when. A person whose first state was just set shows no state they came from.
- Terminated people holding access. How many terminated people still hold access, split into In a handover window (kept on purpose) and Outside every handover window (worth a look). Who holds access lists them, and Explain access opens the Access Explorer for one person.
- HR data. Each HR source with its next scheduled run, or "Runs only when started". A change in your HR system reaches Owlie at that source's next run, so this is when a new start date or a termination takes effect.
States
People lifecycle > States has two tabs.
Mapping shows what your HR system says and what each value means here. The Employment status values table lists every value your sources send, the number of people with it, the state it puts them in, and the rule that maps it. A value no rule names shows No rule yet: choose a state for it.
For example, your HR system sends LOA for people on leave, and the LOA row shows 12 people with
No rule yet. Choose On leave in the row's State list. Owlie adds a rule of yours,
"Employment status LOA", above the built-in rules, and the 12 people move to On leave. There is no
dialog: the choice is saved at once. Choosing a different state for a value that one of your own
single-value rules already maps changes that rule instead of adding another.
The Dates section lists the rules that move people by the calendar, such as the end date rules behind Leaving and Terminated.
Rules lists every lifecycle rule in order. The first rule that matches a person decides their state, and people no rule matches are in Unknown. Built-in rules can be edited but not deleted; your rules can be edited and deleted.
You can read both tabs with permission to read identities and lifecycle rules. Mapping a value or changing a rule needs permission to modify lifecycle rules.
A state's page
Select a state on the strip, or on the States page, to open it. The band shows how many people are in the state now, and the strip at the top leads to the neighbouring states. The page has five tabs:
| Tab | What it lists |
|---|---|
| Holds | The policies whose condition names this state, each read as a sentence such as "Everyone in Engineering gets Google Workspace and Slack.", with how many people it matches and its version. |
| Entering | The reactions that run once when someone moves into this state. |
| Leaving | The reactions that run once when someone moves out of this state. |
| Scheduled | The reactions that run on a day counted from one of the person's dates, such as "3 days before start date". |
| People | Everyone in the state now, with Try in the simulator for each person. |
On Holds, a policy whose next version names the state, but isn't rolled out yet, is listed under Pending changes. For example, the built-in Suspended access deny is listed there on the Suspended page until you roll it out. A policy shows a Pending change badge while a new version waits to roll out. The Active page's Holds tab links to Changes, where moves while Active are.
A policy is listed because its condition names the state. A reaction is listed where it is placed: a reaction you made from the reactions list appears on a state's page once you set On the lifecycle pages on it, as Lifecycle reactions describes.
Add a step
Each tab except People has Add a step. A step creates the real policy or reaction, placed on this page, and opens it:
| Tab | Step | What you fill in |
|---|---|---|
| Holds | Grant access | A resource and a name. Owlie creates a draft policy for everyone in the state. |
| Holds, Terminated only | Keep an account for some days after leaving | A resource and the number of days. See When someone is terminated. |
| Holds, Terminated only | Disable now, delete after some days | A resource and the days to wait before deleting. |
| Entering or Leaving | Notify | Who to tell, a subject and a message. |
| Entering or Leaving | Open a task for what they own | Who gets the task: their manager or a group. |
| Entering or Leaving | Add to a group | The group. |
| Scheduled | Run something on a date | The date, when to run, and what to do. |
Grant access names the policy "Everyone in Active gets Google Workspace" until you type your own name. The policy starts as a draft: on its page, narrow who it covers if you need to, add more access, then roll it out. Nothing is granted before you roll it out.
A step on Entering or Leaving is a reaction on that move. The dialog shows the move with the state already chosen, and you can widen it. For example, a step on Active's Entering tab runs on a move into Active from any state the person was already in, or only from the states you tick, such as Pre-hire. The dialog reads the reaction back in a sentence before you create it. It is created turned off: open it, read it, and turn on Enabled on its page. How transitions and the first import work is in Lifecycle reactions.
A step on Scheduled is a reaction from a date, such as "Send a welcome message 1 day before start date". Owlie preselects the date the state's own rules read. The fields are those of Run a reaction on a date. Owlie also creates the attribute that tracks the date, and lists the reaction on this state's Scheduled tab.
Each step needs the permission its object needs: modifying policies for a policy, managing reactions for a reaction, and also modifying lifecycle rules for a step that runs on a date.
When someone is terminated
Owlie ships the Terminated access deny, a built-in policy that removes all of a terminated person's access at once. It is shown on the Terminated page and can't be deleted. Entering Terminated also disables the person's Owlie account and ends their sessions; see Lifecycle state and overrides.
The Terminated page's Holds tab starts with Each resource, when someone is terminated: a sentence that says what happens, and a table with one row per resource. For example:
When someone is terminated, their access is removed at once, except Google Workspace, kept for 30 days.
| Column | What it sets |
|---|---|
| What happens to the account | Disable the account now, Delete the account now, or Disable now, delete later after the days you set. |
| Kept after the termination | How many days the person's account and access on this resource are kept for whoever takes over their work. Leave it blank to remove access at once. |
What happens to the account is the resource's own setting, so it changes for every termination from then on, and also shows on the resource. Delete the account now asks you to confirm, because the account is deleted with whatever it holds. A resource Owlie can't set from this table shows what happens instead, with Change in resource settings to change it there. For example, a resource fulfilled by hand shows Open a task for the owner, and one whose accounts Owlie never created shows Remove the access Owlie manages, leave the account to its owner.
Kept after the termination is a handover window. For a resource with a window of 30 days:
- the person keeps the account and access they already have on it for about 30 days after Owlie processes their termination;
- nothing new is granted on it during the window;
- when the window ends, Owlie removes the access, and the account is then disabled or deleted as its row says;
- if the person is rehired inside the window, they keep the access.
A window is part of the Terminated access deny, so changing one is a change to that policy. Enter the days, then select Save as a rollout. A banner says the change is waiting, and each row it changes shows Rolling out: select Review and roll it out to roll it out. Until it is rolled out, terminations keep the windows they had. Windows are 1 to 366 days.
Two built-in reactions run when someone is terminated. Both are on, and you can edit them or turn them off, but not delete them. Changing what the handover reaction does, or turning it off, needs the permissions its steps use: to manage requests, update identities and update resources.
- When someone is terminated: hand over responsibilities moves their open approvals to their manager and their tickets to each resource's owner, or to their manager when the owner can't take one. It also ends any delegation they set up, and opens a task for their manager to pick a new owner for each resource they owned.
- When someone is terminated: notify their manager sends their manager a handover checklist.
Until HR names a new manager for the leaver's reports, approvals, reviews and notices about those reports go to the leaver's manager. Owlie never changes a manager in your directory.
How to take one person through all of this is in Offboard an employee.
Changes
People lifecycle > Automate > Changes shows changes to people's department, manager, title or
location while they are Active, and what Owlie did next. Recent changes lists each change, such as
Department: Engineering → Design, and Then shows the access the next decision for that person
granted and removed, such as "+2 granted · −3 revoked", linked to their access. Owlie decides a
person's access again after every change, so the figures are that decision's whole result, which can
include other changes made at the same time.
Under Behaviors, Notify the old and new manager turns the built-in reaction "When someone's manager changes: notify the old and new manager" on or off. When someone's manager changes while they are Active, their new manager and their previous manager each get a notice. A person's first manager, such as one a first import sets, isn't a change, so nobody is notified.
Simulator
People lifecycle > Automate > Simulator answers "what happens to this person?" without saving or running anything. Choose a person under Person, or select Try in the simulator on a state's People tab.
The first line names the person's state and why they are in it: for example Active, from the built-in rule "Hired", or the state an administrator set by hand, with who set it and when. Below it, a timeline shows:
- Now: what they hold and through which policy, and any account kept in a handover window, with the day the window ends.
- If Priya becomes Terminated (one run for each state they could move to next): the reactions that would run, what would happen to each of their accounts, the notices that would go out, and the work they would hand over, such as "Has 2 tickets, 1 approval open to hand over."
Every future line says "would". A reaction that already ran for the same value, such as a date it already ran for, shows Already ran. When the person's dates would move them, the run says so and names the day. If an administrator set the person's state by hand, the simulator says that HR changes don't move them until the override is cleared.
The simulator needs permission to read policies, identities, reactions, resources and lifecycle rules.
Roll out a change
A change to what people hold is a new version of a policy, and it takes effect only when you roll it out. People lifecycle > Roll out > Rollouts lists the policies the lifecycle uses: every policy whose condition names a lifecycle state, or that is placed on one. Open a policy, save your change on its Editor tab (Save draft for a new policy, Save & stage for a change to an active one), then open its Rollout tab:
- Select Preview the rollout. Owlie works out what the version would change and shows the totals under Pending rollout: Identities, Grants, Revokes and Parked for review. A preview that stopped counting early shows "at least" before each figure.
- Under Try on a few, add up to ten people you want to check. For each one, Owlie shows what the version would give them and what they would lose. Nothing is saved.
- Select Roll out, check the totals in the confirmation, and select Roll out again.
If a rollout would remove a lot of access, the safety stop holds it before anything is applied, and its status reads Stopped for review. Check the totals, then select Resume (approve a large rollout) to apply it, or Cancel rollout to drop the staged change. Rollout history lists every rollout of the policy.
Previewing and cancelling need permission to modify policies. Rolling out and resuming need permission to activate policies, so the person who writes a change and the person who rolls it out can be different people.