Starter packs and lifecycle mails
Starter packs install a reviewed piece of configuration in one step: approval rules, access-review rules, separation-of-duties rules, access-grant policy templates or lifecycle settings. They live under Setup › Rules › Starter packs (the old Library link redirects there).
Until 25 October 2026 this page described workflow packages (pkg.*): code-defined
scenarios that wrote workflows and custom properties. They are gone, and so is the
/api/v1/workflow-packages endpoint. A section below says where each one went.
The Starter packs page
Each pack is a card with its frameworks, a Starter or Yours chip, "Installed · version" once installed, one chip per kind of item it adds, and "Installs switched off" when the pack activates nothing. Filter chips (All, Starter, Sector, Yours, Installed) and a search narrow the list. Uninstall asks first, because it removes the pack's rules.
Creating your own pack, installing one from a file and managing trusted publishers sit below the catalogue. Moving configuration between your own tenants is a different job and has its own place, Environments › Config promotion; see environments and staged configuration.
What a starter pack is
Config packs (app/domain/config_pack, id prefix pack.*) bundle configuration: the manifest can carry object types (SchemaDefinition), scoped roles (delegated admin — a capability set bound to an owner-anchored scope), approval rules and separation-of-duties rules. Installation is idempotent, and reports per item what it created versus kept.
What the registry holds today is six sector packs — financial services (SOX and DORA), healthcare (HIPAA and GDPR Article 9), public sector (NIS2 and the EU AI Act), mid-market (ISO 27001 and GDPR), manufacturing (IEC 62443 and NIS2 across IT and OT), and AI enterprise (EU AI Act and NIST AI RMF).
They are deliberately small. Each seeds one opinionated approval rule for its sector — routing high-risk resources to security and compliance, patient-data access to a privacy officer, AI-agent access to a four-eyes check — and the financial pack additionally seeds three separation-of-duties rules. None of them currently seeds object types or scoped roles, even though the manifest supports both: a pack is a starting point that saves an hour of first-day configuration, not a compliance programme in a box.
Next to the sector packs, the registry holds four generic starter packs that answer "what does every tenant need on day one". They install inert, so nothing grants, reviews or mails anyone until you switch it on:
pack.starter.birthright— three access-grant policy templates, one each for department, location and legal entity. You pick the context value and the entitlements in the Policy Builder, then enable them.pack.starter.jml— the lifecycle windows only: a 3-day joiner pre-provisioning window, policy access that stops on the end date and a 7-day account grace. It never overwrites a setting you already changed, and uninstall only reverts fields that still hold the pack's value. The joiner, manager-change and leaver mails are no longer part of it (see below). See JML flows.pack.starter.cert— four access-review rules (privileged access, all access, and two event-driven), all created inactive.pack.starter.sod— three generic separation-of-duties conflicts (payment create versus approve, user administration versus audit log, requisition versus goods receipt), created disabled. Tune the keywords to your real entitlement names before enabling.
Lifecycle mails are notification rules
The joiner welcome, manager-change and leaver mails are notification rules on the lifecycle events (joiner, mover, leaver), under Notifications › Rules › "Mails about people". Every tenant has four of them, switched off: who receives a mail about a person is your decision. A rule can be limited to identity types and, for a mover, to the fields that changed; it can go to the person, their manager, their previous manager or the members of a role, with at most five recipients and 25 members per role. A lifecycle mail never carries a password. The Lifecycle mails pane of the Lifecycle settings shows the same rules per stage, read-only, with a link to Notifications › Rules where they are changed.
A tenant that had switched on one of the old package workflows keeps the mail: the workflow was switched off and renamed "… (moved to Notifications)", and the matching rule was switched on with the same recipients.
What the workflow packages became
| Old package or item | Now |
|---|---|
pkg.joiner_welcome, pkg.manager_change_notify, pkg.leaver_notice |
Lifecycle notification rules, see above. |
pkg.samaccountname, pkg.ad_username |
An account's name on a target system is an account convention; see account types. |
pkg.work_email |
An identity attribute such as the work e-mail is a generation rule in the Data model. |
pkg.unstructured_data_preview |
The File shares preview is switched on under Subscription › Previews; see unstructured-data visibility. |
pkg.ivip_mode |
Removed. The IVIP risk and analytics lenses stay. |
The nine tmpl.* starter templates |
Removed. A workflow a tenant created from one stays. |
| The two built-in workflows | Retired: one without runs was deleted, one with runs was disabled and labelled "Retired built-in", so its run history stays. |
| Sequences and schema mappings | Removed. Business ids are derived from names, so no create form asks for an id. Data checks (invariants) are the Checks tab of a custom object type in the Data model. |
An earlier delegated-onboarding pack, which composed external organisations out of these primitives, was retired in July 2026: external onboarding became a first-class module that owns those objects directly, and keeping a pack that modelled the same thing in parallel would have meant two definitions of it. See external onboarding.
Further reading: