Teams and roles
Use teams to group people with a shared access requirement. Begin with the built-in role descriptions, then review any app-specific permissions.
Recommended sequence
Choose a built-in role for each audience.
Create a team when a named group is useful.
Invite users to the intended team.
Add user or team properties only when an access rule or personalization needs them.
Test access with representative accounts.
Design teams around tasks
For a ticket app, a support team might update tickets while a reviewer only reads them. A builder who changes the app needs a different access level from an agent who changes ticket data.
Write down the intended permissions for each team before configuration: pages, records, create/update/delete actions, and builder or administration access. A team name such as Support or Managers is a label; verify the actual permissions behind it.
When a person belongs to more than one team, test their effective access. Do not assume a restrictive team overrides a broader one unless you have verified the behavior in your app.
Was this helpful?