Inbound Email Action did not create or update interaction using current

 

<Inbound Email Action> : did not create or update <table name> using current

This inbound email action issue can consume your reasonable amount of time, may be, sometime in hours, if underlying root cause is not known. Similar kind of problem can occur for any ServiceNow table for which the inbound email action has been defined. Considering, we need to make changes and perform unit testing in ServiceNow non-production or sub-production instances prior to moving the final tested solution to Production instance.

Before we even discuss different scenarios and their possible solution, we should make a note that by the time we actually identify the cause, it will really test our patience considering non-production instances may not have same setup of trigger conditions like production wherein the inbound email action actually trigger based on auto forwarding DLs (Distributed Email) or any production email to which we can't send and test in non-production instance. As we all know, business users email ids can't be used for testing purpose. So, this means we need to simulate the trigger condition so that it can trigger and we can test the issue in non-production instance.

Scenarios: "did not create or update <table name> using current"

Now, lets consider different scenarios which can contribute this inbound email action issue. While we proceed on each scenarios, please note that whenever this issue occurs, our inbound email action actual script logic may not work properly and the required objective of the inbound action will not get fulfilled. We can come across the issue of "<Inbound Email Action> : did not create or update <table name> using current" during following possible scenarios.

1. Code Issue in Action script:

In this case, code issue can be related to any attribute being accessed through "GlideRecord" object. For example, let say, "comments" field is being accessed for Interaction table although, out of box "comments" is not available as Interaction table is not inherited from Task table. It might also occur due to improper use of out of functions related to ServiceNow API, for e.g. using ".update" instead of ".update()". So, this type of root cause, can be identified in less time and it depends on your coding skills and relevant experience in handling similar scripting issues.

2. Role or Condition Issue:

The inbound email action can be triggered for the test emails planned to be sent to any particular test email id, for example, directing to ServiceNow instance email id as recipient. But prior to that, we ensure the configuration of System Email properties for the Inbound Emails are properly enabled and values set for required properties. Having said that, now the question is, user who will send the test email, need to be a valid user with proper roles in ServiceNow user profile (sys_user table). This point is important when Inbound Email Action has dependency on any particular role. So, it means sender user id must have that respective role as a pre-requisite.

 Secondly, condition(s) configured to trigger the inbound email action should be appropriate, so that it don't conflict with any other inbound email action. In case, there is any known inbound email action having same matching condition, in non-production instance, it can be modified to remove the conflict. Let say, additional condition on subject text can filter out the trigger condition in order to only fulfill your inbound action during unit testing or QA. Otherwise, email log can show either your inbound email action was skipped due to mismatch in the condition or this error as "did not create or update using current".

3. Condition conflict with another Inbound Email Action on same or another table:

This scenario is similar to above discussed second scenario. The only difference is that condition criteria, of any other unknown inbound action, can have conflict with your inbound action. So, in this situation, the troubleshooting can be time consuming as we have to investigate and identify which all other inbound email actions have trigger condition same as yours.

 You can start with checking the email log of the email record which was created when we sent the test email. Scrolling down below the email log message, you can find the filter wherein you can filter out all logs where it contains "Skipping". This will filter out skipped message logs and only show logs relevant to the inbound email actions where condition conflict may exist and were picked for processing at that point of time. There can be chance that the logs shows more than one record with the issue of "did not create or update using current". You must note down the inbound action names other than your inbound action.

 On case by case basis, you can update the conditions temporarily to strike out all possible options which are responsible for condition conflicts and retest. Eventually, in the end, you will see your inbound action start triggering properly and actual logic perform correctly. This exercise is not applicable for Production instance as ideally all inbound email actions have genuine email DLs or business users recipient list working in line with that particular process.

4. Format or data issue in Attached file (used as input to a data source):

This scenario involve more steps in unit testing from end to end. Since Inbound Email Action script references a scheduled import record which in turn mapped to data source. Now, in this kind of setup, most of the time scheduled import possibly remain inactive until it gets activated by acknowledgement of inbound email action. So, we can say, scheduled import is in sleep mode and it gets active as soon as an email is received to process the attached file via that Scheduled Import. Now the inbound action script might pass on the attachment to the data source and the source file gets processed based on transform map logic underlying respective staging table to target table. Here, we are not considering Robust Transformer. However, if situation demands, that sort of implementation is also feasible. But such requirements are not frequent.

 Now, coming back to inbound email action wherein the attached file is passed on to data source, this overall logic involves processing of the file and we are talking to about specially Excel or CSV file. The reason is, primarily a formatting problem with the file, as the required data expects structured format in terms of sheet number and row number as per data source setting. But, if the actual data lies in sheet other than required tab, then it may not process. Secondly, it will not process even if data starts from any other row and have a mismatch with expected header row which specifies column names mapped with staging table. Eventually, the file may not get processed. On the top of this, unnecessary new columns might get created in staging table based on file formatting issue.

 The overall impact happens to the inbound email action result which doesn't show success and, also the email log shows that it is not processed successfully with error message as "did not create or update using current" for that particular table. As solution, we need to ensure, file formatting is correct and data starts from correct header row. Same details matches with the configuration of related data source and file type.

5. Referenced table record issue in Action script:

This kind of cause is very tricky as we can't count it as logical issue, but underlying data problem with referenced attribute for any table used in Action script. Most common situation, is like, we use GlideRecord on any table for example Incident, Interaction or Change Request etc. for update or insert activity.

Let say, we are setting choice option value for any attribute, but somehow that option is not active. Since, there is data discrepancy, it don't restrict creation or updating of the related record in target table. Perhaps, in that script, there are chances you are also using GlideRecord API functions for example, updateWithReferences() or insertWithReferences() to keep reference tables data in synch with Inbound Email Action table. 

This scenario can lead to confusion wherein we can't conclude if everything look good or there lies any problem. To avoid this discrepancy, we should ensure our choices or referenced data is inline with our logic which we are referring in our code. 

In case you have error handling scripts, it will be quick help and effective troubleshooting technique to drill down to the actual data point. By the way, in general we should have proper error handling in all the scenarios mentioned above.

Hope this article might have helped you in any manner to understand the root cause for Inbound Email Action issue related to "did not create or update using current".  Secondly, if there are any additional scenarios for which same issue occurs, your inputs will be a value add on this forum. If any suggestions, please feel free to add in comments to improve in right direction! ✌️😊