A security role is a named bundle of privileges — Create, Read, Write, Delete, Append, Append To, Assign, Share — each set per table, at one of several access levels. A user’s effective access is the sum of every role assigned to them (directly or via a team); roles are additive, never restrictive.

Access levels

  • None — no access via this role.
  • User — only records the user owns.
  • Business Unit — records owned by anyone in the user’s own business unit.
  • Parent: Child Business Units — the user’s BU and every BU beneath it.
  • Organization — every record regardless of owner or business unit.

Privileges, briefly

  • Append — attach this record to another (e.g. add a Note to a Case).
  • Append To — allow other records to be attached to this one.
  • Assign — change a record’s owner.
  • Share — grant another user or team access to a specific record.

Append and Append To are the two privileges people most often forget and then can’t understand why a seemingly correct role still blocks an action — both sides of a relationship need the relevant privilege.

Roles stack; they never subtract. If a user has one role granting Organization-level Read on Accounts and another role granting only User-level, they end up with Organization-level access — the highest level from any assigned role wins for that privilege. There’s no way to use roles to carve out an exception for one user; for true one-off restriction, you’re looking at a different table design or a custom plugin, not security roles.

Custom roles vs. out-of-the-box roles

The built-in roles (System Administrator, Salesperson, Customer Service Representative, etc.) are reasonable starting points but are almost never exactly right for a real project. Standard practice: copy the closest built-in role and adjust it, rather than either using it unmodified or building entirely from scratch.