How to Validate Customer Data Before Order Creation
Introduction
Customer data quality directly impacts every downstream process: order fulfillment, shipping, billing, collections, reporting, and customer relationships. A single incorrect customer record can cause shipping delays, payment failures, duplicate accounts, compliance issues, and revenue loss.
Traditional customer data validation relies on manual review, user training, and cleanup after problems emerge. This reactive approach is expensive—fixing bad data costs 10x more than preventing it, and the business impact of errors (missed deliveries, payment disputes, regulatory violations) can be far more costly.
Proactive validation prevents bad customer data from entering your system in the first place. By implementing automated checks when customers are created or modified, you ensure data quality at the source, reduce downstream problems, improve operational efficiency, and maintain compliance.
This comprehensive guide covers customer validation strategies, required field validation, format and consistency checking, duplicate prevention, credit and business rules, integration with external services, and practical implementation patterns for customer master data quality.
Why Customer Data Validation Matters
The Cost of Bad Customer Data
Operational impact:
Financial impact:
Compliance impact:
Categories of Customer Data Issues
1. Incomplete data:
Required fields missing (name, address, contact)
Partial addresses (missing postal code, city)
Missing tax/legal identifiers
2. Invalid data:
Incorrect email formats
Invalid phone numbers
Non-existent postal codes
Invalid tax IDs
3. Inconsistent data:
Address doesn't match city/state/postal code
Payment terms don't match customer category
Currency doesn't match country
4. Duplicate data:
Same customer entered multiple times
Slight variations in naming (ABC Corp vs ABC Corporation)
Different contact info but same entity
5. Outdated data:
Old addresses
Closed locations
Former employees as contacts
Expired credit card/payment information
6. Policy violations:
Credit limit exceeds policy for customer category
Payment terms too generous
Incorrect tax treatment
Customer Validation Strategy
Validation Layers
Implement validation in multiple layers:
Layer 1: Field-level validation (immediate)
Format checking (email, phone)
Required field enforcement
Data type validation
Triggered on field entry/exit
Layer 2: Record-level validation (on save)
Cross-field consistency
Business rule compliance
Duplicate detection
Triggered on Before Insert/Modify
Layer 3: External validation (on save or async)
Address verification services
Tax ID validation (government databases)
Credit bureau checks
Triggered on Before Insert or After Insert
Layer 4: Periodic validation (batch)
Data quality scoring
Outdated data detection
Compliance audits
Scheduled reports
Required vs. Recommended Validation
Required (blocking errors):
Fields essential for business operations
Legal/compliance requirements
Data that prevents system errors
Recommended (warnings):
Best practice fields
Optional but valuable data
Quality improvements
Example:
Implementation: Required Field Validation
Understanding When Data Exists
Customer records in Business Central are created in stages:
OnInsert: Only the No. field is populated (manually or from number series)
User fills fields: Name, Address, Country/Region, etc. are entered
Activation: The Blocked field is cleared (changed from blocked to blank), making the customer available for transactions
Why OnInsert Doesn't Work for Required Fields: When the Customer record is first inserted, only the No. field exists. Other fields like Name, Address, Country/Region Code haven't been entered yet. Validating required fields at OnInsert would always fail because the data doesn't exist.
Correct Approach: Validate required fields when the customer is being activated (Blocked field changing to blank). At this point, all fields have been entered and you're verifying completeness before the customer can be used in transactions.
Basic Required Fields (Status-Based Validation)
Rule Set: CUSTOMER-REQUIRED-FIELDS
Trigger Table: 18 (Customer)
Trigger Field: [18:39] // Blocked field - trigger when customer being activated
Trigger Event: Before Modify
Scenarios:
1. {18:39} is <>[18:39] // Blocked field is changing (using old value {18:39})
2. [18:39] is ' ' // New value is blank (customer being unblocked/activated)
Rule 1: Customer Name Required
Condition: [18:2] is ''
Action: Error - "Customer Name is required before activating customer.
This customer is being unblocked for use in transactions. All customers must
have a name for identification in sales orders, invoices, and reports. Enter
customer name before removing block."
Rule 2: Address Required for Shipping Customers
Scenarios: [18:CustomShippingCustomer] is true
Condition: [18:5] is ''
Action: Error - "Address is required for shipping customers. Customer [18:1]
is flagged as shipping customer but has no address. Enter address or change
customer type."
Rule 3: City Required (if Address Provided)
Scenario 1: [18:5] is <>'<>' // Address filled
Condition: [18:7] is ''
// City blank when address provided
Action: Error - "City is required when address is provided. Complete the
full address information."
Rule 4: Postal Code Required (if Address Provided)
Scenario 1: [18:5] is <>'<>' // Address filled
Condition: [18:91] is ''
Action: Error - "Postal Code is required when address is provided."
Rule 5: Country/Region Required
Condition: [18:35]
Placeholders Used in This Pattern:
[18:2] - Customer (Table 18): Name (Field 2) - Customer's name
[18:35] - Customer (Table 18): Country/Region Code (Field 35) - ISO country code
[18:39] - Customer (Table 18): Blocked (Field 39) - Status field (' '=active, 'All'=blocked)
{18:39} - Customer (Table 18): Previous value of Blocked field (old value before change)
Why This Pattern Works:
Change Detection: Scenario 1 ({18:39} is <>[18:39]) uses old value comparison to detect when Blocked field is being modified
Activation Detection: Scenario 2 ([18:39] is ' ') confirms the new value is blank (unblocked/active)
Together: Both scenarios ensure rules only fire when customer is being activated, not during regular field updates
Data Exists: At activation time, all fields have been entered, so validation checks have data to validate
Real-World Workflow: Matches actual Business Central usage - create customer → fill details → activate by clearing Blocked field
Conditional Required Fields
Fields required only in certain circumstances:
Rule Set: CUSTOMER-CONDITIONAL-REQUIRED
Trigger Table: 18 (Customer)
Trigger Field: [18:39] // Blocked field - validate when customer being activated
Trigger Event: Before Modify
Scenarios:
1. {18:39} is <>[18:39] // Blocked field changing
2. [18:39] is ' ' // Being unblocked (activated)
Rule 1: Tax ID Required for B2B
Condition: [18:CustomCustomerType] is 'B2B' AND [18:CustomTaxID] is ''
Action: Error - "Tax ID (EIN/SSN) is required before activating B2B customer.
This customer is being unblocked but is classified as B2B (business-to-business).
B2B customers require Tax ID for 1099 reporting and tax compliance. Enter Tax ID
or change customer type to B2C before removing block."
Rule 2: VAT Registration No. Required (EU B2B)
Condition: [18:35] in ['DE','FR','IT','ES','NL','etc.'] AND
[18:CustomCustomerType] is 'B2B' AND
[18:166] is ''
// EU country, B2B customer, VAT Reg. No. blank
Action: Error - "VAT Registration No. is required for B2B customers in EU
countries. Customer [18:2] is in [18:35] and marked as B2B. Enter VAT
Registration No."
Rule 3: Contact Required for Corporate Accounts
Condition: [18:CustomCustomerCategory] is 'Corporate' AND [18:CustomContactName] is ''
Action: Warning - "Contact Name recommended for Corporate accounts. Enter
primary contact for this account."
Rule 4: Credit Limit Justification Required (High Limits)
Condition: [18:59] is >100000 AND [18:CustomCreditJustification] is ''
Action: Error - "Credit limits over $100,000 require justification. Enter
reason for high credit limit or reduce limit to $100,000 or less."
Rule 5: Parent Customer Required (Subsidiary Accounts)
Condition: [18:CustomAccountType] is 'Subsidiary' AND [18:CustomParentCustomer]
Placeholders Used in This Pattern:
[18:35] - Customer (Table 18): Country/Region Code (Field 35) - ISO country code
[18:166] - Customer (Table 18): VAT Registration No. (Field 166) - EU VAT number
[18:2] - Customer (Table 18): Name (Field 2) - Customer name
[18:CustomCustomerType] - Customer (Table 18): Custom field for B2B/B2C classification
[18:CustomTaxID] - Customer (Table 18): Custom field for tax identification number
[18:CustomCustomerCategory] - Customer (Table 18): Custom field for customer category
[18:CustomContactName] - Customer (Table 18): Custom field for primary contact
[18:CustomCreditJustification] - Customer (Table 18): Custom field for credit limit justification
[18:CustomAccountType] - Customer (Table 18): Custom field for account type
[18:CustomParentCustomer] - Customer (Table 18): Custom field for parent customer link
Contact Information Requirements
Rule Set: CUSTOMER-CONTACT-VALIDATION
Trigger Table: 18 (Customer)
Trigger Field: [18:39] // Blocked field - validate when customer being activated
Trigger Event: Before Modify
Scenarios:
1. {18:39} is <>[18:39] // Blocked field changing
2. [18:39] is ' ' // Being unblocked (activated)
Rule 1: Email or Phone Required
Condition 1: [18:102] is '' // Email blank
Condition 2: [18:103] is '' // Phone blank
// Both email and phone blank (AND logic between conditions)
Action: Error - "At least one contact method (Email or Phone) is required before
activating customer.
This customer is being unblocked. Contact information is essential for order
confirmations, invoice delivery, and customer communication. Enter email address
or phone number before removing block."
Rule 2: Email Required for Electronic Invoice Customers
Scenario 1: [18:CustomInvoiceMethod] is 'Electronic'
Condition: [18:102] is ''
Action: Error - "Email address is required for customers receiving electronic
invoices. Enter email or change invoice method to 'Print'."
Rule 3: Multiple Contact Methods Recommended
Condition 1: [18:102] is ''
// Email missing
Condition 2: [18:103]
[18:CustomInvoiceMethod] - Customer (Table 18): Custom field for invoice delivery method
Implementation: Format Validation
Note on Format Validation: Format validations can run on both OnInsert and OnModify because they validate the format of data that exists, not whether required fields are populated. However, for consistency with the activation pattern, these examples use OnModify with Trigger Field [18:39] to validate format when customer is being activated.
Alternative: You could also validate format immediately when fields are changed by using:
Trigger Field: [18:102] (Email field itself)
Trigger Event: Before Modify
No scenarios needed (validates whenever email changes)
Email Format Validation
Rule Set: CUSTOMER-FORMAT-VALIDATION
Trigger Table: 18 (Customer)
Trigger Field: [18:39] // Validate format at activation
Trigger Event: Before Modify
Scenarios:
1. {18:39} is <>[18:39] // Blocked field changing
2. [18:39] is ' ' // Being unblocked
Rule 1: Email Format Basic Check
Scenario 1: [18:102] is <>'<>' // Email exists
Condition: [18:102] is not '*@*.*'
// Doesn't contain @ and .
Action: Error - "Email '[18:102]' appears invalid. Email must be in format
user@domain.com. Correct email or leave blank."
Rule 2: Email Suspicious Patterns
Condition: [18:102] in ['test@test.com','noemail@email.com','none@none.com']
Action: Warning - "Email '[18:102]' appears to be placeholder/test data.
Confirm this is customer's actual email address."
Rule 3: Free Email Warning for B2B
Condition: [18:CustomCustomerType] is 'B2B' AND
[18:102] like '*@gmail.com|*@yahoo.com|*@hotmail.com'
Action: Warning - "Customer [18:2] is marked as B2B but uses free email
service ([18:102]
[18:2] - Customer (Table 18): Name (Field 2) - Customer name
[18:CustomCustomerType] - Customer (Table 18): Custom field for B2B/B2C classification
Phone Number Format Validation
Rule Set: CUSTOMER-PHONE-VALIDATION
Trigger Table: 18 (Customer)
Trigger Field: [18:39] // Validate format at activation
Trigger Event: Before Modify
Scenarios:
1. {18:39} is <>[18:39] // Blocked field changing
2. [18:39] is ' ' // Being unblocked
Rule 1: Phone Number Format (US)
Condition: [18:35] is 'US' AND
[18:103] is <>'<>' AND
[18:103] is <>'###-###-####'
// US customer with phone not matching XXX-XXX-XXXX
Action: Warning - "Phone number '[18:103]' doesn't match standard US format
XXX-XXX-XXXX. Recommended format for consistency."
**Placeholders Used in Phone Validation:**
- `[18:35]` - Customer (Table 18): Country/Region Code (Field 35) - ISO country code
- `[18:103]` - Customer (Table 18): Phone No. (Field 103) - Customer's phone number
- `[18:91]` - Customer (Table 18): Post Code (Field 91) - Postal/ZIP code
Rule 2: Phone Number Minimum Length
Scenario 1: [18:103] is <>'<>' // Phone exists
Condition: LEN([18:103]) is <10
// Less than 10 characters
Action: Warning - "Phone number '[18:103]' appears too short. Standard phone
numbers are 10+ digits. Verify this is complete number."
Rule 3: Phone Number Suspicious Patterns
Condition: [18:103] in ['000-000-0000','111-111-1111','999-999-9999']
Action: Warning - "Phone number '[18:103]
Address Format Validation
Rule Set: CUSTOMER-ADDRESS-VALIDATION
Trigger Table: 18 (Customer)
Trigger Field: [18:39] // Validate format at activation
Trigger Event: Before Modify
Scenarios:
1. {18:39} is <>[18:39] // Blocked field changing
2. [18:39] is ' ' // Being unblocked
Rule 1: Postal Code Format (US)
Condition: [18:35] is 'US' AND
[18:91] is <>'<>' AND
[18:91] is <>'#####' AND
[18:91] is <>'#####-####'
// US postal code not 5 digits or ZIP+4
Action: Error - "US Postal Code must be 5 digits (XXXXX) or ZIP+4 (XXXXX-XXXX).
'[18:91]' is invalid format."
Rule 2: Postal Code Format (Canada)
Condition: [18:35] is 'CA' AND
[18:91] is <>'<>' AND
[18:91] is <>'L#L #L#'
// Canada postal code not in A1A 1A1 format
Action: Warning - "Canadian Postal Code typically format: A1A 1A1. '[18:91]'
doesn't match pattern. Verify postal code is correct."
Rule 3: Postal Code Format (UK)
Condition: [18:35] is 'GB' AND
[18:91] is <>'<>' AND
LEN([18:91]) NOT IN [6,7,8]
// UK postcode typically 6-8 characters
Action: Warning - "UK Postcode '[18:91]' appears unusual length. Verify this
is correct postcode."
Rule 4: PO Box Detection (when prohibited)
Condition: [18:CustomShippingMethod] is 'Courier' AND
[18:5] like '*P.O. Box*|*PO Box*|*POB*'
// Address contains PO Box but courier shipping selected
Action: Error - "Courier shipping cannot deliver to PO Box addresses. Address
'[18:5]
Implementation: Consistency Validation
Cross-Field Consistency
Rule Set: CUSTOMER-CONSISTENCY-VALIDATION
Trigger Table: 18 (Customer)
Trigger Field: [18:39] // Validate consistency at activation
Trigger Event: Before Modify
Scenarios:
1. {18:39} is <>[18:39] // Blocked field changing
2. [18:39] is ' ' // Being unblocked
Rule 1: Currency Matches Country
Condition: [18:35] is 'US' AND [18:CustomCurrency] is <>'USD'
Action: Warning - "Customer in United States ([18:35]) but currency is
[18:CustomCurrency]. Typically US customers use USD. Confirm currency is correct."
Rule 2: Payment Terms Match Customer Category
Linked Tables: Payment Terms (3)
Scenario 1: [18:CustomCustomerCategory] is 'Retail'
Scenario 2: [18:27] is <>'NET30'
Action: Warning - "Customer category is Retail but payment terms are [18:27].
Standard retail payment terms are NET30. Confirm [18:27] is approved for this
customer."
Rule 3: Price Group Matches Customer Type
Scenario 1: [18:CustomCustomerType] is 'B2B'
Scenario 2: [18:23] is 'RETAIL-PRICE'
Action: Warning - "B2B customer assigned Retail price group. B2B customers
typically use wholesale/corporate pricing. Confirm price group is correct."
Rule 4: Salesperson Territory Matches Customer Location
Linked Tables: Salesperson (13)
Condition: [18:CustomTerritory] is <>[13:CustomTerritory]
// Customer territory doesn't match assigned salesperson's territory
Action: Warning - "Customer territory ([18:CustomTerritory]) doesn't match
salesperson [13:1]'s territory ([13:CustomTerritory]). Verify correct
salesperson assignment."
Rule 5: Tax Liability Matches Country
Condition: [18:35] is 'US' AND [18:CustomTaxExempt] is true AND [18:CustomExemptCertificate]
Business Rule Consistency
Rule Set: CUSTOMER-BUSINESS-RULES
Trigger Table: 18 (Customer)
Trigger Field: [18:39] // Validate business rules at activation
Trigger Event: Before Modify
Scenarios:
1. {18:39} is <>[18:39] // Blocked field changing
2. [18:39} is ' ' // Being unblocked
Rule 1: Credit Limit Appropriate for Customer Category
Scenario 1: [18:CustomCustomerCategory] is 'Small Business'
Scenario 2: [18:59] is >50000
Action: Warning - "Credit limit $[18:59] exceeds typical maximum of $50,000
for Small Business customers. Confirm this credit limit is approved."
Rule 2: International Customer Requirements
Condition: [18:35] is <>'US' AND [18:CustomInternationalApproved] is false
Action: Error - "International customers require management approval. Customer
[18:2] is in [18:35] (non-US) but not flagged as approved for international
business. Request approval or change country to US."
Rule 3: Blocked Customer Cannot Be Unblocked Without Reason
Condition: [18:39] is false AND [PreviousValue of 18:39] is true AND [18:CustomUnblockReason] is ''
// Customer being unblocked but no reason specified
Action: Error - "Unblocking customer [18:2] requires documented reason. Enter
unblock reason before removing block."
Rule 4: High-Risk Industry Additional Requirements
Condition: [18:CustomIndustry] in ['Cannabis','Firearms','Cryptocurrency'] AND
[18:CustomRiskApprovalDate] is ''
Action: Error - "Industry '[18:CustomIndustry]
Implementation: Duplicate Prevention
Note on Duplicate Detection: Duplicate detection is one of the few scenarios where Before Insert is appropriate, because you're checking if a new customer being created already exists in the system. However, Business Central's Rule Engine has limited capability for cross-record queries. Duplicate detection typically requires custom AL code or integration with data quality services.
Duplicate Detection Patterns
Rule Set: CUSTOMER-DUPLICATE-DETECTION
Trigger Table: 18 (Customer)
Trigger Field: [18:0] // Any field - fires when customer being created
Trigger Event: Before Insert
Rule 1: Exact Name Match
// This requires custom code or external duplicate detection
Action: Warning - "Customer with name '[18:2]' may already exist. Search for
existing customer before creating new record to prevent duplicates."
Rule 2: Similar Name Warning
// Advanced - fuzzy matching typically requires custom implementation
Action: Warning - "Customer name '[18:2]' is similar to existing customer
'[SimilarName]' ([SimilarNo]). Verify this is a different customer before
creating."
Rule 3: Duplicate Email Detection
// Requires lookup to check if email exists in other customers
Condition: [Email exists in another customer record]
Action: Error - "Email '[18:102]' is already registered to customer [ExistingCustomer]
([ExistingNo]). Each customer must have unique email address, or leave email
blank if not available."
Rule 4: Duplicate Tax ID
Condition: [Tax ID exists in another customer record]
Action: Error - "Tax ID '[18:CustomTaxID]' is already assigned to customer
[ExistingCustomer]. This indicates duplicate customer. Verify if customer
already exists before creating."
Rule 5: Duplicate Phone + Address
Condition: [Same phone AND same address exist in another customer]
Action: Warning - "Another customer [ExistingCustomer]
Note: Duplicate detection typically requires custom code, aggregation, or integration with deduplication tools. Basic rule engine functionality may be limited. Consider:
Custom AL code to check for duplicates
Integration with data quality services
Manual review process triggered by warnings
Implementation: Credit and Business Policy Validation
Credit Policy Enforcement
Rule Set: CUSTOMER-CREDIT-POLICY
Trigger Table: 18 (Customer)
Trigger Field: [18:39] // Validate credit policies at activation
Trigger Event: Before Modify
Scenarios:
1. {18:39} is <>[18:39] // Blocked field changing
2. [18:39] is ' ' // Being unblocked
Rule 1: Credit Limit Requires Approval
Condition: [18:59] is >0 AND [18:CustomCreditApprovedBy] is ''
Action: Error - "Credit limit of $[18:59] requires credit department approval.
Enter name of approving manager in Credit Approved By field, or set credit
limit to $0 for cash-only customers."
Rule 2: Credit Limit Maximum by Category
Scenario 1: [18:CustomCustomerCategory] is 'Retail'
Scenario 2: [18:59] is >25000
Action: Error - "Retail customers have maximum credit limit of $25,000 per
policy. Customer [18:2] has limit of $[18:59]. Reduce credit limit or upgrade
customer category to Corporate."
Rule 3: New Customer Credit Limit Restriction
Scenario 1: [18:CustomCustomerAge] is <90
Scenario 2: [18:59] is >10000
// Customer less than 90 days old, credit over $10K
Action: Warning - "New customers (less than 90 days) typically limited to
$10,000 credit. Customer [18:2] is [18:CustomCustomerAge] days old with credit
limit $[18:59]. Confirm this is approved."
Rule 4: Cash-Only Customers Must Have Zero Credit
Scenario 1: [18:CustomPaymentMethod] is 'Cash Only'
Condition: [18:59] is >0
Action: Error - "Customer flagged as 'Cash Only' but has credit limit of
$[18:59]. Cash-only customers must have zero credit limit. Set credit limit
to $0 or change payment method."
Rule 5: Credit Terms Match Credit Limit
Scenario 1: [18:59] is 0
Condition: [18:27] is <>'COD'
// No credit limit but payment terms allow credit
Action: Warning - "Customer has zero credit limit but payment terms '[18:27]
Customer Category Business Rules
Rule Set: CUSTOMER-CATEGORY-RULES
Trigger Table: 18 (Customer)
Trigger Field: [18:39] // Validate category rules at activation
Trigger Event: Before Modify
Scenarios:
1. {18:39} is <>[18:39] // Blocked field changing
2. [18:39] is ' ' // Being unblocked
Rule 1: VIP Customers Requirements
Scenario 1: [18:CustomCustomerCategory] is 'VIP'
Condition: [18:CustomAccountManager] is ''
Action: Error - "VIP customers require dedicated account manager. Assign
account manager before saving VIP customer."
Rule 2: Enterprise Customer Documentation
Scenario 1: [18:CustomCustomerCategory] is 'Enterprise'
Condition: [18:CustomContractOnFile] is false
Action: Warning - "Enterprise customers typically have master service agreement
on file. Confirm contract exists for customer [18:2]."
Rule 3: Government Customer Special Requirements
Condition: [18:CustomCustomerType] is 'Government' AND
[18:CustomGSAApproved] is false
Action: Warning - "Government customers may require GSA Schedule approval.
Verify compliance before accepting orders from [18:2]."
Rule 4: Non-Profit Tax Exemption
Condition: [18:CustomCustomerType] is 'Non-Profit' AND
[18:CustomTaxExempt] is false
Action: Warning - "Non-profit customer [18:2]
Implementation: Integration with External Validation Services
Address Validation Service Integration
Rule Set: CUSTOMER-ADDRESS-VERIFICATION
Trigger Table: 18 (Customer)
Trigger Event: After Insert, After Modify
// Use "After" events for async/external validation
Rule 1: Trigger Address Validation
Condition: [18:5] is <>'<>' AND [18:CustomAddressVerified] is false
// Address exists but not verified
Action: Custom Action - CallAddressValidationService
// This requires custom AL code or Power Automate integration
Parameters:
Address: [18:5]
City: [18:7]
State: [18:CustomState]
PostalCode: [18:91]
Country: [18:35]
Result: Update [18:CustomAddressVerified], [18:CustomStandardizedAddress]
Rule 2: Address Verification Failed
Condition: [18:CustomAddressVerified] is false AND
[18:CustomAddressVerificationAttempted] is true
// Verification tried but failed
Action: Email to customer.service@company.com
"Address verification failed for customer [18:1] - [18:2].
Entered address:
[18:5][18:7], [18:CustomState][18:91][18:35]
Tax ID Validation
Rule Set: CUSTOMER-TAX-ID-VALIDATION
Trigger Table: 18 (Customer)
Trigger Event: After Insert
// After Insert for async validation
Rule 1: Validate US Tax ID (EIN/SSN)
Condition: [18:35] is 'US' AND
[18:CustomTaxID] is <>'<>' AND
[18:CustomTaxIDVerified] is false
Action: Custom Action - ValidateTaxID
// Integration with IRS TIN Matching service or similar
// Requires custom implementation
Rule 2: Validate EU VAT Number
Condition: [18:35] in ['DE','FR','IT','etc.'] AND
[18:166] is <>'<>' AND
[18:CustomVATVerified]
Credit Bureau Integration
Rule Set: CUSTOMER-CREDIT-CHECK
Trigger Table: 18 (Customer)
Trigger Event: After Insert
// After Insert - credit check is async
Rule 1: Automatic Credit Check for New B2B Customers
Condition: [18:CustomCustomerType] is 'B2B' AND
[18:59] is >5000 AND
[18:CustomCreditCheckCompleted] is false
Action: Custom Action - RequestCreditReport
// Integration with D&B, Experian, Equifax, etc.
// Returns credit score, recommended limit, risk rating
Rule 2: Credit Check Results Review
Condition: [18:CustomCreditScore] is <600
// Poor credit score returned
Action: Email to credit.manager@company.com
"Low credit score for new customer [18:2]:
Credit Score: [18:CustomCreditScore]
Requested Credit: $[18:59]
Risk Rating: [18:CustomRiskRating]
Implementation: Customer Lifecycle Validation
New Customer Onboarding
Note on Onboarding Validation: New customer onboarding is one scenario where Before Insert is appropriate, because you're validating that prerequisite steps (application, terms acceptance, compliance checks) are completed before the customer record is created in the system. This differs from required field validation, where fields are entered after the record exists.
Rule Set: CUSTOMER-ONBOARDING-VALIDATION
Trigger Table: 18 (Customer)
Trigger Field: [18:0] // Any field - fires on customer creation
Trigger Event: Before Insert
Rule 1: Customer Application Complete
Condition: [18:CustomApplicationComplete] is false
Action: Error - "Customer application incomplete. Complete all required sections
of customer application before creating customer record."
Rule 2: Terms and Conditions Accepted
Condition: [18:CustomTermsAccepted] is false OR [18:CustomTermsAcceptedDate] is ''
Action: Error - "Customer must accept Terms and Conditions before account
creation. Obtain signed agreement and record acceptance date."
Rule 3: Credit Application Submitted (for credit customers)
Condition: [18:59] is >0 AND [18:CustomCreditAppSubmitted] is false
Action: Error - "Credit application required for customers requesting credit
terms. Submit and approve credit application before setting credit limit."
Rule 4: Reference Check Completed (high-value customers)
Condition: [18:59] is >50000 AND [18:CustomReferencesChecked] is false
Action: Warning - "Customers with credit over $50,000 typically require trade
reference verification. Confirm references have been checked for [18:2]."
Rule 5: Background Check (specific industries)
Condition: [18:CustomIndustry] in ['Defense','Pharmaceutical','Financial Services'] AND
[18:CustomBackgroundCheckComplete] is false
Action: Error - "Industry '[18:CustomIndustry]
Customer Status Changes
Rule Set: CUSTOMER-STATUS-VALIDATION
Trigger Table: 18 (Customer)
Trigger Field: [18:39] // Blocked field - monitor status changes
Trigger Event: Before Modify
Rule 1: Customer Block Requires Reason
Scenario 1: [18:39] is <>' ' // Being blocked (new value not blank)
Scenario 2: {18:39} is ' ' // Was not blocked before (old value blank)
Condition: [18:40] is ''
// Customer being blocked but no reason specified
Action: Error - "Blocking customer [18:2] requires documented reason. Select
block reason code before applying block."
Rule 2: Outstanding Balance Before Block
Scenario 1: [18:39] is <>' ' // Being blocked (new value not blank)
Condition: [18:61] is >0
// Has balance
Action: Email to collections@company.com
"Customer [18:2] blocked with outstanding balance $[18:61].
Block Reason: [18:40]
Age of Balance: [18:CustomOldestInvoiceAge] days
Review for collections action."
Rule 3: Unblock Approval Required
Scenario 1: {18:39} is <>' ' // Was blocked (old value not blank)
Condition: [18:39] is ' ' AND [18:CustomUnblockApprovedBy] is ''
// Customer being unblocked but no approver specified
Action: Error - "Unblocking customer [18:2] requires management approval.
This customer was previously blocked. Document the approving manager's name
before removing block. Contact your supervisor for authorization."
Rule 4: Status Change Audit
Condition: [18:CustomStatus] is <>{18:CustomStatus} // Status field changed (using old value)
Action: Log - Record status change
"Customer [18:1] status changed from {18:CustomStatus} to [18:CustomStatus]
Changed by: [USERID]
Date: [TODAY]
Date: [TODAY]
Time: [TIME]
Performance Optimization for Customer Validation
Validation Priority and Sequencing
Fast validations first (reject obviously bad data quickly):
Use Scenarios to Filter
Rule Set: CUSTOMER-VALIDATION
Scenarios:
1. [18:2] is <>'<>' // Name not blank (reject blanks immediately)
2. [18:CustomValidationRequired] is true // Only validate flagged records
Rules: [Detailed validation logic]
Async Validation for Slow Operations
Synchronous (immediate, fast):
Required fields
Format checks
Basic business rules
Trigger: Before Insert/Modify
Asynchronous (delayed, slow):
Address verification (API call)
Tax ID validation (external service)
Credit checks (third-party)
Duplicate detection (complex search)
Trigger: After Insert, then update customer record
Testing Customer Validation Rules
Test Case Matrix
Test Scenario
Required Fields
Format
Consistency
Duplicates
Policy
Expected Result
Valid new customer
All filled
Valid
Consistent
No dup
Compliant
Success
Missing name
Name blank
-
-
-
-
Error
Invalid email
Filled
Bad format
-
-
-
Error
Mismatched currency
Filled
Valid
US/EUR mismatch
-
-
Warning
Duplicate email
Filled
Valid
-
Email exists
-
Error
Excessive credit
Filled
Valid
-
-
Over limit
Error/Warning
New customer (all checks)
Complete
Valid
Consistent
No dup
Compliant
Success + async checks
Test Data Preparation
Create test customers for each scenario:
Monitoring and Maintenance
Validation Metrics
Track validation effectiveness:
Continuous Improvement
Regular review cycle:
Conclusion
Customer data validation transforms data quality from reactive cleanup to proactive prevention. By implementing comprehensive validation at the point of data entry, you ensure accurate, complete, consistent customer information that improves every downstream process.
Key validation categories:
Required fields: Essential data for operations and compliance Format validation: Correct structure for emails, phones, addresses Consistency: Cross-field relationships and business logic Duplicates: Prevent multiple records for same customer Business policies: Credit limits, customer categories, approvals External validation: Address verification, tax ID checks, credit bureaus
Implementation approach:
Start with required field validation (highest impact, lowest complexity)
Add format validation for key fields (email, phone, address)
Clear, helpful error messages with specific guidance
Balance strictness (errors) with flexibility (warnings)
Fast validation for common checks, async for slow operations
Continuous monitoring and refinement
User training and communication
ROI of customer data validation:
By investing in comprehensive customer data validation, you protect your business from costly errors, improve operational efficiency, ensure compliance, and deliver better customer experiences—all while reducing the burden of manual data cleanup.
Related Reading:
Preventing Data Entry Errors: Validation Best Practices
Writing Effective Error Messages for Business Rules
The Complete Guide to Placeholders for Dynamic Messages
Duplicate Detection Strategies in Business Central
Integrating External Validation Services with QUALIA Rule Engine
Richten Sie Ihre Testversion von Business Central ein.
mit QUALIA Technik GmbH
Starten Sie Ihre 30-tägige Testphase (bei Bedarf auf 60–90 Tage verlängerbar) mit Expertenhilfe, Beispieldaten oder Ihren eigenen Daten.
Was Sie in Ihrer kostenlosen Business Central-Testversion erhalten
25 Testbenutzer, in wenigen Minuten einsatzbereit Wir stellen Ihnen eine CSP Premium-Testversion mit 25 Lizenzen für 30 Tage zur Verfügung – während der Testphase fallen keine Kosten an, und Sie können jederzeit wechseln.
Oder wählen Sie den öffentlichen Testpfad (bis zu 90 Tage). Starten Sie eine Microsoft „öffentliche/virale“ Testversion mit Ihrer geschäftlichen E-Mail-Adresse, verlängern Sie diese einmal selbst (+30 Tage) und einmal über einen Partner (+30 Tage) für bis zu 90 Tage, bevor Sie ein Abonnement abschließen.
Geführtes Onboarding – direkt im Produkt integriert: Sie erhalten In- ‑App- Touren, Schulungstipps und eine „Erste Schritte“-Checkliste, sobald Sie sich anmelden, damit Ihr Team Finanzen, Vertrieb, Lagerbestand und mehr souverän erkunden kann.
Ihre Daten oder Beispieldaten – Sie haben die Wahl. Starten Sie mit einem umfangreichen Demo-Unternehmen oder importieren Sie Starterdateien; Sie können während der Testphase auch Premium- Funktionen für komplexere Szenarien aktivieren.
Sichere ‑Partnerunterstützung mit minimalen Berechtigungen (GDAP) Wir helfen Ihnen bei der Einrichtung und dem Support Ihrer Testphase mithilfe von granularer delegierter Administration (GDAP).
Lokalisiert für Ihren Markt: Die Testversionen werden mit den Sprachen und der regulatorischen Lokalisierung für Ihr Land/Ihre Region bereitgestellt.
Richten Sie Ihre Testversion von Business Central ein.
mit QUALIA Technik GmbH
Starten Sie Ihre 30-tägige Testphase (bei Bedarf auf 60–90 Tage verlängerbar) mit Expertenhilfe, Beispieldaten oder Ihren eigenen Daten.
Was Sie in Ihrer kostenlosen Business Central-Testversion erhalten
25 Testbenutzer, in wenigen Minuten einsatzbereit Wir stellen Ihnen eine CSP Premium-Testversion mit 25 Lizenzen für 30 Tage zur Verfügung – während der Testphase fallen keine Kosten an, und Sie können jederzeit wechseln.
Oder wählen Sie den öffentlichen Testpfad (bis zu 90 Tage). Starten Sie eine Microsoft „öffentliche/virale“ Testversion mit Ihrer geschäftlichen E-Mail-Adresse, verlängern Sie diese einmal selbst (+30 Tage) und einmal über einen Partner (+30 Tage) für bis zu 90 Tage, bevor Sie ein Abonnement abschließen.
Geführtes Onboarding – direkt im Produkt integriert: Sie erhalten In- ‑App- Touren, Schulungstipps und eine „Erste Schritte“-Checkliste, sobald Sie sich anmelden, damit Ihr Team Finanzen, Vertrieb, Lagerbestand und mehr souverän erkunden kann.
Ihre Daten oder Beispieldaten – Sie haben die Wahl. Starten Sie mit einem umfangreichen Demo-Unternehmen oder importieren Sie Starterdateien; Sie können während der Testphase auch Premium- Funktionen für komplexere Szenarien aktivieren.
Sichere ‑Partnerunterstützung mit minimalen Berechtigungen (GDAP) Wir helfen Ihnen bei der Einrichtung und dem Support Ihrer Testphase mithilfe von granularer delegierter Administration (GDAP).
Lokalisiert für Ihren Markt: Die Testversionen werden mit den Sprachen und der regulatorischen Lokalisierung für Ihr Land/Ihre Region bereitgestellt.
Richten Sie Ihre Testversion von Business Central ein.
mit QUALIA Technik GmbH
Starten Sie Ihre 30-tägige Testphase (bei Bedarf auf 60–90 Tage verlängerbar) mit Expertenhilfe, Beispieldaten oder Ihren eigenen Daten.
Was Sie in Ihrer kostenlosen Business Central-Testversion erhalten
25 Testbenutzer, in wenigen Minuten einsatzbereit Wir stellen Ihnen eine CSP Premium-Testversion mit 25 Lizenzen für 30 Tage zur Verfügung – während der Testphase fallen keine Kosten an, und Sie können jederzeit wechseln.
Oder wählen Sie den öffentlichen Testpfad (bis zu 90 Tage). Starten Sie eine Microsoft „öffentliche/virale“ Testversion mit Ihrer geschäftlichen E-Mail-Adresse, verlängern Sie diese einmal selbst (+30 Tage) und einmal über einen Partner (+30 Tage) für bis zu 90 Tage, bevor Sie ein Abonnement abschließen.
Geführtes Onboarding – direkt im Produkt integriert: Sie erhalten In- ‑App- Touren, Schulungstipps und eine „Erste Schritte“-Checkliste, sobald Sie sich anmelden, damit Ihr Team Finanzen, Vertrieb, Lagerbestand und mehr souverän erkunden kann.
Ihre Daten oder Beispieldaten – Sie haben die Wahl. Starten Sie mit einem umfangreichen Demo-Unternehmen oder importieren Sie Starterdateien; Sie können während der Testphase auch Premium- Funktionen für komplexere Szenarien aktivieren.
Sichere ‑Partnerunterstützung mit minimalen Berechtigungen (GDAP) Wir helfen Ihnen bei der Einrichtung und dem Support Ihrer Testphase mithilfe von granularer delegierter Administration (GDAP).
Lokalisiert für Ihren Markt: Die Testversionen werden mit den Sprachen und der regulatorischen Lokalisierung für Ihr Land/Ihre Region bereitgestellt.
Richten Sie Ihre Testversion von Business Central ein.
mit QUALIA Technik GmbH
Starten Sie Ihre 30-tägige Testphase (bei Bedarf auf 60–90 Tage verlängerbar) mit Expertenhilfe, Beispieldaten oder Ihren eigenen Daten.
Was Sie in Ihrer kostenlosen Business Central-Testversion erhalten
25 Testbenutzer, in wenigen Minuten einsatzbereit Wir stellen Ihnen eine CSP Premium-Testversion mit 25 Lizenzen für 30 Tage zur Verfügung – während der Testphase fallen keine Kosten an, und Sie können jederzeit wechseln.
Oder wählen Sie den öffentlichen Testpfad (bis zu 90 Tage). Starten Sie eine Microsoft „öffentliche/virale“ Testversion mit Ihrer geschäftlichen E-Mail-Adresse, verlängern Sie diese einmal selbst (+30 Tage) und einmal über einen Partner (+30 Tage) für bis zu 90 Tage, bevor Sie ein Abonnement abschließen.
Geführtes Onboarding – direkt im Produkt integriert: Sie erhalten In- ‑App- Touren, Schulungstipps und eine „Erste Schritte“-Checkliste, sobald Sie sich anmelden, damit Ihr Team Finanzen, Vertrieb, Lagerbestand und mehr souverän erkunden kann.
Ihre Daten oder Beispieldaten – Sie haben die Wahl. Starten Sie mit einem umfangreichen Demo-Unternehmen oder importieren Sie Starterdateien; Sie können während der Testphase auch Premium- Funktionen für komplexere Szenarien aktivieren.
Sichere ‑Partnerunterstützung mit minimalen Berechtigungen (GDAP) Wir helfen Ihnen bei der Einrichtung und dem Support Ihrer Testphase mithilfe von granularer delegierter Administration (GDAP).
Lokalisiert für Ihren Markt: Die Testversionen werden mit den Sprachen und der regulatorischen Lokalisierung für Ihr Land/Ihre Region bereitgestellt.
