> For the complete documentation index, see [llms.txt](https://docs.jetadmin.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.jetadmin.io/access-and-sharing/members-users-and-groups/user-and-team-properties.md).

# User and team properties

In this section you will learn about user-specific permissions

Add attributes such as department, customer ID, or status to user and team records. A property stores a value; access changes only when a rule uses that value.

## Add a Select property

1. Open **Users → Users** for a user property, or **Users → Teams** for a team property.
2. Select **Add Property**.
3. Choose **Select** as the property type.
4. Set **Name** to Status.
5. Under **Specify options**, replace the blank option with Active.
6. Select **Add an Option** and add Inactive.
7. Select **Create**, then populate the values for the relevant records.

![New Property dialog with Select type, Name, Specify options, and Add an Option](https://3448227606-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LQ08RFAKZvFADEiXKFy%2Fuploads%2FEUp5aZiZzHRGJCVTIAmb%2F05-user-property.png?alt=media)

Use this as a data-model example. A Status value of Inactive does not automatically disable a user's account.

## Use properties in access rules

Define who can change properties used for authorization. A user should not be able to grant themselves access by changing their own customer ID or department.

Use stable identifiers, consistent types, and explicit behavior for missing values. If user and team properties use the same key, document which value the rule should use when they differ, then test that case.

For record restrictions, continue with [Restrict access to records](/access-and-sharing/app-and-data-permissions/record-access.md). For multiple customers, use [Separate customer data](/access-and-sharing/app-and-data-permissions/customer-data-isolation.md).

### Classic examples

Classic component visibility is covered in [hiding components](/classic-app-builder/design-and-structure/components-visibility/conditional-visibility.md), and the existing [customer portal guide](/classic-app-builder/videos/build-apps-together/customer-portal.md) demonstrates separating data. Visibility rules still need separate authorization checks.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.jetadmin.io/access-and-sharing/members-users-and-groups/user-and-team-properties.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.