What Dynamics 365 Customisation Actually Means for Saudi Enterprises
Customisation in Dynamics 365 is not the same as configuration. Configuration works within the boundaries Microsoft has set. Customisation extends or replaces those boundaries when the business requirement demands it. For large enterprises in Saudi Arabia, that distinction matters because the business environment creates requirements that out-of-the-box ERP does not address.

Regulatory compliance built into every deployment
ZATCA e-invoicing, VAT reporting, Nitaqat and Saudisation workforce tracking, and Zakat filing requirements.

Industry, entity and currency complexity
Industry-specific workflows in construction, petrochemical, manufacturing, and trading that do not map to generic module defaults — plus multi-entity and multi-currency complexity across Saudi, GCC, and international operations.

Bilingual interfaces and local integrations
Arabic and English bilingual interfaces with right-to-left layout requirements across all user-facing screens, together with integration requirements for local government portals, banking systems, and third-party platforms.
The risk in customisation is not the change itself. It is an undisciplined change made without understanding the downstream consequences. Dynamics 365 is deeply interconnected: Project Accounting connects to Finance, Procurement, and Reporting; Supply Chain connects to Production, Inventory, and Costing. A customisation that is not impact-assessed before development will surface problems in production — often in modules that were never touched.
Our standard: No customisation is scoped without a formal impact analysis. Every change is documented, regression-tested, and validated against the modules it connects to before go-live.
Customisation Delivered: Two Business-Critical Examples
Two examples from Saudi Arabia show where standard Dynamics 365 functionality was not sufficient and careful engineering was required.
Business-critical customisation delivered by Terracez:





Customisation Capabilities Across the Dynamics 365 Platform
The examples below reflect actual work delivered, not theoretical capability.
Revenue recognition logic, project profitability reporting, multi-entity consolidation, Zakat and VAT-compliant financial structures.

Automated item generation, purchase requisition consolidation, supplier onboarding workflows, multi-warehouse inventory rules.

Custom item rejection and approval workflows, production order modifications, quality control integration.

AI-based KYC portals integrated with Dynamics 365 Sales, customer onboarding automation, pipeline and deal governance workflows.

Bespoke estimation tools for construction and marine projects, contract management extensions, project controls dashboards.

ZATCA Phase 1 and Phase 2 e-invoicing integration, Nitaqat and Saudisation workforce reporting, Arabic-English bilingual interfaces.

Azure Blob Storage integration, Power Platform automation, custom portals connected to core ERP data.

When We Customise vs. When We Extend
Customisation
- The business requirement is central to a core financial or operational process.
- The standard module produces incorrect results for a specific business rule.
- The change is bounded, impact-assessed, and upgrade-safe.
- Core behaviour genuinely needs to be extended to meet the requirement.
- Connected-module dependencies can be fully understood and regression-tested before deployment.
Extension
- The requirement involves significant data volumes, document management, or AI processing.
- Modifying core code would create upgrade risk or performance degradation.
- The functionality is best served by a dedicated portal or external system connected via API.
The Engineering Decision
- The petrochemical KYC solution is a clear example of the extension approach.
- The Technomak revenue recognition work is a clear example of core module customisation.
Saudi Arabia Regulatory Requirements: Built Into Every Deployment
Customisation decisions must account for tax, workforce, localisation and reporting requirements from the start. The controls below are part of the Saudi delivery context Terracez builds into Dynamics 365 programmes.
Saudi localisation is treated as a delivery baseline: tax, workforce, Zakat and Arabic-language requirements are considered before customisation design is approved.
Saudi Regulatory and Localisation Controls
Arabic Language and Localisation
All user-facing screens, reports, and printed documents are delivered in both Arabic and English with full right-to-left interface support. This is a non-negotiable baseline for user adoption in Saudi Arabia.
How Our Saudi Arabia Customisation Engagements Work
Five connected stages take the requirement from validation and impact analysis through architecture, development, testing, deployment and hypercare.
The Five-Step Customisation Engagement
We begin by understanding the business requirement in precise terms — not the feature request, but the underlying business rule, the data it touches, and the outcome it needs to produce. This is where most customisation projects go wrong: the requirement is not specific enough to build correctly.
Before any development begins, we map every module, function, and integration that the proposed change could affect. For complex modules like Project Accounting or Supply Chain, this analysis typically surfaces two to three dependency risks that were not visible in the initial requirement. These are resolved at the design stage, not after deployment.
Based on the requirement and impact analysis, we determine whether the right approach is a core customisation, a platform extension, or a configuration change. This decision is documented and agreed with the client before development starts.
Development follows Microsoft's extensibility best practices, preserving upgrade paths wherever possible. Testing covers the customised function, all connected modules, and regression scenarios for existing workflows that share the same data or logic.
Go-live is supported by our on-the-ground teams in Riyadh, Jeddah, and Dammam. A hypercare period follows every deployment, with defined SLAs for issue resolution and direct access to the consultants who built the solution.

For a deeper look at how governance decisions shape customisation outcomes, read our guide: If you are an IT Manager or Operations Director preparing for a go-live, this is essential reading:
On-ground presence: Terracez has delivery teams physically based in Riyadh, Jeddah, and Dammam. For business-critical customisations, this matters. Time zone alignment, Arabic language capability, and the ability to be on-site when it counts are not small details.
Start With a Scoping Conversation
If you have a Dynamics 365 customisation requirement in Saudi Arabia, the right first step is a scoping conversation — not a proposal. We need to understand the business rule, the module it lives in, and what it connects to before we can tell you what is feasible, how long it will take, and what it will cost.
Terracez offers a complimentary scoping session for enterprise organisations in Saudi Arabia. In that session, we will assess your requirement, identify the likely impact surface, and give you an honest view of the approach before any commitment is made.
Our teams are based in Riyadh, Jeddah, and Dammam and are available for on-site meetings across the Kingdom.

Dynamics 365 Customisation in Saudi Arabia — Frequently Asked Questions
Direct answers to the questions Saudi enterprises most often ask before starting a Dynamics 365 customisation engagement.

