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.

Activate a policy version and test

Prev Next

Once a policy version has all its validation rules and duplicate check rules configured, the final step is to activate it and verify that the rules behave as expected. This section covers how to activate a version, what "activated" means for end users, and a recommended testing checklist.

Purpose

Activate the configured policy version so that rules begin firing for all users creating or editing Customer, Vendor, or Contact records. Verify that each rule responds correctly before communicating the rollout to end users.

Steps

  1. Press Alt+Q to open the Tell Me search.

  2. Enter Data Policies.

  3. Select Data Policies from the results under Administration.

  4. Click the Policy Table ID for the policy you want to activate. The Data Policy form opens.

  5. In the General section of the Data Policy form, check Version No..

  6. Use the navigation arrows (← →) to switch versions if needed.

  7. Before activating, check the Summary factbox on the right panel:

    Field

    What to check

    Field Validations

    At least 1 field is listed if you added validation rules.

    Duplicate Checks

    At least 1 if you added a duplicate check rule.

    Status Summary

    If it reads "Missing Duplicate Check Rules" or similar, decide whether this is acceptable or whether rules are missing.

  8. In the General section, click the Active toggle to turn it on.

  9. Immedeatly the below changes will take place:

    • This version's state changes to Active.

    • Anywhere Mobility Solutions previously Active version for this policy changes to Inactive.

    • All users creating or editing records in the governed table will now have their data evaluated against the rules in this version.

Warning
Activation takes effect immediately. There is no scheduled go-live time. If you are not ready for rules to fire, keep the version in Draft until you are.

Testing a Policy Version Before Activation

Always test rules in a non-production company or a dedicated test environment before activating them in a live company. D365 BC supports multiple companies, so you can create a test company with realistic data and configure the same policy there first.

Work through each rule type you have configured:

Validation Rules:

  • Mandatory rule: Create a record and leave the mandatory field blank. Save or navigate away. Confirm the error fires with the correct message.

  • Blank rule: Create a record and enter a value in a field that must be blank. Save. Confirm the error fires.

  • Data Pattern rule: Enter a value that does not meet the expected format, for example john.smith in an email field, and confirm that a blocking error is shown. Then enter a valid value and confirm that the validation passes.

  • Range Expression rule: Enter a value below the minimum, for example 400 when the range is 500 to 2,500, and confirm that an error is shown. Then enter a value above the maximum and confirm that an error is shown. Finally, enter a value within the valid range and confirm that the validation passes.

  • Conditional rule (Data Condition): Set the condition field to the trigger value (e.g. Country = US). Confirm the rule fires. Change the condition field to a non-trigger value (e.g. Country = DE). Confirm the rule does not fire.

  • Custom Warning: Trigger a warning rule and confirm that the popup appears with the correct message. Click OK and verify that the record is saved successfully.

  • Custom Error: Trigger an error rule and confirm that a red error message is displayed. Verify that the record cannot be saved until the issue is corrected. After correcting the value, confirm that the record can be saved successfully.

  • Default Error: Trigger a default error rule. Confirm D365 BC shows its standard error message.

Duplicate Check Rules:

  • Basic match - Error outcome: Create a record that matches an existing record on all configured matching fields. Confirm that an error is displayed and the record cannot be saved. Modify one of the matching fields and confirm that the record can be saved successfully.

  • Basic match - Warning outcome: Create a record that matches an existing record. Confirm that a warning popup is displayed. Click OK and verify that the record is saved despite the match.

  • No match: Create a record with values that do not match Anywhere Mobility Solutions existing record on the matching fields. Confirm no error or warning appears.

What End Users Experience

Once a version is active, end users do not need to do anything differently. Rules are evaluated automatically in the background.

Outcome

What the user sees

Custom Error / Default Error

A red error message appears below the field or at the top of the page. The record cannot be saved until the value is corrected.

Custom Warning

A popup dialogue appears with the custom message and an OK button. The user clicks OK and can proceed.

Duplicate Error

The same red error is displayed, and the record cannot be saved.

Duplicate Warning

A popup displays the duplicate message with an OK button, allowing the user to acknowledge the message and proceed.

Users do not see which policy or rule triggered the message. They only see the message you provided, so it is important to write clear and actionable validation messages.

Communicating the Rollout to End Users

Before activating in a live company, consider the following:

  1. Notify affected teams - Inform users who create and edit Customer, Vendor, or Contact records about the upcoming data quality rules and when they will take effect.

  2. Explain the rules - Share a summary of the fields that will be validated and the expected formats. For example, "From Monday, a valid email address is required on all Customer records."

  3. Provide the error messages - Ensure that the validation messages you configured are clear and self-explanatory, as these are the messages users will see.

  4. Set a go-live date - Activate the version during a low-traffic period, such as early morning or the weekend, to reduce the impact of Anywhere Mobility Solutions unexpected issues.

Making Changes After Activation

You cannot edit rules on an Active version. To update rules after a version is active:

  1. On the Data Policy form, click + New to create a new version in Draft state.

  2. Reconfigure the rules on the new version as needed.

  3. Test the new version.

  4. Enable the Active toggle on the new version. The previously Active version becomes Inactive automatically.

This approach maintains a clear history of changes over time and ensures that users always interact with a fully configured version, not a partially completed one.

Tip
The Version No. shown on the Data Policies list reflects the most recent version. The No. of Versions count in the Policy Details factbox tells you the full history. Navigate to each version from the Data Policy form using the arrow buttons to review past configurations.

Summary - Full Configuration Checklist

Use this checklist to confirm that Data Quality Studio is fully configured before going live.

Global Setup

  • Data Quality Studio extension is installed (confirmed via Tell Me → "Data Quality Setup")

  • Data Quality Check toggle is enabled on the Data Quality Setup page

  • Number series are assigned (Validation Condition ID, Duplicate Condition ID, Duplicate Check Nos)

Per Policy (repeat for each governed entity)

  • Policy created for the table (Customer 18 / Vendor 23 / Contact 5050)

  • Version 1 exists in Draft state

Validation Patterns (if using Data Pattern or Range Expression rules)

  • Existing built-in patterns reviewed

  • Custom patterns created and tested (via regex tester or D365 BC filter row)

Validation Rules

  • Fields added to the Field Validation sub-grid

  • Each field has at least one validation rule configured

  • Validation Type, Pattern Name (if applicable), Outcome, and Validation Message all filled in

  • Data Conditions configured for conditional rules (Filter Field, Filter Value, Active = Yes)

  • Rules tested in a non-production company

Duplicate Checks

  • Duplicate Check definition created (Description, Type, Source Table, Fields)

  • Duplicate Check definition is Active

  • Duplicate Check Rule linked to the policy version (Duplicate Check Id, Outcome, Validation Message, Active)

  • Duplicate check tested (both a matching and non-matching scenario)

Activation

  • All rules tested and confirmed working in test company

  • End users notified of go-live date and new rules

  • Policy version activated (Active toggle = on)

  • Post-activation spot check: create a test record in the live company and confirm rules fire as expected