Plan requirement
| Subscription | Suite Team or higher, Support Enterprise |
| Access | Admin |
Who can read, create and edit records is set per object, and it is worth deciding rather than accepting.
Set them
- Open the custom object in Admin Center.
- Set whether the records page is visible to all agents and admins, or to admins only.
- Set what each role may do: read, create, update, delete.
- Save and check with an agent account.
How much of that you can set depends on the plan. On Team, Growth and Professional the permissions for the standard admin and agent roles are fixed, and only the light agent and contributor roles are yours to configure. Full control per role needs Enterprise and its custom roles. Check this before you promise somebody a permission model your plan will not hold.
The usual shape
- All agents can read. They need the context to answer.
- A smaller group can edit. Whoever is responsible for the data being right.
- Almost nobody can delete. Deleting a record breaks the tickets pointing at it.
Read for everyone and edit for few is the configuration most organisations land on, and it is a good default to start from.
Where the data is sensitive
Contract values, renewal dates and commercial terms are not automatically things every agent should see. Where that applies, restrict reading too, and put only what agents need on the card in the context panel.
Customer access is not scoped to their own records. You can let end users view, add, edit and delete records, but the permission is granted at the level of the whole object. Give customers read access to your contracts object and each of them can read all of it, not the rows that concern them. Where you want a customer to see their own data, that is a lookup on their ticket or organisation, not a permission on the object.
When another system owns it
Make it read-only for agents. A synced copy that agents can edit produces divergence, and the edit is lost at the next sync anyway, which is worse than not allowing it.
Filtering by brand
Records can be scoped to brands, so a multibrand account can keep one brand's contracts out of another's pickers. Worth doing where the brands are genuinely separate businesses.
Comments
0 comments
Article is closed for comments.