Unable to process Inbound email action on emails received from inactive and locked out accountsIssue <!-- div.margin { padding: 10px 40px 40px 30px; } table.tocTable { border: 1px solid; border-color: #e0e0e0; background-color: #fff; } .title { color: #d1232b; font-weight: normal; font-size: 28px; } h1 { color: #d1232b; font-weight: normal; font-size: 21px; margin-bottom: 5px; border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: #cccccc; } h2 { color: #646464; font-weight: bold; font-size: 18px; } h3 { color: #000000; font-weight: bold; font-size: 16px; } h4 { color: #666666; font-weight: bold; font-size: 15px; } h5 { color: #000000; font-weight: bold; font-size: 13px; } h6 { color: #000000; font-weight: bold; font-size:14px; } ul, ol { margin-left: 0; list-style-position: outside; } --> When emails are sent to the instance from a user account which is - a) Inactive - The syslog_email entry for the received email indicate - 'Skipping <Inbound Action>, User <User Name> with email <User email ID> is inactive b) Locked Out - The syslog_email entry for the received email indicate - 'Skipping <Inbound Action>, User <User Name> with email <User email ID> is locked out c) Inactive and Locked Out - There are syslog_email entries for inactive and locked out user as above. and therefore the inbound actions do not process the emails. ReleaseApplicable to all releasesCauseThis is based on how inbound actions work when emails are received and processed by the instance. When an email is received by the instance, the system searches for a matching email record in the sys_user table. If found, ServiceNow instance then impersonates as that user and runs the relevant inbound action steps. If the user is not found, then the instance uses the Guest user to complete this action.ResolutionCase 1: When the user is inactive When the user is inactive, then the inbound email actions will NOT process for the user. The log entry will indicate inbound action getting skipped. Case 2: When the user is Locked Out Inbound email actions can be triggered for Locked out users by enabling a system property - glide.pop3.process_locked_out . The user must still be active. Note: Customers are requested to keep in mind the security implications of allowing users from untrusted domains, and why they were locked out before allowing emails from them to trigger inbound email actions. Case 3: When the user is Inactive and Locked Out Even if the system property from Case 2 above is enabled, the syslog_email entry will still indicate that the inbound email actions could not be processed because the user is inactive and NOT process for the user. The log entry will indicate inbound action getting skipped.