The situation
A hire is agreed and a dozen things have to happen across HR, IT and facilities before the start date, some of them with legal deadlines and expiry dates. The list differs by role and country. Today it is a spreadsheet copied per hire, chased by hand, with no record of what was actually done or when the document that proves it expires.
These are illustrative scenarios showing how the products are used, not customer case studies.
Build-versus-buy lens
What this helps you decide
Use the example to find where product configuration ends and custom code begins — and whether the boundary leaves your team with less infrastructure to own.
- Model fit
- Can the record shape evolve without coordinating a migration, API and UI release?
- Workflow fit
- Can approvals, exceptions and deadlines move out of application code without losing control?
- Integration fit
- Can your existing APIs become reusable steps with retries, throttling and visible run history?
- Control fit
- Can your team reconstruct model changes, workflow runs and human decisions later?
What gets modeled
The structure as it would actually be defined — sections that repeat are marked.
- Onboardingrecord type
- Employeesection
Reusable — shared with Offboarding
- Rolechoice
Drives which tasks apply
- Documentsrepeating section
- Typechoice
Read from Document types, per country
- Filefile upload
Permitted types and size capped
- Expiresdate
What the reminder schedule reads
- Access requestsrepeating section
- Systemchoice
- Granted ondate and time
- Document typesrecord type
Per country; the single list
How it gets built
In the order somebody would actually do it. Each step names the capability it rests on, so it can be checked against the product pages.
Model the starter, not the spreadsheet
Documents and access requests are repeating sections because their number varies by role and country. The employee section is defined once and reused wherever a person appears, so offboarding does not redefine it.
What it uses: Repeating sections, and reusable sections shared across record types
Let HR own the country rules
Which documents a country requires is a choice field reading live from the record type HR owns. Adding a requirement is a change in one place that the form, the validation and the API all see on the next read.
What it uses: Live option sources
Start the run when the hire is created
A trigger starts the onboarding run on record creation, with filters so contractors take a different path from employees. Conditional links branch on the role, with an explicit default path.
What it uses: Record triggers with filters, conditional links
Request the accounts as steps, not tickets
Account creation in each system is a step, registered by importing that service’s API description or authored by hand where there is none. Step inputs are mapped from the record, so nobody retypes a name into a ticket.
What it uses: Any API becomes a step, with mapped inputs
Stop and ask a person where a person is needed
Equipment sign-off and manager confirmation are human decision steps landing in an inbox, embedded in the HR interface rather than a separate tool. The decision chooses the outgoing path, using your own vocabulary rather than a generic approve and reject.
What it uses: Human decision steps with your own decision vocabulary, embeddable inbox
Chase the missing document
A deadline warning fires while a document is outstanding, and escalation moves it on when the start date approaches. Notification templates are yours to rewrite.
What it uses: Deadline warnings, escalation, and editable notification templates
Catch the expiry months later
A scheduled workflow — a cron expression or a fixed interval — reads documents approaching expiry and starts a renewal run. Because the schedule is itself a workflow, a reminder that quietly stops firing raises a notification. Nobody has to discover it during an inspection.
What it uses: Schedule triggers listed alongside every other run
Numbers used above, and where they come from
Every figure on this site is counted from the product itself. Nothing here is a performance or customer claim, because there is no measurement to cite for one.
- field types
- 9field typesCounted from egav/backend/app/api/v1/egav/schemas/entity_type_attribute.py — DataType
- ways a field can be presented
- 43ways a field can be presentedCounted from egav/backend/app/api/v1/egav/schemas/ui_configuration.py — WidgetType
What changes
Day one is a run somebody can look at rather than a spreadsheet somebody remembers to check, and the document that expires in eleven months is already on a schedule rather than a note in a calendar.
Written for Operations teams that own a process.