Data Loader – Validation Rules

Knowledge Base Home

Search the Omeda Knowledge Base

Validation Rules

Many of the Validation rules are shown/hidden based on mapped fields from the input file, so only settings associated with fields in the input file will be display in the Settings Step.  To view all available settings click the Available Settings button. This can be found at the bottom of the Settings Step in mapping and will show the user all Available Settings, the definition and what fields are necessary to show or hide that particular setting.

Name

Category

Description

Name

Category

Description

Auto Cleanup

General

Removes invalid characters such as @\ digits $ () from contact information.  This setting can be toggled on and off by both internal (Omeda) and external (Client) users.

Reject New Customer

General

This rule is designed as general measure to stop new customers from being generated as part of processing a file. Only
existing customers will be processed.  If no match is found based on the selected matching rules, the record will be added as new, unless Reject New Customer setting is checked.

Vulgarity

General

Checks for vulgar terms within name and contact information.

Junk Names

Customer

Checks the incoming name fields and will reject any name that has no vowels, over 6 consecutive consonants, repeating letters or is on a list of specific names that have marked as junk (e.g. First or last name is ‘Test’)   Requires at least one of the following fields to be mapped: First Name, Last Name

Customer Id must already Exist

Customer

Checks to see if the provided value for the mapping resolves to an existing customer. If it does not, the row will fail validation.
Requires at least one of the following fields to be mapped:
Customer Id, Encrypted Customer Id, or Postal Address Id

Customer Id Required

Customer

Checks to see if the provided value for the mapping is blank or otherwise empty. If it is, the row will fail validation. If this rule
is used without the “Customer Id must already Exist” rule and the provided value does not match an existing customer, then
a new customer will be created.
Requires at least one of the following fields to be mapped:
Customer Id, Encrypted Customer Id, or Postal Address Id

Customer Id Fill Test

Customer

Checks to see if the provided Customer Id and the first 2 letters of the first name and last name all match the existing customer. If yes, it will pass, if not, the row will fail.
Requires the following fields to be mapped:
Customer Id, First Name, Last Name

External Id must already Exist

Customer

Checks to see if at least one of any mapped External Customer Id can be found on a customer. If it can be, then that the
existing customer will be used. If none of the values to the mapped namespaces exist for that customer and would thus
result in a new customer, the row will fail and no new customer will be created.
Requires the following field to be mapped:
External Customer Id

Incoming Name Matches Existing Customer Id

Customer

Checks to see if the name and customer_id on the incoming file match the existing name and customer_id in the database.   If they do not match the error will show on the File State screen under ‘Row Errors’
Requires the following field to be mapped:
External Customer Id

Validate Customer Name

Customer

Checks Salutation, Suffix, First, Middle & Last Name for non-alpha characters.
Requires at least one mapping of any of the following fields:
Salutation, Suffix, First, Middle or Last Name

Validate Gender

Customer

Valid Values are: F, M, 1, 2 & Blank
Requires the following field to be mapped:
Gender

Email Address Required

Email

Checks to make sure at least one email address is present for the row.
Requires at least one mapping of the following field:
Email Address

Invalid Email Address Format

Email

Verifies email address is well formatted & does not start with spam, abuse, postmaster or hostmaster.
Requires at least one mapping of the following field:
Email Address

Postal Address Required

Postal

A slightly more in-depth check to see if a postal address is present for the row. This rule also requires at least some data to
be present in enough Postal Address related fields to make it a decently complete address. If any field isn’t mapped and this
rule is used, the row will fail.For example, if all of the below required fields are mapped except City, all of the rows will fail.
Requires all of the following fields to be mapped:
At least 1 from Street, Apt/Suite/Mail Stop, or Extra Line; City; Region Code; Postal Code; and Country Code

Valid Country Code

Postal

Verifies that the Country Code matches the Country specified.  Data Loader will populate Country Code when files are processed containing the correct Country Name and the same will be true in reverse. If a file contains the accurate Country Code, Country Name will be populated.

Valid USA Postal Code

Postal

Verifies that the postal code matches the state & should be 5 or 9 digits.

Mexican State Required

Postal

Verifies that the Region Code/Name is present for a Mexico Address

Valid Canada Postal Code

Postal

Verifies that the postal code matches the Canadian postal code format.

Phone Required

Phone

Checks to make sure at least one phone number is present for the row. If, for example, both Phone Number and Fax Number
are mapped and the row only has Fax Number, the rule will be considered a Pass.
Requires at least one mapping of any of the following fields:
Phone Number, Fax Number, Pager Number, Mobile

Valid US Phone Number

Phone

Verifies that US phone numbers contain 10 digits

Matching Rules

Name

Category

Description

Name

Category

Description

Customer Matching-Lookup – Name + Address

Match

Use this matching-lookup to find an existing customer using Name and Postal Address elements. Non-matched rows will be ignored by default. Can be used with other Matching-Lookups. Requires the following fields to be mapped (for best results, use as many as possible): Any version of the Name fields, at least 1 from [Street, Apt/Suite, Extra Address], City, Region Code, and Postal Code

Customer Matching-Lookup – Name + Email

Match

Use this matching-lookup to find an existing customer using Name and Email Address elements. Non-matched rows will be ignored by default. Can be used with other Matching-Lookups. Requires the following fields to be mapped: Any version of the Name fields and Email Address

Customer Matching-Lookup – Name + Phone

Match

Use this matching-lookup to find an existing customer using Name and Phone elements. Non-matched rows will be ignored by default. Can be used with other Matching-Lookups. Requires the following fields to be mapped: Any version of the Name fields, and any Phone-related Field

Exact Email Match*

Match

Use to perform to look for an existing customer with provided Email Address. If multiple customers are found this way, the most recently created one will be used. Requires the following field to be mapped: Email Address

Process non-Match as Add

Match

Instead of ignoring the Non-Matched information, a new customer will be created. Only used in conjunction with any “Matching-Lookup” settings

Fail Too Many Matches

Match

If matching finds more than one customer to match, use this setting to prevent it from picking one and instead fail the row. Only used in conjunction with any “Matching-Lookup” settings

*If any of the Customer Matching-Lookup rules have been selected, they will take priority over Exact Email Match if the file contains the following fields:

  • Customer Id

  • Encrypted Customer Id

  • Postal Address Id

  • External Id

Note: If the source file contains multiple records with the same email address and the Exact Email Match is selected, the file will not process the duplicate emails and will instead return errors for each of the rows.

Data Integrity Settings & Rules

These settings and rules are applied to make sure the incoming data doesn’t create an undesirable state that could harm features elsewhere. They can not be turned off and occur when relevant.

Name

Category

Description

Name

Category

Description

External Id tied to Multiple Customers

Customer

If the External Id is being matched on to find an existing customer, if the combination of Namespace and the given External
Id would find more than one customers, the column will be marked as an error. Data Loader won’t know which to pick.Most External Ids shouldn’t resolve to multiple customers, but on the off chance that the data exists in such away, this validation
helps in preventing data from being applied in a potentially undesirable way.

External Ids find Mismatching Customers

Customer

If a file has mapped multiple External Ids that are being used to look for a single customer and if the row being processed would
have values that would resolve to different customers then the row will error. If only one of them was the matched one, Data Loader
would assign the unmatched one to the matched customer when it already belongs to someone else. This helps to remove that case.

External Id Already Taken

Customer

If a new Customer were to be created for the row and there exists External Ids for an existing Customer, the row will error. If this were
to not error, the new Customer would gain the External Id as well, which would cause two Customers to have the same External Id.This only occurs when a namespace is chosen to lookup a Customer and there are multiple External Ids in the file.For example, External-A1 is being used for lookup, but for this row it is a new External Id. The same row has External-C2 which belongs to
a different customer and is not being used to lookup. Since External-C2 isn’t being used for lookup, but belongs to a different customer, an
error will be marked accordingly.