We started by creating the Access Team template to give any user in the team write access to the specific record.

In step 2 to step 5, we added the specific Access Team subgrid to the form to easily manipulate who is part of the list. Finally, in step 6, we added a user to the Access Team, giving them special access to a specific record that they would not have access to otherwise.

Access Teams are relatively faster and more scalable than Owner Teams. Access Teams do not have security roles associated with them, rendering them faster to query given the simpler structure.

Entities can contain one or more Access Teams based on Access Team templates. When users join an Access Team, they inherit the privileges associated with that team regardless of their current privileges. Access Teams are also cumulative like security roles.

One thing to keep in mind is that the privilege is only applied to the one record. All related records will still follow the default security roles. Extra customization can propagate the user's membership to additional Access Teams belonging to related records. Furthermore, security role hierarchies (User, Organization, Parent: Child Business Unit), are irrelevant as Access Teams are not driven by ownership.

One more thing to be aware of is that team access templates are not solution-aware. They are treated as data and need to be transported using a different mechanism between SDLC environments.