Avoid Duplicate Logical Cases

Overview

Some workflows receive multiple documents, emails, or updates that refer to the same real-world business item. In those workflows, the goal is not always "one input equals one case." The goal is to identify the logical case the input belongs to.

To do that, define a business identifier on the agent case schema and make it easy to search. Reviewers and operators can then use case search to find the existing logical case before deciding whether a new case is needed.

Questions This Article Answers

• What is a logical case?
• What is a business identifier?
• How should business identifiers be defined in the case schema?
• How does case search help prevent duplicates?
• What should users do when a possible duplicate is found?

Logical Case vs. Reindeer Case ID

Reindeer assigns a case ID to each case created in the system. That ID is useful for opening and referencing a specific Reindeer record.

A logical case is the business item your team is trying to manage. It may be represented by an invoice, claim, order, shipment, customer request, financial transaction, or another business object.

For duplicate prevention, the business identifier is usually the most important value for users. It tells them whether two inputs refer to the same logical case.

Define the Business Identifier

Every workflow that can receive repeat, revised, or related inputs should define the field or combination of fields that identifies the logical case.

Good business identifiers are:

• Meaningful to users.
• Stable across updates and resubmissions.
• Present early enough for review or routing.
• Specific enough to separate different business items.
• Searchable in Reindeer.
• Included in the case schema and shown in the case UI.

Examples:

If one field is not enough to uniquely identify the logical case, define a compound business identifier. For example, invoice number alone may not be enough if different suppliers can use the same invoice number.

Put the Identifier in the Case Schema

The business identifier should be part of the agent case schema, not only visible in the source document. This allows Reindeer to display, search, review, and report on the value consistently.

Recommended schema fields:

• A primary business identifier, such as cross-charge number or invoice number.
• Supporting fields needed to disambiguate the identifier, such as supplier, company code, period, customer, or region.
• A display-friendly case title that includes the identifier when helpful.
• A duplicate or related-case status if reviewers need to track possible matches.
• A reviewer decision field for merge, ignore, continue, or create new case decisions.

Use the same names and formatting across the workflow. If users search for an identifier with leading zeros, punctuation, or prefixes, keep the display and search value consistent.

Use Case Search Before Creating or Continuing a Case

When a user or process receives a document that may refer to an existing logical case, search for the business identifier in Reindeer.

Recommended review pattern:

1. Identify the business identifier from the incoming document, email, or record.
2. Search for that identifier in the relevant workspace and agent.
3. Compare any matching cases using supporting fields such as date, vendor, amount, period, or company code.
4. Decide whether the input belongs to an existing logical case or should create a new one.
5. Record the decision using the workflow's standard review fields.

This approach works especially well when repeat documents are expected, such as revised invoices, supporting documents, follow-up emails, or corrections for an existing charge.

What Counts as a Match

Define match rules before users begin reviewing cases. The rules should be specific enough that different reviewers make the same decision.

For customer-facing workflows, avoid relying on visual similarity alone. Use the defined business identifier first, then supporting fields.

When Not to Reuse an Existing Logical Case

Do not treat an input as a duplicate just because it looks similar.

Create or continue a separate case when:

• The business identifier is different.
• The same supplier or customer sent a different transaction.
• The identifier is reused for a different period or company code.
• The new input represents a separate adjustment, correction, or reversal.
• The workflow requires one case per document even when business references match.

The goal is to prevent accidental duplicate logical cases, not to collapse separate business events into one record.

Recommended Configuration Checklist

Before rollout, confirm:

• The business identifier is defined for the workflow.
• Reviewers know which field or field combination identifies the logical case.
• The identifier appears on the case page.
• The identifier is searchable.
• Supporting fields are visible for comparison.
• The case title includes the identifier when that helps users scan results.
• There is a documented action for exact, likely, weak, and no-match results.
• Duplicate or related-case decisions are captured on the case.

Common Mistakes

• Using the Reindeer case ID as the business identifier.
• Expecting a filename or upload timestamp to identify the logical case.
• Searching by only one field when the business process requires two or more fields.
• Hiding the identifier from the case view.
• Allowing different teams to format the same identifier differently.
• Treating every matching invoice number, order number, or charge number as a duplicate without checking supporting fields.

Reporting Duplicate Logical Cases

When reporting duplicate logical cases to Reindeer support, include:

• Links or IDs for the Reindeer cases.
• The business identifier shown on each case.
• The supporting fields used to compare the cases.
• The source documents or emails involved.
• Whether users expected the input to attach to an existing case or create a new one.
• The search terms used and the results returned.

This helps determine whether the issue is a schema issue, a search/display issue, an ingestion issue, or an operating-procedure gap.

Related Articles

• Manage an Agent Case Schema
• Understand Case Fields and Views in Reindeer
• Review and Correct Case Information