Tickets cannot be seen by on behalf users in servicenow self-service portal

[KRM]

Dear Servicenow Experts,

We have an issue here in were, ticket are not visible for the on behalf users (without itil role) in servicenow self service portal.

Scenario:

If a local IT (which has ITIL role) will raise a ticket in self service portal(service catalog) and set on behalf user (which has no role) . A ticket will be created, but the on behalf user will not see the ticket status.

I checked other discussion, which they advise about the Query Business Rule , but not sure how to modify it since users need to access it on a self service portal. Not the incident console it self.

Also checked the application menu > Self Service but no restrictions are found under myrequests

Please advise the configuration on how to allow on behalf users to view their ticket in self service portal.

Thank you for your support.

[pavan9885]

I can answer your  question as in London upgrade  if widget having roles so best practice is clone the widget and customize the code with roles or with no roles based on your requirement .

1.  if you are using default OOB widgets   please check in the widgets there is a default  "approver_user." role is defined in out of script in the back end from service now 

2. If you don't want any roles for users to see the approval or any records you can clone the default widgets and remove the OOB roles coming from Service now.

[patricklatella]

OK, thanks so much...and with the cloned widget and changing the logic there...would I still need to mess with ACLs?

[Allen Andreas]

Hi,

Uh...you can apply roles or remove roles all day from widgets, but if there are ACL's blocking vision, etc. you won't see anything, it'll say "returns no records", unless you remove some of the check script in the server portion, then maybe you can loop-hole around it, but if you are wanting to set it platform wide...then you'd just want to go to your ACLs. So firstly, you would need to go to your ACL for Incident and Read type and look at what you have now, then decide if you want to keep what you have and just add an additional ACL...or edit the one you have now.

Regardless, the script section would then need to query the user table to look for the logged in users company, then compare that to the Incident company and then decide if access should be allowed or not. Once that evaluation has passed THEN...the data would show in your widget.

So ACL is step 1, widget is step 2.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[patricklatella]

Hi Allen,

thanks so much for your clarification, really helps...so it looks like I need to do a combination of working with the ACLs and cloning the simple list widget for my needs.

[pavan9885]

Yup if you clone the widget also you have to modify the OOB server script and make sure to check the roles 

if you require a role for a  cloned widget define the role in the server script

if you  don't  require role for the cloned widget make sure to remove the role in the server script  

Make sure you  match your  requirements for better resilts