
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-10-2019 07:59 AM
Hey there SN Comm!!
I am looking to see what (if at all), others might be doing when it comes to allowing people that do not have access to view a Case/are not part of a Case - to be able to email into a Case.
Example:
recently we had a Case that was for one person, and they were the Requestor and Subject Person and Opened By (because they emailed into the system). The assigned to person of this Case, needed to reach out to the Requestor's manager. They did so, via emailing them from the Case itself. The manager then replied to that email from the Case. However, since they are not apart of the Case, and not in any assignment group from the system, their reply never reached the actual Case. It was ignored.
I reached out to SN with a HI Case because I was confused at first. I thought that if someone gets emailed from the actual Case, they would be able to reply and their reply would be posted to the Case. SN however, said that since the person being emailed does not have access to the Case (or apart of the Case in any way), that they cannot post anything to the Case - which includes their emails.
I then as a test, added that manager to the watch list, reprocessed their email, and it was posted to the Case.
We do not want to make this a thing, where we keep adding people to watch list, just to allow them to reply back to a Case when they are not actually involved in the Case.
First, does anyone out there know of this issue/scenario? Second, if you know about this, has anyone built anything as a work around? Is there something that can be done for this?
My initial thought was to create an addition field that is like the watch list field, but tie NO Out going emails like the watch list does. The watch list currently sends out emails for work noted AND additional comments, which we do not want. Especially when it is with someone not technically involved in the Case. But just reached out for additional information.
Thanks in advance!
-Rob
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-16-2019 04:53 PM
Hey John,
So yeah - seems like I needed to add the correct .addOrCondition line within the Restrict Query Business Rule. I tested with a few different tables that I am using this new field on within our HR Cases (COEs). Sure enough, each time I added the dummy account to the new field and sent my email in, the email posted. Once I removed the dummy account from the field, sent in another email, the email was blocked from being posted to the Case. It is a bit strange that the Business Rule would control all of that access, but I guess it does make sense when we really think about it. I was sure that I needed a new ACL, or at least had to modify an OOTB one (as provided by asifnoor). Then we went through also modifying the Include Script. But, turns out it was not needed. But I am glad we went through it, as I definitely learned a lot!
So, here is what was needed for the access:
Modify the OOTB Business Rule 'Restrict Query', with the new field I created (which is a List Field with a reference qualifier)
Here is my new field as a reference:
I hope this helps you, and anyone else - as this entire post has helped me!
Cheers!!
-Rob

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-16-2019 07:42 AM
changed table name within the script include code we did - put the ACL back to the code we did - reprocessed email, getting no warnings, but same errors. But none dealing with our code, still same stuff as I have shown before.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-16-2019 10:41 AM
Okay - I think with both of your help I got it to work! I had forgotten the u_ in the BR for the new field. Once I corrected that to be the correct field value, the email worked. I then took the dummy account off of that field - emailed in again, and it was blocked. Re-added the dummy account again to that field, sent another email, and it was posted.
BR Restrict query on the sn_hr_core_case:
Going to do a little more testing, to make sure this is actually working correctly!
Thanks,
-Rob

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-16-2019 11:07 AM
So - from some testing with this new field, and the added line for the BR. I put the Script Include and ACL back to what they were prior to all the modifications. I took the dummy account out of the new field, sent a new email, and it was blocked. Added the dummy account back to the new field, and the email processed.
This makes me feel very interested, in how just the BR is able to control this access. I thought the BR was for Case Read purposes, which was why we jumped into the Script Include and ACL to control the Case Write access.
Nonetheless, seems to be working with just the modification to the BR.
Anyone able to comment on that?
Thanks,
-Rob

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-16-2019 12:37 PM
Thats very strange that BR is actually restricting the access.
Anyways, glad it worked.
Kindly mark my comment(s) as helpful if it has helped in debugging the issue.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-16-2019 02:14 PM
The BR is a before query so it is filtering the results returned in the query independent of the access the ACLs are granting. In your case, the BR was preventing the case from being returned when searching for the case associated to the email being replied to.