GS524 – Embedding Business Rules and Exceptions in Globalization Studio

Compliance rules vary. Some customers want PDFs, others require XML. Some invoices must be signed, others not. Dynamics 365 Globalization Studio enables you to embed those differences as rules, not code.

In this article, you’ll learn how to:

Embed business-specific logic and exceptions into your features
Dynamically control steps in the processing pipeline using context-aware applicability rules
Add validations directly in Format Designer
Build localization logic that adapts to different business cases

🔗 Builds on: GS504 – Applicability Rules, GS514 – Output Routing, GS525 – Validation and Storage

Table of Contents

🧠 Why Add Business Logic?

Real-world compliance is not one-size-fits-all. You need to reflect:

Type	Example
Country rules	Only Spain uses FACe
Customer exceptions	B2G needs digital signature, B2B does not
Invoice thresholds	Sign invoices only if > €500
Delivery logic	Exports vs. domestic

Hardcoding these rules in X++ creates rigidity. Using Globalization Studio + ER, they become configurable and transparent.

image-261 GS524 – Embedding Business Rules and Exceptions in Globalization Studio

🪜 Step-by-Step: Add Pipeline Applicability Rules using Context

✅ Step 1: Find Context Configuration

Go to Electronic Feature > Click Application Setup

Note – The Application setup is essential for:

Automating electronic invoice creation and submission
Ensuring regulatory compliance
Supporting multiple document types and legal entities
Driving dynamic behavior using context and validation rules

image-262 GS524 – Embedding Business Rules and Exceptions in Globalization Studio

Check Context name. Remember – this is by document type

image-263 GS524 – Embedding Business Rules and Exceptions in Globalization Studio

Context variables

👉 This defines dynamic runtime values available for rules.

As seen in your screenshot, these values are later used in applicability rules to filter steps by country, channel, or entity.

image-264 GS524 – Embedding Business Rules and Exceptions in Globalization Studio

Context variables are located under empty container in ER configuration

image-267 GS524 – Embedding Business Rules and Exceptions in Globalization Studio

You can extend these variables as per requirement or add new once.

✅ Step 2: Use the Context in Applicability Rules

Go to Globalization Studio > Feature > Applicability Rules
Add a rule like:

image-266 GS524 – Embedding Business Rules and Exceptions in Globalization Studio

This restricts the entire feature to apply only for invoices in Spain

🧪 Step-by-Step: Add Validation in Format Designer

In Format Designer, validations are used to enforce business logic on the XML structure. For example, validating IBAN numbers or signer parameters.

✅ Step 1: Open Format Designer

Go to Electronic Reporting > Configurations
Select your format (e.g., Sales Invoice (ES))
Navigate to the Validations tab

image-265 GS524 – Embedding Business Rules and Exceptions in Globalization Studio

✅ Step 2: Add Validation Conditions

Your screenshot includes the following conditions:

Validation Point	Condition Sample	Function
AccountNumber	OR(Invoice.InvoiceBase.CompanyInfo.BankAccount.IBAN <> “”, Invoice.InvoiceBase.CompanyInfo.BankAccount.AccountNum <> “”)	This validation ensures that the company’s bank account details are present in the invoice , either: An IBAN, or A local bank account number 🔹 Why It’s Needed: For Spanish e-invoicing (e.g., submission to FACe), it is often mandatory to include payment account details of the issuer (supplier/company) in the XML. Missing this could result in: Submission rejection by government platforms Invalid invoice formats
AccountToBeDebited	OR(Invoice.CustomerTransaction.BankAccount.IBAN <> “”, Invoice.CustomerTransaction.BankAccount.AccountNum <> “”)	This validation ensures that the company’s bank account details are present in the invoice , either: An IBAN, or A local bank account number 🔹 Why It’s Needed: For Spanish e-invoicing (e.g., submission to FACe), it is often mandatory to include payment account details of the issuer (supplier/company) in the XML. Missing this could result in: Submission rejection by government platforms Invalid invoice formats
XMLHeader	OR(Invoice.InvoiceBase.CountrySpecificData.EInvoiceParameters_IT.EInvoiceSignerType_ES= Enums.ModelEInvoiceSignerType_ES.Issuer, Invoice.InvoiceBase.CountrySpecificData.EInvoiceParameters_IT.EInvoiceSignerType_ES= Enums.ModelEInvoiceSignerType_ES.Receiver, Invoice.InvoiceBase.CountrySpecificData.EInvoiceParameters_IT.EInvoiceSignerType_ES= Enums.ModelEInvoiceSignerType_ES.ThirdParty)	Validates that the invoice signer type (EInvoiceSignerType_ES) is one of the allowed values: Issuer Receiver ThirdParty 🔹 Why It’s Needed: The Spanish e-invoice model expects the invoice XML to include the correct signer classification, depending on: Whether the invoice is self-billed Who generated or signed the document Whether a third party is involved in the process This validation ensures that a valid enum value is selected , otherwise the XML may: Be structurally invalid Get rejected by the Spanish e-invoicing web service

🛑 If these conditions fail, the export will be blocked and a validation error will appear.

📢 Tip: Use Edit Message to provide a clear business-friendly error message like:
“⚠️ IBAN or Account Number is required for customer payment details.”

💼 Advanced Use Case: Mixed B2B/B2G Customers in Spain

Contoso Spain sells to:

Public sector (B2G) → requires Facturae XML + signature + FACe submission
Private sector (B2B) → needs only PDF via email

How to handle both in one pipeline:

Step	Applicability Condition
Sign	Context.CustomerGroup = “B2G”
Submit	Context.CustomerGroup = “B2G”
Store to Azure	Context.CustomerGroup = “B2G”
BDM PDF	Context.CustomerGroup = “B2B”
Email	Context.CustomerGroup = “B2B”

💡 Best Practices for Managing Rules

Tip	Why It Helps
Name context variables clearly	IsExport, NeedsSignature, CustomerGroup
Keep validations user-readable	Auditors can understand failure reason
Separate logic cleanly	Don’t mix country + customer logic
Use comments in rules	Explain why the rule exists
Test edge cases	Ensure robustness (nulls, missing fields)

📁 Where to Monitor Rule Outcomes

Tool	View
Pipeline Execution Log	See if step was executed or skipped
ER Execution Log	See calculated values, e.g., IsB2G
Submission History	Result per document, incl. validation failures
Power BI Audit Report	End-to-end compliance view

🧭 Related Articles

📘 Coming Up Next

In GS525 – Document Archival and Compliance Audits in Globalization Studio, we’ll explain how to securely store signed documents and submission logs for long-term audit compliance.
You’ll learn how to: