- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-22-2023 02:52 PM - edited 06-22-2023 02:57 PM
Hi, been banging my head again the wall for a couple days now and have no idea why this is not working and I need this fixed ASAP. If anyone can help let me know. When I find a solution I promise to post back what I ended up doing to fix this.
On this form we have a customer who logs into the portal and chooses a store number in the 'Rest/Account' field and, based on who he is as the logged in user, it presents a list of stores. This all works fine and the world is good place.
Then we have the contact field below that called 'Rest/Act Contact'. This should provide a list of contacts from the contact relationship table for the store account based on a reference qualifier. But it just gives me "No matches found".
But I know my code works because (after taking forever to figure out how to throw debugs to the log, I can see that it's working. The form just wont display it. Something is interfering but I can't find any other script that would interfere. I must be missing something. Here's all the info...
This is the info on the Reference Qualifier call on the "Rest/Act Contact" field. I'm pulling from a script include I wrote, and I'm throwing the value from the 'account' field ("Rest/Account" mentioned above) to the script. Both fields are reference fields and are throwing sys_ids.
Here's the script include...
To run it, I impersonate one of our Franchisees, pull up the Create Case form, pick a restaurant in the "Rest/Account" field. Then click on the "Rest/Act Contact" field, and get this...
After a series of foul mouth remarks and swear words emit from my mouth after the 100th time this didn't work 🙂 I check the syslog for that gs.info line I added to my script, which shows the value I am returning to the field (eg. "sys_idIN7897....etc."). See below.
Obviously, I am missing something, but what I'm seeing in that last screenshot is that I'm pulling the sys_id for the Franchisee for that store, there is only one in this case, but it still says "No matches found" when what it should do is give me that franchisee's name as a choice in the drop down.
What am I doing wrong?
I'm going to keep at it until I figure it out but if anyone has any ideas please help! This one has me stuck.
Thanks!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-24-2023 01:31 PM - edited 06-24-2023 01:34 PM
OK, after many hours, I've figured this out. My last post was actually the solution. Switching the "Reference" field, under "Type Specifications" in the Variable setting for "Rest/Act Contact" to "User [sys_user]" allows the drop down to work.
The reason it was NOT showing me multiple users is by design for the CSM portal. See this article..
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0718506
I discovered it was a permissions issue when I gave an external user admin rights and snc_internal to debug the form. When I did that, the form worked, and I saw the other choices in the drop down. I experimented with ACLs before running into the article above.
I had recently adjusted our data integration that pulls in our Customers and Contacts from another system because the data was not accurate and the model did not line up nicely with how ServiceNow's hierarchy works. We simplified mostly removed the hierarchy other than a store to contact relationship, until we can figure out a better way to design it.
So in the end, I decide not to force in an ACL, because I had already adjusted one of the client scripts that was clearing the default user (which was just the logged in user) so that it filled out automatically, and most times that will be the contact anyway. So that fix, and adjusting the reference field to sys_user is the fix we need for now.
Once we build back the hierarchy properly, the partner and admin roles will allow for more options in the contact field.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-24-2023 12:16 AM
Well, I found partial success by switching the reference field to sys_user instead of customer_contact in the reference qualifier settings of the variable field. The field in the portal now shows a value. The problem now is it only shows one value. I've set it up now to test multiple contacts, so it should give me a list but it doesn't. It just gives me the logged in user again. I still think my code is right. It shouldn't really be this hard to do something so simple.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-24-2023 01:31 PM - edited 06-24-2023 01:34 PM
OK, after many hours, I've figured this out. My last post was actually the solution. Switching the "Reference" field, under "Type Specifications" in the Variable setting for "Rest/Act Contact" to "User [sys_user]" allows the drop down to work.
The reason it was NOT showing me multiple users is by design for the CSM portal. See this article..
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0718506
I discovered it was a permissions issue when I gave an external user admin rights and snc_internal to debug the form. When I did that, the form worked, and I saw the other choices in the drop down. I experimented with ACLs before running into the article above.
I had recently adjusted our data integration that pulls in our Customers and Contacts from another system because the data was not accurate and the model did not line up nicely with how ServiceNow's hierarchy works. We simplified mostly removed the hierarchy other than a store to contact relationship, until we can figure out a better way to design it.
So in the end, I decide not to force in an ACL, because I had already adjusted one of the client scripts that was clearing the default user (which was just the logged in user) so that it filled out automatically, and most times that will be the contact anyway. So that fix, and adjusting the reference field to sys_user is the fix we need for now.
Once we build back the hierarchy properly, the partner and admin roles will allow for more options in the contact field.