​

User profiles

A user profile holds extra fields on a person (phone, sport, jersey size) next to their portal login. You do not create a second people table or ask the AI to invent a hook that copies each new user. Tell Build what to collect and when. Example: collect sport when you invite an athlete, and phone when they accept or register.

​

Who gets which shape

You can have one shared profile for everyone, plus optional role-specific profiles (for example athletes only). A person can match the shared profile and one role-specific profile. Profile tables store attributes. They are not a second membership list. End-Users and portal People still show who is in the project.

​

Invite and register fields

Some fields are filled by the person who sends the invite. Others are filled by the person when they accept the invite or register.

• Invite forms on End-Users and portal People show invite fields for the role you picked.
• Accept-invite and project register forms show register fields for that role.

Required fields must be filled before the invite is sent or the account is created. Do not edit a user profile table yourself in Migrations. Ask Build to change the user profile.

​

After you already built a companion table

If an older app created extra rows with a users:create hook, ask Build to declare a user profile instead and remove that hook. Invites now create the person in the project immediately (status invited), so that hook would fire at invite time on every path, including portal People.

​

Delete all data

Delete all data on the person’s user page removes their profile rows and their login row. Remove from project only takes away access. Profile rows stay until you delete all data. After they leave every project, find them under No access on the project they left. See Inviting and managing end users.