sn_customerservice.customer visibility on all the contacts from own company

valkyrichek
Tera Expert

We have a requirement from the customer to allow all the contacts with just the "sn_customerservice.customer" role to see all the other contacts from own account, so that they can report cases on behalf of each other. 

I understand that this can be achieved by granting them the role "sn_customerservice.customer_admin", but it's not the ideal solution, because they do not need to manage the contacts for own company, only see them.

With the out of the box "before query" business rules and ACLs, I understand that to achieve that we need to define a new implementation in the scripted extension point CSQueryExtensionPoint, but so far we could not find the right definition for this. 

Has anyone had such a requirement, and how did you achieve that? 

Thanks in advance!

1 ACCEPTED SOLUTION

valkyrichek
Tera Expert

Actually we found the right context to use in this case, it was just the matter of cache that it didn't work at the first sight. 

Something like this, but of course in a custom constant file: "{'access_context': [CSQueryBRUtilOOBConstants.MY_ACCOUNT, CSQueryBRUtilOOBConstants.ACCTS_FROM_CONTACT_RELATIONSHIP, CSQueryBRUtilOOBConstants.SUB_ACCTS]}"
 

View solution in original post

4 REPLIES 4

Willem
Giga Sage
Giga Sage

Hi Valentina,

Instead of customizing a lot and using OOTB roles in a different way, it might be best to create a new role, add an ACL for that role and grant access that way.

Doing it this way ensures the OOTB roles and security still works. If anything would go wrong or you want to move back to OOTB then you can just remove the ACL and the role and you are done.

Adding a ACL will grant access if it is true. So for each existing ACL on the table/record you want access to, create your own ACL.

 

Let me know if you need more info.

Well, that's the problem with the CSM that it's not so simple as in the other modules - in CSM all the access to the tables is managed with a single script include which is difficult to override with the "standard" approach to ACLs and before query BRs. 

https://docs.servicenow.com/bundle/orlando-customer-service-management/page/product/customer-service...

valkyrichek
Tera Expert

Actually we found the right context to use in this case, it was just the matter of cache that it didn't work at the first sight. 

Something like this, but of course in a custom constant file: "{'access_context': [CSQueryBRUtilOOBConstants.MY_ACCOUNT, CSQueryBRUtilOOBConstants.ACCTS_FROM_CONTACT_RELATIONSHIP, CSQueryBRUtilOOBConstants.SUB_ACCTS]}"
 

Hi @valkyrichek ,

 

Could you please share me the detailed steps you followed? I got stuck with creating extension points to change the conditions.