Inbound Action - Assign only works if Assignment Group is included
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-11-2022 12:27 PM
We have an Inbound Action configured to create incidents from incoming emails and it's working well unless we attempt to use assign:without also using assignment_group:.
So our choices are to not use assign or to include the assignment group if we do. As you can guess, our users aren't super fond of that option.
If I look in the logs, I can see that it tries to create an incident, but the incident isn't anywhere that I can find.
Example log entry: Information Processed 'Create Incident', created incident :INC0012021
Here is the relevant portion of my script. It works, as long as assignment_group is present.
if(email.body.assign != undefined){
if (email.body.assign.indexOf('<mailto:')){
var assignsplit = email.body.assign.split('<mailto:')[0];
gs.log("email body assign: " + assignsplit);
current.assigned_to = assignsplit;
} else {
gs.log("email body assign: " + email.body_text.assign);
current.assigned_to = email.body_text.assign;
}
}
if(email.body.assignment_group != undefined){
gs.log("assignment : " + email.body.assignment_group.trim());
current.assignment_group.setDisplayValue(email.body.assignment_group.trim());
}
I've been tinkering with the Dictionary settings as I suspect they might be the culprit, but so far nothing I've tried has provided resolution.
Does anyone have any suggestions?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-11-2022 12:41 PM
Hello,
The assigned to field is expecting a sys_id as it's a reference to the sys_user table.
Unfortunately, you didn't provide us an example of an inbound email, just so we can see what all is going on, and you did your own assessment and also only provided us what you felt was relevant as far as the script goes.
The fact that the inbound action attempts to create the incident, regardless of assignment field there is not, means the inbound action is processing through and the result is a new incident (thus you're receiving a number for it, and if you go to your email log, you'll see the target actually contains a sys_id there, but no real record).
The reason for this would be something that happens AFTER the inbound action is processed.
Whether that's a system action or business rule, etc. it may come down to permissions.
Have you reviewed the user who is sending this in and verified what they're sending is appropriate and per your setup.
As I'm sure you're aware, the assigned_to field is dependent upon the assignment group field and there is an out of box reference qualifier as well. Do those test successfully meet that criteria? And again, the from user is being identified in that inbound action transaction in the email log?
Please mark reply as Helpful/Correct, if applicable. Thanks!
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-11-2022 01:52 PM
Sorry Allen. I have a tendency to provide too much information, so I try to avoid overloading people.
There's not really much to show by way of examples.
This does not create an incident:
assign:person@email.com
This does create an incident:
assign:person@email.com
assignment_group:Assignment Group Name
It doesn't matter what the rest of the email body contains. If I don't attempt to use assign: the incident is created.
Thanks for your insights. I will look at business rules and processes that run after the inbound action has processed.
Unfortunately, I'm the one sending the emails, so I can't attribute it to user error.
Yes, the from user is being correctly identified in the log and assigned as the caller when incidents are created.
Thanks for the ideas.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-14-2022 07:25 AM
Hi,
Thanks.
I'm glad you've reviewed the downstream processes as I had mentioned above that would most likely be causing this issue AFTER the system was trying to insert the record and providing you with a "ghosted" sys_id in your email log target field.
If you need any further assistance, definitely let us know.
If my reply above helped also guide you Correctly, please also mark as Correct.
Thanks and take care! 🙂
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-11-2022 12:42 PM
Hello
When you say you are tinkering what things yu have tried ?
Did you try to remove the dependant fiekd of assign and tried?
Thanks