Customisation is not a feature decision. It is a governance decision that determines whether Dynamics 365 remains a scalable business platform or slowly becomes the old organisation rebuilt in code.
Most Dynamics 365 programmes in Saudi Arabia and the UAE do not lose value because they customised too little. They lose value because customisation is approved as a response to user pressure rather than governed as an operating model decision.
The real problem rarely starts at the design workshop. It starts six months after go-live, when the change request queue fills up, business users escalate to senior leadership, and the path of least resistance is to say yes.
Three patterns repeat across GCC programmes:
- Demand-based customisation approved without architecture review or business justification
- Legacy behaviour rebuilt inside the new platform, effectively recreating the old system at a higher cost
- Post-go-live changes accumulating without impact analysis, ownership, or upgrade consideration
According to the KPMG Saudi Arabia Tech Report 2026, 93% of Saudi organisations report centralised control over technology selection, compared with 78% globally. The governance intent is there. The execution gap is in what happens after go-live, when that centralised control is rarely applied to individual change requests.
This article gives IT managers, ERP owners, and operations directors a practical framework for assessing, approving, and controlling Dynamics 365 customisation across CRM and ERP, before and after go-live.
Key takeaways:
- Start with configuration, then extensions, then code - in that order
- CRM and ERP customisation carry different risk profiles and need separate governance
- Post-go-live demand is the highest-risk customisation scenario in GCC environments
- Manufacturing, project accounting, and finance modules require the strictest approval thresholds
- Power Platform can absorb peripheral requirements without touching core architecture
- DevOps and impact analysis are not optional - they are part of the governance model
- Transformation Intelligence helps distinguish essential gaps from organisational preference
What Customisations Should You Allow in Dynamics 365?
The most common mistake in Dynamics 365 governance is treating customisation as a binary choice: either you build what the business asks for, or you tell them no. The reality is more structured than that.
Microsoft's extensibility guidance for Finance and Operations recommends a clear hierarchy: exhaust standard configuration first, use supported extensions second, and only approve custom code where the gap is material to compliance, process integrity, automation, or measurable business value. Governance boards in mature GCC environments are increasingly requiring teams to prove that no standard capability exists before custom code is approved.
The decision hierarchy looks like this:
The practical rule: if a requirement can be met without changing core platform logic, that is almost always the safer route. Many perceived local gaps in Saudi Arabia and the UAE are already addressed through Microsoft's Saudi localisation for Dynamics 365 Finance, including Arabic UI, right-to-left configuration, Hijri calendar support, and ZATCA-aligned invoice structures.
How Should CRM and ERP Customisation Be Governed Differently?
One of the most consistent gaps in regional Dynamics 365 programmes is treating CRM and ERP customisation as the same discipline. They are not.
Dynamics 365 Customer Engagement (CRM) and Dynamics 365 Finance and Operations (ERP) sit on different architectures, serve different business functions, and carry very different consequences when customisation goes wrong.
A workflow customisation in CRM that improves the sales team's pipeline visibility is operationally manageable. The same logic applied to a finance posting rule or a project billing calculation can create downstream reporting errors, compliance gaps, and upgrade failures that take months to unpick.
The governance principle: apply proportionate scrutiny. CRM can tolerate more controlled flexibility. ERP demands a higher burden of proof before any change is approved.
What Customisations Should You Avoid in Dynamics 365 ERP?
Some modules carry disproportionate risk. Customising them is not impossible, but the consequences of getting it wrong are severe enough that the burden of justification must be extremely high.
On ZATCA specifically: Saudi Arabia's e-invoicing mandate (FATOORA) applies to businesses with VAT revenue above SAR 375,000. The Dynamics 365 standard ZATCA submission feature handles XML invoices, digital signatures, and QR codes. Building custom logic on top of this creates compliance exposure that is difficult and expensive to remediate.
As noted in our earlier guidance on Dynamics 365 customisation in Saudi Arabia, customisation governance should enforce using standard tax codes and structures aligned with Saudi localisation rather than custom tax logic.
What Happens When Post-Go-Live Customisation Is Not Controlled?
The most dangerous customisation in a Dynamics 365 programme is not the one approved at design stage. It is the one approved six months after go-live because a business user escalated and nobody had a framework to say no.
This is the pattern we observe most frequently across GCC programmes. Implementation goes well. The architecture is sound. The standard build is clean. Then the support phase begins, and so does the erosion.
Warning signs that post-go-live customisation is out of control
- Change requests are approved by the support team without architecture or business owner sign-off
- The same business process has been modified three or more times since go-live
- Upgrade testing is taking significantly longer because custom code keeps breaking
- The system is being used differently from how it was designed, and nobody can explain why
- Business users describe the system as "not working for us" despite it functioning correctly
- Support tickets are rising, but the root cause is customisation debt, not platform failure
The underlying dynamic is straightforward. User demand is not the same as business justification. Every request must be assessed for architecture impact, compliance exposure, support cost, and future upgrade effort. A system that accepts every request eventually adds no value. It becomes an expensive copy of the as-is state, which is precisely what the transformation was supposed to replace.
The cost is not just technical. Uncontrolled post-go-live customisation erodes executive confidence, delays value realisation, and makes future upgrades progressively more expensive. Across GCC programmes, this is one of the most consistent contributors to transformation programmes that complete on time but fail to deliver business benefit.
How Should Dynamics 365 Customisation Requests Be Approved?
Every customisation request, whether raised during implementation or after go-live, should pass through the same structured assessment. The output is not always yes or no. Many requests should be redesigned into configuration, workflow, or Power Platform options before any code is written.
The five-question approval test
- Is the gap real? Can the business demonstrate a measurable process failure, compliance risk, or automation need? If the answer is "we prefer it this way", that is not a business gap.
- Is standard capability exhausted? Has the team confirmed that no configuration, workflow, or localisation feature covers the requirement? Microsoft's extensibility home page for Finance and Operations is the starting point for this check.
- What value does this create? Can the requestor quantify the business benefit: time saved, error reduced, compliance achieved, or revenue protected?
- What risk does this introduce? What is the impact on architecture, integrations, reporting, security, and upgrade path?
- What happens at upgrade or audit time? Who owns this customisation? Who will test it? Who will maintain it?
Decision output
- Approve: Gap is real, standard capability is exhausted, value is quantified, risk is acceptable, ownership is assigned
- Redesign: Gap is real, but a configuration, extension, or Power Platform option can address it without custom code
- Defer: Gap is real but low priority; add to the governed backlog for the next release cycle
- Reject: Gap is a preference, not a process need; standard capability already covers it
Impact analysis must cover: process impact, integration dependencies, reporting and BI impact, security and data access, testing effort, and post-deployment ownership. This is not optional for ERP changes. It is the minimum standard before any change enters development.
How Should DevOps and Impact Analysis Support Dynamics 365 Customisation?
Governance without delivery discipline is just documentation. Even well-justified customisations become unstable if the team has no version control, no deployment pipeline, and no regression testing framework.
Minimum DevOps and impact analysis controls
- Source control: All custom code and extensions stored in a version-controlled repository, with branch strategy and code review before merge
- Environment strategy: Separate development, test, UAT, and production environments; no direct changes to production
- Automated build and deployment: Changes deployed through a controlled pipeline, not manual file uploads
- Regression testing: Every release includes a test pass covering affected modules and integrations, not just the changed component
- Impact analysis log: Every approved change includes a documented impact assessment before development begins
- Ownership record: Every customisation has a named business owner and a named technical owner responsible for maintenance and upgrade testing
- Release cadence: Post-go-live changes released in governed cycles, not on demand
Microsoft's Power Platform ALM guidance applies the same principles to low-code environments. Environment governance, data loss prevention policies, and solution lifecycle management are not optional for Power Platform deployments in enterprise settings.
The practical implication: if your current support model allows changes to be deployed directly to production without a test pass, your customisation governance is already broken, regardless of how good the original architecture was.
When Should Power Platform Be Used Instead of Custom Code?
Power Platform is one of the most underused governance tools in Dynamics 365 programmes. Most teams think of it as a reporting or automation add-on. The more useful framing is this: Power Platform can absorb peripheral requirements that would otherwise force unnecessary changes to the core ERP or CRM.
Where Power Platform adds value without touching core architecture
- Approval workflows and notifications that do not need to live inside Finance and Operations
- Lightweight mobile or portal experiences for field teams, contractors, or external parties
- Regional process variations that are operationally important but not core to the platform design
- Dashboards and operational reports that do not require changes to standard BI or financial reporting
- Integration orchestration between Dynamics 365 and third-party systems, using Power Automate rather than custom X++ code
Where Power Platform still needs governance
- Low-code does not mean low-risk. Every Power Platform solution needs environment control, data loss prevention policies, and a named owner
- Solutions built without ALM discipline create the same technical debt as poorly governed custom code
- Connectors to external systems must be reviewed for data residency and compliance, especially in Saudi Arabia where data sovereignty is a board-level concern
The governance principle: use Power Platform to protect the core, not to bypass governance. A well-governed low-code layer reduces implementation cost, preserves upgradeability, and keeps the ERP architecture clean.
How Do You Support a Dynamics 365 Environment with High Customisation?
If your organisation is already running a heavily customised Dynamics 365 environment, the answer is not to freeze everything and hope nothing breaks. The answer is to reintroduce governance so that future changes improve value rather than compound the existing debt.
Starting point: understand what you have
Before any support model can work, you need four things:
- Customisation inventory - a complete register of every custom object, extension, and modification, including who built it and why
- Architecture review - an assessment of which customisations are safe, which are upgrade risks, and which are already causing instability
- Ownership map - every customisation assigned to a named business owner and a named technical owner
- Technical debt baseline - a clear picture of the remediation effort required to bring the environment back to a supportable state
Support operating model for high-customisation environments
The objective is not to freeze the system. It is to stop the accumulation of ungoverned change and create a model where every future modification is assessed, owned, and traceable. As we noted in our Dynamics 365 F&O customisation guidance, go-live is the beginning of value creation, not the end of the project.
How Transformation Intelligence Qualifies Customisation Decisions
Most customisation debates are symptoms of deeper organisational issues. Weak process ownership, unclear decision rights, poor business readiness, and unresolved operating model gaps all generate customisation pressure that looks like a technical problem but is actually a governance and alignment problem.
This is where Transformation Intelligence changes the conversation.
Rather than evaluating each change request in isolation, Transformation Intelligence provides the organisational context that determines whether a request reflects a genuine business gap or an unmanaged preference, a political escalation, or legacy behaviour that the transformation was specifically designed to remove.
The Alignyx Transformation Intelligence Platform maps customisation decisions against the organisational signals that matter:
- Executive alignment - is this change consistent with the agreed target operating model, or does it contradict a decision already made at leadership level?
- Transformation governance - does this change have a clear owner, a justified business case, and a defined impact boundary?
- Business readiness - is the requesting team prepared to operate the new process, or are they asking for customisation because adoption has not been achieved?
- Value realisation - does this change support the business outcomes the programme was designed to deliver, or does it move the system further from those outcomes?
No direct competitor in the Saudi Arabia or UAE Dynamics 365 market connects customisation governance to a broader transformation advisory method. That gap is significant. Technology changes are easy to approve. Organisational changes are harder to govern. Transformation Intelligence addresses both.
Protect the Architecture, Not Every Request
The right question when a customisation request arrives is not "can we build this?" It is "should this exist in the target operating model at all?"
Customisation should fill essential gaps in automation, workflow, and process design. It should not preserve old habits, accommodate poor adoption, or rebuild the legacy system inside a new platform.
Organisations in Saudi Arabia and the UAE operating Dynamics 365 need governance that protects architecture, compliance, and long-term value realisation. That governance must apply before go-live and with equal rigour after it.
Executive takeaway: The organisations that get the most value from Dynamics 365 are not the ones that customise the most. They are the ones that govern the most carefully.
If your organisation is managing ongoing customisation pressure, dealing with a heavily modified Dynamics 365 environment, or preparing for a post-go-live architecture review, Terracez works with IT leaders and transformation teams across Saudi Arabia and the UAE to assess customisation strategy, reintroduce governance, and protect long-term platform value. Speak with our advisory team to review your current customisation approach.
.png)
.png)
.webp)
