The First Seed

The SDK has no sign-up. Everyone who works in an installation is a partner. The first ones, the people who must be there on day one, come from a seeder. Writing it is the first step of every implementation. After it, everything happens in the apps.

Where it runs

The seed runs on the QA system first. QA doubles as the customer's training system. People learn the apps with their own organisation in them, the roles are checked against real work, and the customer signs off. The whole database then moves to production in the initial deployment: the go-live. Production starts as a copy of the signed-off QA database, so the seeder never has to run there.

What must exist first

1. The platform owner. ui5:intake creates it.
2. The synced catalog. ui5:sync writes the roles, the abilities and the relationship types (employed_by among them) that the seeder refers to.

What each person needs

What	Where	Why
The person	sdk_partners, type Person	It is what the SDK authorizes.
A login	users, with partner_id set	Without the link, every request answers 403.
Role assignments	sdk_role_assignments	They open the apps. Partners and Settings need local_admin; the Launchpad needs no role.
Membership	sdk_partner_relationships, employed_by, primary	Not needed to sign in. Without it, primaryOrgPartner() and everything scoped to the actor's organisation return nothing.

Every relationship and assignment follows two rules:

• Someone granted it. Each row names the partner who granted it (assigned_by_partner_id, required). In a first seed nobody could grant anything yet, so the organisation is the author.
• It is time-bound. valid_from defaults to now and valid_until to 9999-12-31 23:59:59. Set them when an assignment has to start or end on a date.

The system level grants nothing. A person's system_level decides which settings scope they may write. It does not open a single app. Access comes only from role and ability grants. A seeded admin who sees an empty navigation rail is almost always missing the role assignment.

The pattern

The Quickstart has a minimal seeder: one organisation, one person, one role, one login. A real one does the same for every person, and stays safe to run again:

• Key every row on something stable, usually the email, and write with updateOrInsert or firstOrCreate. The seeder can then run again on QA after a correction.
• Seed only day one. The interface for partners is the Partners app, not code. The seeder writes what must exist before anyone can sign in to that app. From then on people, memberships, login objects and roles are looked after there. Every change made there runs the app's checks, such as the rule that a person has only one primary membership. Raw inserts skip those checks, which is fine on an empty database and only there.
• Login objects: the seeder can create them with initial passwords. It can also leave them to the Partners app, which creates them with a password change required at the first sign-in.

After the seed

Everyone else is created in the Partners app by a local admin: partners, memberships, logins and roles.

A hand-written seeder is right for one company. Doing it for every customer is a different job. It means scoping a finished solution against what the customer needs, then fit-to-standard, training, sign-off and go-live, and it calls for a method. Pragmatiqu IT's method for that, from discovery to go-live, is part of Platform.