Matching and record identification

Matching and record identification are core concepts in iDMS that determine how incoming data is applied to records in iMIS. Whether you are importing data, updating records, or running automated workflows, matching ensures that the correct records are inserted, updated, or left unchanged.

Understanding how matching works is critical to preventing duplicate records, incorrect updates, or unintended data changes.

In This Article 

Understanding matching

Matching is the process of identifying which record in iMIS corresponds to a row of incoming data. iDMS uses one or more fields (called match criteria) to determine whether a record already exists.

Based on the result of matching, iDMS will do the following:

  • Insert a new record if no match is found
  • Update an existing record if a match is found
  • Skip or error if multiple matches are found (depending on configuration)

Record identification in iDMS

Record identification refers to the specific fields used to uniquely identify a record in iMIS. Choosing the correct identifiers is essential for accurate matching.

Common identifiers include:

  • iMIS ID – The primary identifier for a contact
  • ContactKey – A unique system-generated identifier
  • SEQN – Used for identifying specific activity records
  • Ordinal – Used for identifying panel data rows

Note: Whenever possible, match on unique identifiers such as iMIS ID or ContactKey to ensure accurate results.

Types of matching

The following are the types of matching.

Exact Matching (Key-Based)

Exact matching uses unique identifiers (such as iMIS ID or ContactKey) to locate a single record.

  • Most reliable method of matching
  • Recommended for updates and integrations
  • Minimizes risk of duplicates or incorrect updates

Field-Based Matching

Field-based matching uses non-unique fields such as name, email, or other attributes.

  • Useful when unique identifiers are not available
  • Requires careful configuration to avoid incorrect matches
  • May result in multiple matches if not specific enough

Composite Matching

Composite matching uses multiple fields together to uniquely identify a record.

  • Combines fields such as First Name + Last Name + Email
  • Improves accuracy when a single unique field is not available
  • Commonly used in file-based imports

Matching behavior by module

Matching may depend, based on the iDMS module you are using.

iImport

  • Matching is configured using file columns
  • Supports matching with or without iMIS ID
  • Can use “Insert with Matching” when IDs are not available

iUpdate

  • Matching is typically defined within the IQA query
  • Query results determine which records are updated
  • More controlled and precise than file-based matching

iWorkflow and iTransfer

  • Matching may occur as part of actions or integrations
  • Often relies on identifiers passed through workflows or APIs

Handling matching outcomes

When iDMS evaluates matching criteria, several outcomes are possible:

  • Single match found – The record is updated
  • No match found – A new record may be inserted (depending on action)
  • Multiple matches found – The job may skip, error, or require configuration changes

These behaviors can often be configured using task options.

Best practices for matching

The following are best practices for matching:

  • Match on unique identifiers whenever possible
  • Use multiple fields when unique identifiers are not available
  • Avoid broad matching criteria (for example, matching only on Activity Type)
  • Test jobs with small datasets before running in production
  • Review task options to control behavior when multiple matches are found

Common pitfalls

The following are common pitfalls related to matching:

  • Matching on too few fields, resulting in unintended updates
  • Using non-unique fields without additional criteria
  • Overwriting data due to incorrect match configuration
  • Creating duplicates when matching is not properly defined