> ## Documentation Index > Fetch the complete documentation index at: https://zite.com/llms.txt > Use this file to discover all available pages before exploring further. # Store extra data about your users > Relate database records to editors, internal app members, and external users in your workspace. ## Overview Each person who can use the workspace or one of its apps is stored once in the workspace's shared user directory. This includes editors, internal app members, and external users. Apps and database tables can point to the same person. To track details such as a phone number, department, or plan, add them to one of your own tables and link that table to the user. ## What Zite stores on a user Every user has the same small set of fields: * **Name** * **Email** * **First name** * **Last name** * **Profile image** That list is fixed and the same for every app. Anything beyond it belongs in your tables. Your users appear in a dedicated panel in the database rather than as a normal table, and you can't add columns to it. That's deliberate — you extend a user by relating to them, which keeps one person's details from being scattered across apps. If your app uses [SSO](/help/platform/access/sso), the custom attributes you've enabled — like department or cost center — are also available on the signed-in user. ## Link a table to your users Add a [User field](/help/database/configure-database/user-field) to any table to attach its records to a person. Use whatever table the data belongs in. A `Profiles` table if the row *is* a person, or an existing table like `Requests` or `Orders` if you're recording who it belongs to. Add a field and choose the `User` type. Name it for its role in the table — `Owner`, `Assignee`, `Submitted by`, `Member`. Decide whether the field holds one person or several, whether the picker should show only your team, and whether the row should be deleted when that person is removed from the workspace. See [User field](/help/database/configure-database/user-field) for what each setting does. ## Ask the Agent for what you need Once a table is linked to your users, describe the behavior you want and the Agent builds it. | What you want | What to ask for | | - | - | | Per-user data | `Only show each person the records where they're the owner.` | | Extra profile fields | `Add a phone number and department for each user, and let them edit it from their profile page.` | | Attribution | `Record who submitted each request and show it in the list.` | | A user directory | `Add a team page that lists everyone with access and what they're working on.` | When you ask, name the table, name the behavior, and say what should happen for someone with no matching records — an empty state is easy to forget and awkward to discover later. ## Add a profile record when someone signs up Sometimes a row per person needs to exist before they do anything — a form needs somewhere to write, a workflow needs a record to look up, or another system needs to be told. Create the table, then ask the Agent for an **After sign up** rule: ```text theme={null} After someone signs up, add them to the Profiles table. ``` This is the one case where copying a user into your own table is still the right answer. See [Custom access rules](/help/platform/access/custom-access-rules). If the row is a profile for that person, set **Delete row when user is deleted** on its User field so the profile goes when they do. Leave it off for rows like tasks or orders, which belong to the work rather than the person. ## See your users Open the workspace database to see its read-only users panel. This panel shows the people stored in the shared user directory, but access is managed from the workspace's Users area. Click `Users` to the left of the workspace selector, then choose the relevant view: * `Editors` for people with workspace-wide editing access * An internal app for organization members with **Use Access** to that app * An external app for people outside your organization who have signed up to use it ## FAQs No. User sync connected two separate stores of users, which no longer exist separately. See [What happened to user sync](/help/platform/access/user-sync). Open the workspace's Users area and select the app first. Use `Invite` to add the people who need access. See [Members & users](/help/platform/access/manage-users). Removing access to one app does not delete the person or their records. They may still be an editor or a member of another app. If the person is deleted from the workspace's shared user directory, the records stay and the User field is left empty by default. Rows are deleted only when the field has **Delete row when user is deleted** turned on. Yes. A workspace has one database and one set of users, so a profile table you build for one app is available to every app in that workspace. Access to each app is still controlled separately.