For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

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. For multiple customers, use Separate customer data.

Classic examples

Classic component visibility is covered in hiding components, and the existing customer portal guide demonstrates separating data. Visibility rules still need separate authorization checks.

Last updated

Was this helpful?