Setup journeys

Table of Contents

These are the first-system-setup journeys: an empty database becomes a usable installation, a tenant is brought into service, and a party is added to a tenant with the accounts that work in it.

They were designed and prototyped first, on throwaway branches, and those prototypes are the model the later journeys follow. Where a journey here has a prototype, the document links it.

The one group whose journeys carry state. A setup journey runs work that takes time and can fail half way, so it is the workflow composition class: the journey is the definition, and its progress is a workflow instance in ores.workflow. The person can leave the page and come back, and the shell can drive the same steps. Every other group describes a path over immediate operations, which keeps no such state. See Journey execution.

The order matters. First run is the only one that can happen on an empty database; the other two need a running installation and a signed-in administrator.

1. Journeys

Journey Actor Gist
First run nobody, then the system administrator Welcome, create the system administrator, first tenant inline, first sign-in
New tenant system administrator Choose a seed profile, describe the tenant, review, provisioning, hand off
New party tenant administrator Find the legal entity, describe it, review, provisioning, next steps

2. Related

Emacs 29.3 (Org mode 9.6.15)