> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Employee lifecycle architecture

> Decide how onboarding and offboarding enter Ravenna and how work fans out across teams, using a parent ticket in the owning workspace and one child ticket per team.

Onboarding and offboarding are the same machine pointed in opposite directions. Two decisions shape both: how the event gets in, and how work reaches each team. Settle them here and the [onboarding](/guides/playbooks/hr/employee-onboarding) and [offboarding](/guides/playbooks/hr/employee-offboarding) playbooks become build instructions.

## Mental model

The employee lifecycle in Ravenna is a fan-out: one intake event produces one parent ticket in the owning team's workspace, and one child ticket per participating team, each in that team's own workspace. Creating a child publishes it, which fires the destination workspace's `Ticket Created` trigger, so each team's workflow runs independently and is owned by that team.

Ravenna coordinates and records. The identity provider provisions. Ravenna's job is group membership, not per-application assignment.

Layer hierarchy for access: Application > Access level > Access policy > Approval template. Provisioning methods on an access level are Group, Application, Manual, and Workflow. Group is the default and the recommended one, because one membership grants every application mapped to that group in the provider.

***

## Intake options, in priority order

| Rank | Trigger                       | Prerequisite                                                                                                                                    | Notes                                                                                                                           |
| ---- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| 1    | `Webhook (AI Prompt Trigger)` | The HRIS can POST to a URL                                                                                                                      | The prompt parses arbitrary payload shapes. The URL is a secret and can only be rotated by deleting and recreating the trigger. |
| 2    | `Ticket Created`              | A connected Slack request channel or a routed email address, plus an agent rule that reads the alert and creates a ticket on the lifecycle form | Prefer agent rules over auto-create. The rule must instruct the agent not to reply in the channel.                              |
| 3    | `Form Submitted`              | A New hire or Offboarding form                                                                                                                  | Filter the trigger to the specific form.                                                                                        |

HRIS employee data syncs every 24 hours. Any process that must act on the day of the event needs one of the three triggers above, not the sync.

***

## Build sequence for the fan-out

The parent-side workflow, in order:

1. Trigger on the chosen intake.
2. On the webhook path only, `Create Ticket` in the owning workspace's channel to make the parent. On the form and alert paths the trigger ticket **is** the parent, so skip this.
3. One `Create Ticket` step per participating team, each configured with:
   * `Workspace` set to that team's workspace, and `Channel` set to their lifecycle channel
   * `Parent ticket` set to the parent's ID (the parent may live in a different workspace)
   * `Form` set to a reference to the intake ticket's form, which copies that ticket's field values onto the child
   * Optionally `Requester`, `Assignee`, `Followers`, `Category`, `Tags`, `Due date`, `Status`
4. `Send Message` and `Send Email` for announcements.

`Create Ticket` outputs `ticketId` and `isSuccess`, both referenceable by later steps.

Each child-side workflow, in order: trigger on `Ticket Created` filtered to that team's lifecycle channel, `Apply Task Template`, branch with `If / Else` or `Conditional`, request access levels, `Wait Until` for scheduling, then `Send Message` on the parent to report completion.

***

## The employee record

The canonical field set every downstream branch reads: first name, last name, work email, personal email, employee ID, start date or last working day, role or title, department, country, manager. Date fields must be date-only.

***

## Constraints and gotchas

* A same-workspace `Create Ticket` skips downstream dispatch, to stop a workflow retriggering itself. Only a cross-workspace create publishes immediately and fires the destination's triggers. A fan-out therefore requires the children to be in different workspaces from the workflow.
* The `Parent ticket` lookup is not workspace-scoped, so a cross-workspace parent link works. This is the intended pattern.
* `Ticket attributes` pickers on a `Create Ticket` step list the attributes of the workflow's own workspace, not the destination's. Pass destination-specific values through the copied form or the description.
* `Update Ticket` has no workspace field. It cannot reliably target a ticket in another workspace, so set everything on the create rather than creating a bare ticket and filling it in.
* Setting the `Form` input to another ticket's form is what copies field values. A child created without it has no fields for its own workflow to branch on. Values set explicitly on the step override the copied ones.
* Auto-create on a Slack channel bypasses agent processing, so do not connect an agent to an auto-create channel. For HRIS alerts, use an agent rule on a normal request channel instead, and include an explicit instruction not to reply.
* A start date carrying a time component shifts `Wait Until` offsets by a day for anyone in another timezone.
* Task templates cannot be reordered after creation, and importing a template replaces the ticket's existing tasks. Apply once, early.
* Ravenna has no native HRIS hire or termination webhook, no "user created" trigger, and no org-level lifecycle builder. The generic `Webhook (AI Prompt Trigger)` is the mechanism.


## Related topics

- [Employee offboarding](/guides/playbooks/hr/employee-offboarding.md)
- [Employee onboarding](/guides/playbooks/hr/employee-onboarding.md)
- [Device lifecycle](/guides/playbooks/it/device-lifecycle.md)
- [HR and People](/guides/playbooks/hr/overview.md)
- [Setting up access provisioning](/guides/how-to/setting-up-access-provisioning.md)
