Skip to main content

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.
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, the custom attributes you’ve enabled — like department or cost center — are also available on the signed-in user. Add a User field to any table to attach its records to a person.
1

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

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

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 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. 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:
This is the one case where copying a user into your own table is still the right answer. See 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 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

No. User sync connected two separate stores of users, which no longer exist separately. See What happened to user sync.
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.
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.
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.
Last modified on August 14, 2026