An HR director at a UK manufacturing business discovers a problem during a compliance review. Right to Work references are missing or invalid, visa expiry dates sit in free-text notes, and National Insurance numbers don't pass basic format checks. The HR team thought it had complete employee records because the fields existed in Dynamics 365. The records weren't reliable enough to support a defensible response to an audit or Subject Access Request.
That situation is common in Microsoft 365 organisations where employee data enters Dataverse through forms, imports, integrations, spreadsheets and manual updates. Data validation rules turn policy into enforceable conditions. They check whether information is present, correctly formatted, logically consistent and suitable for the process that depends on it.
For UK HR teams, validation is more than data cleanliness. It supports GDPR accountability, Right to Work controls, payroll accuracy and SAR readiness. The UK Government Statistical Service guidance on quality statistics treats validation as a core quality-control mechanism, with checks for missing values, logical relationships, arithmetic relationships and acceptable ranges. That same discipline belongs in HR master data.
Why Data Validation Rules Matter for UK HR Compliance
The compliance risk usually appears in layers. A missing expiry date may begin as a data-entry issue, become a payroll or workforce-planning problem, and later create difficult questions about what the organisation knew and when it knew it.
The first layer is regulatory exposure. UK GDPR requires organisations to handle personal data fairly, lawfully and transparently, while keeping it accurate and appropriately managed. Article 5(2) places accountability on the organisation, which means HR teams need more than a policy document. They need evidence that controls operated in practice. A validation rule that prevents a visa record from being saved without its required date can form part of that evidence, particularly when the rule, failure and override are logged.
The Data (Use and Access) Act 2025 adds further practical considerations for HR workflows. Guidance discussed in a recent UK HR data-protection roundup highlights a stop-the-clock mechanism for identity verification and clarification in SAR handling from 5 February 2026. That makes a validated request-intake process important. HR needs to distinguish a complete request from one awaiting clarification, record the reason for a pause, and avoid treating every incoming message as ready for a full search.
Syntactic checks are only the beginning
Syntactic validation checks the shape of information. It can require a value, restrict characters, enforce a date type or reject an obviously malformed identifier. These checks are useful, but they don't prove that the information makes business sense.
Semantic validation tests meaning and relationships. A visa expiry date shouldn't be earlier than its issue date. A Right to Work status of “indefinite” shouldn't require a temporary expiry date. A payroll record shouldn't reference an inactive employee. A consent timestamp should not follow the processing activity it supposedly authorised.
For a Dataverse HR implementation, the strongest design combines both:
- Format controls: Use appropriate field types, choice columns and patterns instead of free text.
- Completeness controls: Require fields when a status, nationality or document type makes them necessary.
- Relationship controls: Validate lookups, dates and dependent records together.
- Audit controls: Record who changed a value, when the change occurred and whether an exception was approved.
The UK's official-statistics framework shows why this layered approach matters. The Department for Education's quality framework includes specification-stage checks, supplier checks, duplicate and missing-data checks, range checks and internal consistency checks. Validation belongs throughout the pipeline, not only on the HR form.
Practical rule: If a value could affect a legal decision, statutory report, retention action or employee-rights response, validate it at the server boundary and not only on the screen.
A useful companion for HR and IT leaders is this guide to employee data security in Microsoft environments. Validation won't replace access controls, encryption or retention policy, but it helps ensure that the records those controls protect are coherent and explainable.
Five Ways to Implement Validation Rules in Dataverse
Dataverse gives teams several ways to enforce validation. The mistake I see most often is choosing the most convenient mechanism rather than matching the mechanism to the risk.
Business Rules
Business Rules are a good starting point for straightforward form behaviour. They can make a field required, lock it, show an error or set a value when another field changes.
A Right to Work example is simple: if the document type is a temporary visa, require a visa expiry date. If the document type represents indefinite leave to remain, hide or disable the temporary expiry field and require the relevant evidence reference instead.
The limitation is important. Business Rules primarily respond to form interactions. They're not a complete control for records written through integrations, imports, APIs or background processes. Use them for immediate user guidance, not as the only compliance barrier.
Form-level JavaScript
JavaScript can handle logic that Business Rules can't express cleanly. It's useful for conditional messages, normalising user input and checking several fields before a form is submitted.
It also carries maintenance cost. Form scripts depend on form context, field names and event registration. A script that works on the main employee form may not run during an import, in a model-driven app variant or through a third-party integration. Accessibility needs careful attention too. GOV.UK guidance says validation should reject information that cannot be correct, is too ambiguous to use or is missing when required, while Home Office guidance recommends text-based messages that explain the location, cause and correction, without relying on colour alone. See the GOV.UK validation pattern and Home Office error-message guidance when designing the user experience.
Synchronous plug-ins
For high-risk rules, a synchronous Dataverse plug-in is usually the dependable enforcement point. It runs during create or update and can stop the transaction regardless of whether the request came from a form, API, import or integration.
A typical pattern validates a normalised National Insurance value before commit:
public void Execute(IServiceProvider serviceProvider)
{
var context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));
if (!context.InputParameters.Contains("Target") ||
!(context.InputParameters["Target"] is Entity target))
return;
if (!target.Contains("new_ninumber"))
return;
var ni = target.GetAttributeValue<string>("new_ninumber");
var normalised = ni?.Replace(" ", "").ToUpperInvariant();
if (string.IsNullOrWhiteSpace(normalised) ||
!Regex.IsMatch(normalised, @"^[A-CEGHJ-PR-TW-Z]{2}[0-9]{6}[A-D]$"))
{
throw new InvalidPluginExecutionException(
"Enter a valid National Insurance number.");
}
}
This checks structure, not whether the number belongs to the employee. That distinction should be visible in the rule description and audit documentation.
Power Automate
Power Automate is useful when validation can happen after the transaction. A flow can flag possible duplicates, request a review, compare data with an approved external service or notify HR about an approaching document deadline.
It's a poor fit for a hard stop. A flow runs asynchronously, can be delayed and may fail after the record has already been saved. Treat it as an orchestration and monitoring layer, not as the sole control for a statutory or high-risk condition.
Power Apps Component Framework
PCF controls make sense where the user needs a specialised input experience. Examples include postcode assistance, structured document capture or passport MRZ scanning. They can reduce entry errors and guide the user more effectively than a standard text box.
They still need server-side protection. A custom control improves the front end, but it doesn't prevent a separate integration from writing an invalid value.
| Method | Enforcement level | Maintenance effort | Best HR use case |
|---|---|---|---|
| Business Rules | Form-level | Low | Conditional required fields and simple visibility |
| Form JavaScript | Form-level, flexible | Medium | Multi-field guidance and normalisation |
| Synchronous plug-ins | Transaction-level | Medium to high | Right to Work, payroll and legally significant controls |
| Power Automate | Asynchronous | Medium | Alerts, duplicate review and external checks |
| PCF controls | User-interface level | High | Specialist capture and guided document entry |
Before implementing rules, define which records arrive through imports, integrations and manual entry. A sound Dataverse data migration strategy should include profiling, cleansing and exception handling, because a perfect form rule won't repair historical records automatically.
Real-World UK Compliance Scenarios and Validation Patterns
The practical test is whether a rule protects a decision, not whether it makes a form look tidy. The following patterns reflect the way I'd structure a UK HR Dataverse solution, while keeping the legal basis and operational purpose explicit.
Right to Work records
Use a dedicated RightToWorkCheck table related to Worker. Typical columns include worker, nationalityCode, validationType, documentStatus, documentReference, issueDate, expiryDate, checkDate, checkingRoute and exceptionReason.
The rule set should be conditional. A temporary visa requires a document reference, checking route and expiry date. An indefinite status should use a suitable evidence type and shouldn't be forced into a temporary-date model. The system should also prevent a record from being marked complete when the mandatory evidence fields are absent.
A synchronous plug-in can apply the transaction boundary:
if (status == "Pending" &&
checkDate.HasValue &&
checkDate.Value.Date < DateTime.UtcNow.Date.AddDays(-28))
{
throw new InvalidPluginExecutionException(
"Complete the Right to Work review or record an approved exception.");
}
if (validationType == "Temporary visa" && !expiryDate.HasValue)
{
throw new InvalidPluginExecutionException(
"An expiry date is required for a temporary visa.");
}
if (validationType == "Indefinite leave to remain" &&
expiryDate.HasValue &&
!exceptionReasonPresent)
{
throw new InvalidPluginExecutionException(
"Explain why an expiry date has been recorded for an indefinite status.");
}
The 28-day threshold in this example comes from the specified operational rule, not from a general assumption that every immigration case follows the same timetable. The legal and operational owner should confirm the rule before deployment, and the plug-in should use UTC consistently to avoid a date changing unexpectedly around midnight.
The UK public-sector programme data standard gives useful examples for this type of design, including unique identifiers, positive-number constraints, controlled categories, date ordering and foreign-key integrity. Those principles help prevent a Right to Work record from pointing to the wrong worker or accepting an invalid document state.
SAR readiness
SAR readiness depends on more than a request form. HR needs dependable worker identifiers, source-system references, data categories, retention fields and search ownership.
A SARRequest table can include worker, receivedDateTime, identityStatus, clarificationRequired, clockStatus, searchScope, responseDueDate, pauseReason and closureDate. A related PersonalDataCategory table can hold categoryName, retentionPeriod, legalBasis, systemOfRecord and owner.
Business Rules can flag missing identity status or search scope. Power Automate can create tasks for HR, IT and managers when a request is ready for discovery across Dataverse, SharePoint, Teams and email. A flow can also flag a consent timestamp that follows the processing date, although that should create an exception for review rather than rewriting history without notice.
The validation objective is traceability. If identity verification or clarification pauses the process, the record should capture the reason, the approver and the relevant timestamps. That structure supports the nuanced SAR approach described in the earlier UK HR guidance, rather than relying on a single deadline field.
Retention and deletion
Retention needs an explicit data model. A RetentionPolicy table can contain dataCategory, legalBasis, retentionStartDate, retentionEndDate, disposalAction, legalHoldStatus and reviewOwner. The employee or payroll-related record should reference the applicable policy rather than storing an unexplained number in a free-text note.
A server-side plug-in can prevent deletion while a statutory retention window is active. The supplied scenario uses 6 years for payroll records under HMRC rules, but the legal owner must confirm which record category and start event the policy applies to before any rule is released. A separate scheduled process can flag records beyond their retention limit for review and disposal.
A common failure is timezone drift. Dataverse stores date and time values with user and organisation settings, while integrations may send UTC or local values. Convert values to a declared timezone before comparing dates, and test records created near a day boundary. Lookup validation is another weak point. A populated lookup isn't necessarily valid if the referenced policy is inactive, belongs to another legal entity or doesn't cover the selected data category.
For independent context on protecting recorded personal data, HR and security teams may also find these business CCTV data protection rules useful when comparing retention, access and deletion controls across different data types.
The following video provides an additional visual reference for compliance-oriented validation patterns:
Testing and Monitoring Your Validation Rules
A validation rule that works on a developer's form can still fail in production. Records arrive through Excel, APIs, integrations, mobile clients and bulk operations. Test the transaction boundary, not just the screen.
Start with a rule inventory. For each rule, record the trigger, expected outcome, legal or operational purpose, owner and exception route. Then test in layers:
- Unit testing: Submit valid, invalid, blank, boundary and deliberately ambiguous values.
- Integration testing: Create and update records through APIs, imports, flows and related-table operations.
- Regression testing: Re-run critical tests after solution upgrades, column changes, plug-in changes and security-role updates.
- User acceptance testing: Ask HR users to perform realistic work, including corrections and exception handling.
- Offline and mobile testing: Confirm that users receive a useful response when the client cannot apply every rule immediately.
Dataverse plug-in tracing can show where server-side failures occur, while Power Platform administration and monitoring tools can help teams identify recurring errors and user friction. Log enough detail to diagnose the rule, but don't write unnecessary sensitive employee values into traces.
Monitor the rule, not just the record
A useful dashboard groups failures by rule, process, source and owning team. A spike in failed imports may indicate a mapping issue rather than poor HR behaviour. Repeated failures on one field may mean that the label, hint text or choice values don't match how the business works.
Synthetic transactions are valuable for edge cases. Simulate a bulk import with missing references, a duplicate worker, an inactive retention policy, a temporary visa without an expiry date and a record received around a timezone boundary. Verify both the user message and the audit outcome.
A rejected record is not automatically a successful control. If users can't understand the error, they'll copy records, work around the process or ask an administrator to bypass it.
Create a feedback route for false positives. HR practitioners should be able to report a rule that blocks a legitimate case, while the system preserves the original failure and records any approved override. Review the rule registry after each significant process or regulatory change, including developments connected with the Data (Use and Access) Act 2025.
Building a Governance Framework for Validation Rules
Technical teams shouldn't own compliance rules in isolation. HR defines the process, legal or privacy specialists confirm the purpose, IT implements the control, and a named business owner accepts the residual risk.
Create a validation rule register for every material rule. Keep the rule name, table and column, condition, message, legal basis, business owner, technical owner, exception process, deployment date and review date. Link the rule to the relevant policy or procedure. This gives auditors a clear explanation of why the control exists and helps developers avoid breaking an obligation during a refactor.
The UK data-quality standard expects organisations to identify critical data items, apply quality rules in a timely way, maintain KPIs and escalate data-quality risks to the appropriate board or forum. That is a governance model, not merely a form-design recommendation.
Make exceptions visible
Rigid rules can create false confidence. A perfectly formatted value may still be stale, biased or attached to the wrong person. Governance reviews should therefore examine both failure rates and false acceptance risk.
Use a change-control process for rules affecting Right to Work, payroll, retention, automated decision-making or SAR handling. A proposed change should identify affected tables, integrations, reports, security roles and historical data. Exceptions should require a reason, approver and expiry or review route. Don't allow administrators to bypass a plug-in by disabling it in production without an auditable change record.
A privacy-by-design approach is described in this DynamicsHub resource on data protection by design. The same principle applies to validation: build the purpose, minimisation and accountability into the data model rather than adding them after a failure.
Next Steps for Your HR Data Quality Journey
Data validation rules are compliance mechanisms, not cosmetic data-cleaning tools. Choose Business Rules for clear form guidance, synchronous plug-ins for high-risk enforcement, Power Automate for follow-up work and PCF controls for specialist capture.
Start by auditing Right to Work, retention and SAR workflows. Identify where records enter Dataverse outside the main form, then pilot server-side validation around the highest-risk transactions. Review failures with HR users, document approved exceptions and keep the rules aligned with changing UK requirements.
DynamicsHub implements Hubdrive's HR Management for Microsoft Dynamics 365 as a hire-to-retire solution built around Dataverse, with UK Right to Work and GDPR-aligned HR controls. The implementation should fit your business processes, integrations and governance model rather than forcing every organisation into the same rule set.
DynamicsHub can help you assess existing HR validation rules, design defensible Dataverse controls and connect Right to Work, retention and SAR workflows across Microsoft 365. Phone 01522 508096 today, or send us a message through DynamicsHub to discuss your HR transformation requirements.
