The System Actor
Every installation is operated by one organisation, the platform owner. It is a partner like any other: an organisation at the top of the system-level ladder. It also has one extra job as the system actor. When a write happens that no person made (ui5:sync recording the default settings, a scheduled job, a webhook), the system actor is recorded as its author.
The system actor records who wrote. It is not an account that signs in, and it grants nothing.
Which partner it is
The SDK reads config('ui5.system_actor_id'), which defaults to env('UI5_SYSTEM_ACTOR_ID', 1). On a fresh database the platform owner is the first partner, so the default already fits.
SystemActorResolverInterface resolves that id to the partner. The default resolver fails loudly:
| Exception | Cause |
|---|---|
MissingSystemActorException | No partner has the configured id. |
SystemActorEditLevelException | The partner exists but is not at platform-owner level. |
ui5:sync resolves the system actor before it writes the default settings, so a missing platform owner stops the first sync. Your own jobs and webhooks can resolve the same interface from the container when they need an author for their writes.
Creating it: ui5:intake
php artisan ui5:intake --name="Acme GmbH" --email=office@acme.testui5:intake creates the platform owner as an organisation at platform-owner level, or updates it in place. It is keyed on the email, so it is safe to run again. A value you leave blank never clears a field that is already set. Run it after migrate and before the first ui5:sync.
| Option | Holds |
|---|---|
--name | required — the organisation's name |
--email | required — its email, the key ui5:intake matches on |
--search-term | a short search term; derived from the name (uppercased, first 12 letters and digits) when omitted |
--ext-ref | a reference in an external system |
--vat | the VAT number |
--reg-no | the company registration number |
--office | the registered office |
--language | a two-letter language code |
--phone | the phone number |
--founded | the foundation date |
--force | skips the "update in place?" confirmation |
The two identity options are required and the rest are not. Anything you omit is asked for interactively and otherwise left unset — the command fills nothing in for you. The single value it computes is the search term, and it computes it from the name rather than inventing it.
So ui5:intake --no-interaction without --name and --email stops with an error naming both. That is deliberate: this command records the organisation that legally operates the installation, and there is no such thing as a sensible guess for that.
Before SDK 1.2.0
Earlier releases filled the omitted options from built-in demo values — ACME as the external reference, Wien as the registered office, de as the language, 1998-03-01 as the foundation date — and under --no-interaction wrote them without asking. If you are on such a release, check what your platform owner actually holds; a pipeline that forgot an option will have stored those values.
After writing, it checks the configuration. If ui5.system_actor_id resolves to this owner, it says so. If not, it tells you which UI5_SYSTEM_ACTOR_ID to put into .env before you run ui5:sync.
There is one platform owner per database. If a platform owner with a different email already exists, ui5:intake refuses and never creates a second one. To change the owner's details, run it again with the same email.
Where it shows up
- Default settings.
ui5:syncrecords the system actor as the author of the defaults it writes. - Grants nobody made by hand. Relationships and role assignments always name the partner who granted them. In a first seed, before anyone could grant anything, that author is the organisation.
- Your own automation. Scheduled jobs and incoming webhooks write on the system actor's behalf.
The order on a fresh database is migrate → ui5:intake → ui5:sync → seed.