Roles

Roles describe a user's position in the organization. They are useful for hierarchy and management responsibility, but they should not become the only way to grant permissions.

Role responsibilities

Use roles to model:

• manager/subordinate relationships;
• department or team hierarchy;
• record visibility based on ownership hierarchy;
• approval responsibility;
• reporting structure.

Use permission sets to grant concrete object, field, and system capabilities.

System objects

Recommended pattern

Start with a small role hierarchy:

System Administrator
Sales Director
Sales Manager
Sales Representative
Support Manager
Support Agent

Then attach permission sets for capabilities:

Sales Manager role
  -> CRM User
  -> Sales Manager Access
  -> Report Viewer

This keeps the role tree stable while allowing permissions to evolve.

Avoid

• one role per individual user;
• duplicating every permission inside every role;
• using role names as business logic checks;
• granting broad access through manager roles when record sharing would be more precise.