Configure data patterns

Data patterns are reusable definitions used by Data Pattern and Range Expression validation rules. You define a pattern once in the Validation Patterns Setup page and then reference it by name in as many validation rules as needed. As of now it supports two pattern types: Data Pattern (regex) and Range Expression (BC filter syntax).

Purpose

Create and maintain the library of validation patterns that validation rules can reference. Patterns should be set up before configuring validation rules that use the Data Pattern or Range Expression validation types.

Navigation

Use the Tell Me search (Alt+Q) and type Validation Patterns Setup. Select the result.

The Validation Patterns Setup list page opens, showing all existing patterns with their type, name, and format.

Steps

Create a new pattern

1. Before creating a new pattern, check whether a suitable one already exists. The list shows:

   Column	Description
   Validation Type	Data Pattern or Range Expression
   Pattern Name	The display name referenced in validation rules
   Pattern Format	The actual regex or range expression string

   
   A set of patterns is provided with the Data Quality Studio extension. If an existing pattern meets your requirement, you can use it directly by referencing its name in the validation rule, without creating a new pattern.

2. In the Validation Patterns Setup list, click + New in the action bar.

3. A new row is added. Fill in the following fields:

   Field	Description
   Validation Type	Select Data Pattern for regex-based checks, or Range Expression for numeric range checks
   Pattern Name	Enter a descriptive name (for example: "UK Postcode" or "Positive Number"). This name appears in the Pattern Name lookup when configuring validation rules.
   Pattern Format	Enter the pattern string (see format guidance below)

4. D365 BC saves the row automatically when you move away.

Pattern Format Guidance

Data Pattern (Regular Expressions)

A Data Pattern uses a regular expression (regex) to define the allowed format for a field value. If the field value does not match the expression, the validation fails.

Regex basics:

Tip
Use an online regex tester such as regex101.com or regexr.com to build and test your pattern before entering it in D365 BC. Paste a few sample values to verify matches and failures.

Range Expression (BC Filter Syntax)

A Range Expression uses Microsoft Dynamics 365 Business Central's standard filter notation to define allowed numeric ranges. The field value must satisfy the expression.

Range expression syntax:

Note
Range Expressions follow the same filter syntax used throughout Microsoft Dynamics 365 Business Central's filter fields. If you are familiar with filtering lists in D365 BC, the same notation applies here.

Built-in Patterns

The following patterns are included in the Data Quality Studio starter configuration package delivered with the extension:

Note
These built-in patterns serve as a starting point. You can modify them or create new patterns to align with your organization’s data standards. For example, since phone number formats vary by country, you can define separate patterns for each format you need to enforce.

Examples - Creating and Using Patterns

Example 1 - Email Address (Data Pattern, built-in)

Already included in the starter configuration. To use it:

1. Open Validation Patterns Setup and confirm that the Email Address pattern exists with the format ^[a-zA-Z0-9_±]+@[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+$.

2. On the Data Validations page for the E-Mail field, set Validation Type = Data Pattern and Pattern Name = Email Address.

Passes: john@company.com, info@staedean.com
Fails: john.company.com, @company, john smith

Example 2 - Phone number (Data Pattern, built-in)

Pattern: ^(\+\d{1,3}[-]?)?\d{10}$

Passes: +31612345678, 0612345678, +1-0612345678
Fails: 06-123-456-78 (hyphens not allowed), 061234 (too short)

Example 3 - Credit Limit range (Range Expression, custom)

The built-in Range pattern uses 500..900. If your credit limit range is 500 to 2,500, create a new pattern:

Passes: 500, 1000, 2499, 2500
Fails: 0, 499, 2501

Example 4 - Dutch postcode (Data Pattern, custom)

Dutch postcodes follow the format: four digits, a space, two uppercase letters (e.g. 1234 AB).

Passes: 1234 AB, 9876 ZZ
Fails: 1234AB (no space), 1234 ab (lowercase), AB 1234 (wrong order)

Where to Get Help with Patterns

• Regex: regex101.com – Interactive regex tester with detailed explanations for each part of the expression

• Regex: regexr.com – Visual regex testing tool for building and validating expressions

• D365 BC filter syntax: Test range expressions directly in Anywhere Mobility Solutions D365 BC list's filter row before entering them in Validation Patterns Setup. If the filter works in the list, it will work in Data Quality Studio.

What Happens at Runtime

When a user saves or leaves a field on a Customer, Vendor, or Contact record, D365 BC evaluates Anywhere Mobility Solutions validation rules attached to that field in the active policy version:

1. If a Data Condition is defined - the system checks whether the condition is met. If not, the rule is skipped.

2. If the condition is met (or no condition exists) - the system evaluates the Validation Type:

   • For Data Pattern: the field value is tested against the pattern's regex. If it does not match, the rule fails.

   • For Range Expression: the field value is tested against the filter expression. If it falls outside the range, the rule fails.

   • For Mandatory: the system checks whether the field has a value. If empty, the rule fails.

   • For Blank: the system checks whether the field is empty. If it has a value, the rule fails.

3. If the rule fails, the system responds based on the Outcome:

   • Default Error - standard red error message, save is blocked

   • Custom Error - your defined message in red, save is blocked

   • Custom Warning - your defined message as a popup, user clicks OK to proceed

4. If the rule passes, the user can continue without interruption.

Note
Rules are evaluated on field exit and on record save. They do not affect records that already exist in the system at the time the rule is activated. Retroactive validation of existing data is planned for a future phase.