Inbound Actions using subject to match with existing ticket if no watermark nor record number?

[desertmoxie1]

Scenario: an external customer sends an issue to a designated mailbox (which is forwarding to ServiceNow for Inbound Action) to create a case. The external customer includes other customers who reply all with "I'm having same issue!". Because we are sending a confirmation to the initial sender, the other "I'm having same issue!" customers won't know that a case was just opened in ServiceNow, so we'd end up creating a distinct case for everyone who replies all with "I'm having same issue!".

Previously, the internal department who requires this functionality built something in Jira ITSM to accommodate finding a match in the subject line (accommodating RE:) by creating a custom table to store the email subject & make the connection to an existing case based on the subject while performing the Jira equivalent of inbound action to add these replies to the same case rather than creating new cases.

Has anyone successfully built such a scenario in ServiceNow using Inbound Actions?

[SasiChanthati]

Yes, your scenario can be successfully implemented in ServiceNow using a combination of Inbound Email Actions, custom logic (possibly Script Includes or Business Rules), and a custom table or matching strategy for subject lines. It’s not an out-of-the-box feature, but here's a pattern that mirrors what your Jira setup did, adapted to ServiceNow.

High-Level Solution Architecture

Create a custom table to store a normalized version of the original subject lines (no RE:, FW:, etc.) and associate them with the corresponding case number.

Modify your Inbound Email Action to:

• Normalize the subject line of incoming emails

• Check the custom table to see if there's an existing match

• If match found → append to existing case

• If not → create new case and store the normalized subject

Implementation Steps

Custom Table for Subject Tracking

Create a table u_subject_case_link:

• u_subject_key (String): normalized subject

• u_case (Reference): the related case (or incident/task)

Optional:

• Store u_original_subject, u_created_by, etc.

Inbound Email Action Logic

Customize or create a new Inbound Email Action:

(function runInboundActionEmailProcessing(email, action, event) {
var normalizedSubject = email.subject.toLowerCase().replace(/^re:\s*/i, '').replace(/^fw:\s*/i, '').trim();

// Query the subject-case mapping table
var subjectGr = new GlideRecord('u_subject_case_link');
subjectGr.addQuery('u_subject_key', normalizedSubject);
subjectGr.query();

if (subjectGr.next()) {
// Found a match → Update existing case
var caseGr = new GlideRecord('sn_custom_case'); // Your case table
if (caseGr.get(subjectGr.u_case)) {
// Add comment or update
caseGr.comments = "Reply from: " + email.origemail + "\n\n" + email.body_text;
caseGr.update();

// Prevent new record creation
action.setAbortAction(true);
}
} else {
// No match → Let Inbound Action create a new case

// After creation, store the mapping
action.setPostProcessing(function(newCase) {
var newSubjectLink = new GlideRecord('u_subject_case_link');
newSubjectLink.initialize();
newSubjectLink.u_subject_key = normalizedSubject;
newSubjectLink.u_case = newCase.sys_id;
newSubjectLink.insert();
});
}
})(email, action, event);

Edge Case Considerations

• Handle different encodings or prefixes (Fwd:, RE: in other languages)

• Strip ticket numbers if they’re appended to the subject later

• Consider tokenizing subject to catch similar wording (optional advanced)

Security & Permissions

Ensure users have access to update or read from u_subject_case_link. Scoped app? Add cross-scope privileges as needed.

Bonus: Confirmation Notification

Send a confirmation back to secondary email senders when their reply was appended, not a new case.

Scenario Flow

• Customer A sends: “App is crashing on login” → new case is created, and subject "App is crashing on login" is stored.

• Customer B replies-all: “I'm having the same issue!” → subject is normalized and matched → no new case is created, but a comment is added to existing one.

Tip: Logging for Debugging

Add gs.info() or gs.log() statements inside your script during testing to verify matching behavior.

This kind of logic is totally achievable in ServiceNow and has been implemented successfully in orgs for ticket deduplication. It gives your support team threaded context and prevents case flooding from mass emails.