inbound action not processing when user is inactive

[donkuelbs]

We have a process where a user is inactivatated in most of our internal systems if they have not completed required training within a specific timefram.   The only options open to them are the training system and email.   The ask is to have them complete the training and then send an email stating that it is complete to ServiceNow.   That email will automatically kick off a process to re-enable the users access.

The inbound action works as long as the user is active, but fails once the user is inactivated.   We get a message stating the inbound action is being skipped due to the user being inactive.   We would like to process the email even though the user is inactive.   We can look up the user in the inbound action script and if the user is inactive create the ticket under the id of a service account that we have created for this type of activity.   Our problem is that we can't find where the inbound actions are being skipped.  

Can anyone point us in the right direction on this?   We need to process emails even if the user that sent the email is currently marked as inactive in the system.

Thanks in advance.

[Michael Fry1]

But the business rule should lock the user out. Unless the rule is inactive?

[donkuelbs]

The use case is something like this.

A user does not complete required training by a specified date.   The HR system inactivates the user in the Active Directory.   The ServiceNow system detects that the user is inactive in the AD and inactivates the user in ServiceNow.  

The user now has to go to an external web site, sign in and complete the training.   Once the training is complete the HR department wants to get an email stating that it is complete.   We have some logic in the email eater to detect these specific emails and they will trigger an action to reactivate the user.

There are many better ways that this can be done.   A link from the training system to HR leaps to mind, however that seems to be infeasible so we have been asked to architect this method.

[Dub Myers]

Inbound email actions impersonate and run as the sending user.

Inbound email actions will not execute if the sender is present as a user in the system and that user record is marked inactive.

...unless your guest account is configured so that unrecognized senders still cause inbound email actions to run.

Option 1: Use locked out instead of inactive

If you set 'glide.pop3.process_locked_out', then a user whose record is active, but marked locked out can still send an email and inbound actions will be processed.   Your inbound email action implementing the unlock would then need to locate the user's record from the email address and change the locked out setting.

Option 2:   Let inbound email actions as 'guest' user   ('guest' must be active)

When an inbound email arrives from a user who is not in the system, or is inactive, the system is capable of processing the email as the 'guest' user ( only if if your guest user is itself active).

Prevent untrusted users from triggering inbound actions

Possible security concerns:

You mentioned you would be able to recognize an email to cause the inbound action to trigger.   What is the nature of the email content?   Is there anything in the content (e.g. a token of some kind) that the sender would be supplying that would allow your inbound action to know the sender legitimately completed the training?

Option 3: REST integration

Can the HR system (or training system inform the ServiceNow system this information via a REST call to a Scripted REST API you implement in ServiceNow?   This would be ideal, because the system that 'knows' just tells the system that needs to know what is going on.   Authentication would be handled between the two systems