- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-11-2012 02:38 AM
Hello,
I have a problem with inbound actions. This is the case: multiple users have same email address and one of the users is locked out or inactive. When an email is sent from this email address, the system randomly maps the email address to one of the users in the system. If the user is locked out or inactive, then all the inbound actions are skipped. I would like the system to map the email address to active user rather than inactive one. I know that the user's email address should be unique in ServiceNow but these users are coming from AD and I can't do much about it.
I tried to create before business rule in the 'sys_email' table and change the user but this has no affect to the user through which the inbound actions are run. Only solution I can think of is to change the inactive user to active in the before business rule but this doesn't seem a sustainable solution.
This behavior occurred when we updated the instance to the Berlin release. Therefore I would like to know what options do I have? Is there a property that controls this behavior or can I somehow control the user mapping of the email?
All help is appreciated!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-25-2013 07:31 PM
The solution we implemented was to create a before business rule on the Email table that runs when the type is "received", the mapped user is inactive, and the mapped user's email is not blank. If this condition is met we query the User table to find if an active user exists with the same email address and then set the email's mapped user to this active user.
Name: Check for Inactive User
Table: Email [sys_email]
When: before
Insert: true
Condition: current.type == 'received' && current.user_id.active == false && current.user_id.email != ''
Script:
var grUser = new GlideRecord ('sys_user');
grUser.addQuery('email', current.user_id.email);
grUser.addActiveQuery();
grUser.orderBy('sys_created_on');
grUser.query();
if (grUser.next()) {
current.user = grUser.sys_id;
current.user_id = grUser.sys_id;
}
Hope this helps!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-12-2012 01:27 AM
Checking the inbound rule for both "Create Incident" and "Create Incident (Forwarded)", it runs gs.createuser() to check to see if a user exists.
I have had a quick look for the script but couldn't find it though I know I have looked over it before. If you can find that, I am sure you can amend it to ensure it looks up only active users or if it finds an inactive one, get it to look again but not including the one it just found.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-12-2012 10:03 AM
Thank you for your response.
Yes, our previous implementation did this. It sorted users based on their activity/inactivity in the inbound action (inbound rule) but since the Berlin release the system assigns the mail to a user before the inbound actions are run. If the user is inactive, all the inbound actions are skipped. Now I'm trying to find out how to control this assignment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-12-2012 12:42 PM
Had another look for the createuser() function but can't seem to find it. You could always just right your own BR and ref this instead?
I have only developed on Berlin but remember reading the release notes on this. You could always go tell your users to have a unique email address? Though I am sure it is easier just to write the script 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-05-2013 03:23 AM
Hi,
After our recent Berlin upgrade, we have encountered this issue. We have valid scenarios in which the same email id is assigned to multiple users and one of the user records may be inactive. We do not want to delete the inactive user records as there are many incidents and other CIs associated to the inactive user record and we do not want to loose this data.
What should we do in order to ensure that Servicenow goes through the list of active user records instead of stopping the execution just by finding one inactive record?
Regards,
pravTel