> ## 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 records to the people who use your app and keep extra user information in your workspace database — no syncing required.

## Overview

The people who sign in to your app are stored in your workspace's own database, alongside your tables. That means you don't copy them anywhere — you point at them.

If you want to track a phone number, a department, a plan, or anything else about a person, put it in one of your own tables and link that table to the user. Zite keeps the account; you keep everything else.

## 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.

<Note>
  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.
</Note>

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.

<Steps>
  <Step title="Create or open the table">
    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.
  </Step>

  <Step title="Add a User field">
    Add a field and choose the `User` type. Name it for its role in the table — `Owner`, `Assignee`, `Submitted by`, `Member`.
  </Step>

  <Step title="Adjust the field settings">
    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.
  </Step>
</Steps>

## 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).

<Tip>
  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.
</Tip>

## See your users in the database

Open your workspace database to see the users panel. It's read-only — you manage who has access from each app's `Users` tab, or from the workspace's `Members` page.

## FAQs

<AccordionGroup>
  <Accordion title="Do I need to set up user sync?">
    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).
  </Accordion>

  <Accordion title="Can I import a list of users?">
    Yes. Open the app's `Users` tab, click `Add user`, and switch to the bulk tab to paste up to 100 email addresses at a time. See [Manage users](/help/platform/access/manage-users).
  </Accordion>

  <Accordion title="What happens to someone's records when I remove them?">
    By default the records stay and the User field is left empty. If a table's User field has **Delete row when user is deleted** turned on, those rows are deleted when the person is removed from the workspace.

    Removing someone from a single app doesn't delete anything — they're still in the workspace.
  </Accordion>

  <Accordion title="Can two apps in the same workspace share user data?">
    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.
  </Accordion>
</AccordionGroup>

<p className="zite-related-topics-heading">Related topics</p>

<div className="zite-related-topics">
  <a href="/help/database/configure-database/user-field">User field</a>
  <a href="/help/platform/access/manage-users">Manage users</a>
  <a href="/help/platform/access/custom-access-rules">Custom access rules</a>
  <a href="/help/platform/access/user-sync">What happened to user sync</a>
</div>