Inbound Email Action did not create or update interaction using current

This error can eat hours of your time if the underlying cause isn't obvious, and it can show up for any table that has an inbound email action defined against it. Since testing usually has to happen in a non-production or sub-production instance before the fix moves to production, there's an added wrinkle: your test environment likely doesn't have the same trigger setup production does — production inbound actions often fire from auto-forwarded distribution lists or real business-user emails you simply can't replicate for a test. That means you'll usually need to simulate the trigger condition to reproduce the issue safely.

Scenarios That Produce This Error

Whenever this error shows up, it generally means the inbound email action's script logic never actually reached current.insert() or current.update() — the record was never saved, so the platform reports it as "did not create or update using current." Here are the situations most likely to cause it.

1. Code Issue in the Action Script

The most straightforward cause: something in the script references a field or method incorrectly. A common example is referencing a field like comments on a table that doesn't actually have it — for instance, the Interaction table isn't extended from Task, so Task-specific fields aren't automatically available on it. Another common mistake is calling a GlideRecord method without the parentheses (.update instead of .update()), which silently does nothing rather than throwing an obvious error. These are usually the fastest to diagnose if you're comfortable reading through the script line by line.

2. Role or Condition Issues

Inbound email actions can depend on the sending user having a specific role on their sys_user record. Before assuming the script itself is broken, confirm:

• The System Email properties for inbound email are correctly configured.
• The user account associated with your test email address actually exists in ServiceNow and holds any role the action's condition requires.
• The action's trigger condition is specific enough that it doesn't accidentally get intercepted by an unrelated inbound action with a broader or overlapping condition.

If the condition is too broad, you may see the action get skipped entirely, or see this same "did not create or update" error even though your action wasn't the one that actually ran.

3. Condition Conflicts With Another Inbound Email Action

This is a variation of the above, but harder to trace: a different inbound email action — one you may not even know exists — has a trigger condition that overlaps with yours, and it's intercepting the email first.

To investigate, start with the email log for the test message. Most inbound email log views let you filter for entries containing "Skipping" — this narrows the log down to messages about inbound actions that were evaluated but didn't run, which is usually where a condition conflict shows up. If you see more than one inbound action listed there, note their names so you can compare conditions side by side.

On a non-production instance, it's reasonable to temporarily narrow an action's condition (for example, adding a unique subject-line filter) to isolate it during testing, then revert once you've confirmed the logic works. This isn't something you'd do in production, since production conditions are generally already tuned to match real distribution lists or business processes without conflict.

4. Format or Data Issues in an Attached File (Used as a Data Source Input)

This scenario takes more end-to-end testing to isolate. If the inbound action script hands off an attachment to a scheduled import mapped to a data source, that scheduled import is typically inactive until the inbound action wakes it up to process the incoming file.

The most common failure here is a formatting mismatch in the file itself — usually an Excel or CSV attachment:

• The actual data lives on a different sheet/tab than the data source expects.
• The data doesn't start on the row the data source is configured to expect, so the header row doesn't line up with the columns the transform map expects.

When this happens, the file may not process at all, and you can end up with unexpected new columns appearing in the staging table as a side effect of the mismatched header row. The fix is usually just making sure the file's actual layout — sheet, starting row, column headers — matches what the data source and transform map expect.

5. Referenced Record or Data Issues in the Action Script

This is the trickiest category, because it isn't a logic bug — it's a data problem that the script happens to expose. A common example: the script sets a choice field to a value that exists but isn't currently active. That mismatch doesn't necessarily block the record from being created or updated, but it can produce confusing, inconsistent results that look like a scripting issue when they're really a data issue.

This scenario often comes up alongside insertWithReferences() and updateWithReferences() — GlideRecord methods that create or update a record along with its referenced records in one operation, useful for keeping related tables in sync from within the inbound action script. One important thing to know if you're troubleshooting this: these two methods are only available in the global scope — they don't work in scoped applications. If your inbound email action script lives in a scoped app and appears to silently do nothing when it reaches one of these calls, that's very likely your actual root cause, not a logic error elsewhere in the script.

Proper error handling around all of the scenarios above — not just this one — makes tracking down which of these you're actually dealing with considerably faster.

Wrapping Up

Hopefully this helps narrow down the root cause behind "did not create or update using current" the next time it shows up. If you've run into a scenario not covered here, I'd genuinely like to hear about it — drop it in the comments so it can help the next person searching for the same error.