It appears that the contributor and light agent roles permit view access to custom objects and are not configurable to be otherwise. On the other hand, these permissions are configurable for other licenses.
I understand that there are serious limitations to access governance with regard to custom objects (ie macro bypass of permissions on other roles), and I assume that is inherent to the architecture. However, since other roles can have their access configured, it seems like this restriction on modifications is arbitrary.
Custom objects could include sensitive data relevant to work done by private groups and should not be accessible to our light agents, contributors, or other members not in the private group. In the same way as ticket access can be customized.
To enforce effective user access governance, the custom object permissions should be configurable for light agent and contributor roles in the same way as ticket access can be customized.
Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]. (2-3 sentences)
Custom objects are visible to users that should not have access. While full licenses for agents can have their custom permissions restricted, due to the fixed config of light agents and contributors, admins cannot customize their access to these data assets.
What problem do you see this solving? (1-2 sentences)
The lack of customization options for light agent and contributor roles impacts data governance and may expose sensitive data. This limits the usability of the custom objects feature altogether.
When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)
This is an on-going issue. This impacts the ability for admins to control who access to what data.
Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)
The only workaround presently available is to not use custom objects to store sensitive data.
What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)
Unlock the light agent and contributor role customization options to allow admins to restrict/customize access to custom object data. At minimum, for the sake of safest data governance, the default should prevent view access.
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.