--- title: "Configure data patterns" slug: "bc-configure-data-patterns" description: "Create reusable Data Patterns and Range Expressions for validation rules in D365 BC to ensure data quality and compliance with your standards." updated: 2026-08-05T06:20:52Z published: 2026-08-05T06:20:52Z canonical: "docs.staedean.com/bc-configure-data-patterns" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.staedean.com/llms.txt > Use this file to discover all available pages before exploring further. # 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:** | **Syntax** | **Meaning** | **Example** | | --- | --- | --- | | `^` | Start of string | `^A` - must start with A | | `$` | End of string | `Z$` - must end with Z | | `[A-Z]` | Anywhere Mobility Solutions uppercase letter A–Z | | | `[a-z]` | Anywhere Mobility Solutions lowercase letter a–z | | | `[0-9]` | Anywhere Mobility Solutions digit 0–9 | | | `\d` | Anywhere Mobility Solutions digit (shorthand for `[0-9]`) | | | `+` | One or more of the preceding element | `\d+` - one or more digits | | `*` | Zero or more | | | `?` | Zero or one | | | `{n}` | Exactly n occurrences | `\d{10}` - exactly 10 digits | | `{n,m}` | Between n and m occurrences | | | `\+` | Literal plus sign | | | `\.` | Literal dot | | | ` | ` | OR | | `( )` | Group | `(\d{3}-)` - groups 3 digits and a dash | > [!NOTE] > **Tip** Use an online regex tester such as [regex101.com](https://regex101.com/) or [regexr.com](https://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:** | **Expression** | **Meaning** | **Example** | | --- | --- | --- | | `>0` | Greater than 0 | Credit Limit must be positive | | `>=0` | Greater than or equal to 0 | | | `<0` | Less than 0 | | | `<=0` | Less than or equal to 0 | | | `=0` | Exactly 0 | | | `500..900` | Between 500 and 900 (inclusive) | | | `>40&<75` | Greater than 40 AND less than 75 | | > [!NOTE] > **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: | **Validation Type** | **Pattern Name** | **Pattern Format** | **Description** | | --- | --- | --- | --- | | Data Pattern | CustomerAccount | `^[A-Z][2][0-9][5]$` | Customer account code format | | Data Pattern | Email Address | `^[a-zA-Z0-9_±]+@[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+$` | Standard email format | | Data Pattern | Percentage | `^([1-9][0-9]\|100)$` | Integer percentage 1–100 | | Data Pattern | Phonenumber | `^(\+\d{1,3}[-]?)?\d{10}$` | International phone with optional country code | | Range Expression | Number < 0 | `<0` | Must be negative | | Range Expression | Number <= 0 | `<=0` | Zero or negative | | Range Expression | Number = 0 | `=0` | Must be exactly zero | | Range Expression | Number => 0 | `=>0` | Zero or positive | | Range Expression | Number > 0 | `>0` | Must be positive | | Range Expression | PrePaymentRange | `>40&<75` | Between 40% and 75% (exclusive) | | Range Expression | Range | `500..900` | Between 500 and 900 (inclusive) | > [!NOTE] > **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: | **Field** | **Value** | | --- | --- | | Validation Type | Range Expression | | Pattern Name | Credit Limit Range | | Pattern Format | `500..2500` | **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`). | **Field** | **Value** | | --- | --- | | Validation Type | Data Pattern | | Pattern Name | NL Postcode | | Pattern Format | `^\d{4}\s[A-Z]{2}$` | **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](https://regex101.com/) – Interactive regex tester with detailed explanations for each part of the expression - **Regex:** [regexr.com](https://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] > **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.