Catalogue › Design Authority › customisation-challenge

Customisation challenge

Department

Design Authority

Stages

Initiate, Implement

Modules

All

Status

reviewed

Copilot Cowork

Design Authority plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Claude Code

/plugin install design-authority@d365forge

Licence

CC BY 4.0, by Simon Foote, Robert Peledie

Every customisation is a long-term cost. It has to be tested against each release wave, documented, supported, and eventually retired or rebuilt when Microsoft ships something better. Projects over-customise because each request seems reasonable on its own, because users want the old system's behaviour back, or because developers would rather build than configure. A few years later the organisation owns a bespoke CRM sitting on a platform it pays to keep standard.

This reviewer-class skill is the formal challenge. Before a gap is filled with anything beyond configuration, someone outside the build team asks whether it needs filling at all and, if so, at the lowest rung of the hierarchy that works. It is read-only: it reviews the proposal and reports findings, and the proposing department owns the decision record and the build.

When to use

• A team proposes a plug-in, custom API, PCF control or client script.
• A new custom table duplicates something a standard table could hold.
• An ISV product is proposed to fill a gap.
• Users ask for the legacy system's behaviour to be recreated.
• A low-code solution is growing into something that needs pro-code support.

Not this skill: business-analysis:fit-gap-analysis for identifying the gaps, solution-architecture:extend-or-configure for the architect's own design choice, design-authority:design-review for reviewing a whole design, and design-authority:standards-conformance for checking a built component.

Questions to ask first

1. What business outcome does the gap serve, and what happens if it is not filled? Many gaps turn out to be preferences rather than requirements.
2. Has the standard process been shown to the business, and why was it rejected? Familiarity with the old system is not a reason to customise.
3. Who will support the component after go-live, and with what declared skills? Pro-code without a maintainer becomes an orphan.
4. Does the proposal depend on a preview feature or a roadmap item? Check current Microsoft Learn documentation; preview features are not a production foundation.

Approach

Walk each proposal down the hierarchy and stop at the first rung that meets the need.

1. Adopt standard. Can the business change its process to fit standard behaviour? This is the cheapest option and is often dismissed too quickly. Ask the process owner, not only the requester.
2. Configure. Can standard configuration (columns, forms, views, business rules, business process flows, security roles, SLAs, routing rules) meet the need? Configuration survives upgrades and can be maintained by administrators.
3. Low-code. Can Power Automate, Power Fx or a Copilot Studio agent meet it? Low-code is cheaper to change but still needs ALM, ownership and error handling; it is not free.
4. Pro-code. Plug-ins, custom APIs, PCF controls and client scripts are justified when transactional integrity, performance or user experience demand them. Require unit tests, source control and a named maintainer.
5. ISV. A third-party product may beat building, but challenge vendor viability, the vendor's record of keeping pace with release waves, data residency, the exit route and licensing (ask the vendor for its terms, and for Microsoft licences confirm with the Microsoft licensing guide or your partner).

For every proposal, test supportability over time. How will it behave through the next few release waves? Does it rely on unsupported techniques such as direct manipulation of the page structure or undocumented APIs? Who maintains it, and what would removing it later cost? Does it overlap with something on Microsoft's published release plans?

Record each finding with its classification.

• Blocking: the proposal uses unsupported techniques, has no maintainer, skips a lower rung that clearly meets the need, or creates risk the blueprint does not allow. It cannot proceed until resolved.
• Advisory: a lower rung might work, or supportability could be improved; the department records its decision and may proceed.

Blocking findings are not overruled by the department under review. Where it disagrees, the matter escalates to the steering committee or executive sponsor, who may accept the customisation and its long-term cost explicitly.

Outputs

• Challenge record per proposal, stating the rung chosen and the rationale.
• Findings classified as blocking or advisory.
• Customisation register (what was built, why, owner, next review date) kept alongside the solution-blueprint.
• Accepted technical debt recorded in the raid-log.

Scale notes

SMB

The lead consultant plays this role and is often challenging their own team's proposals, so a second-pair-of-eyes review from someone outside the delivery is worth arranging for anything pro-code or ISV. SMB organisations rarely have developers to maintain custom code, so the bar for pro-code should be higher, not lower.

Enterprise

The design authority board runs the challenge with a defined submission template, and the customisation register is reviewed at every release wave. Expect pressure from workstreams with tight deadlines; the hierarchy protects the long-term estate and must be applied consistently across modules.

Hand-offs

• Proposals that pass go to solution-architecture:extend-or-configure for design, then to platform-engineering:plugin-design, platform-engineering:pcf-controls, platform-engineering:power-automate-patterns or platform-engineering:copilot-studio-agents to build.
• Built components are checked by design-authority:standards-conformance.
• Escalations reach the steering committee through programme-management:governance-cadence.

Sources

references/sources.md in this skill lists the outside authorities for the questions here, what each is authoritative for, and what you may do with it. Check the current Microsoft Learn documentation before stating how a feature behaves, because Dynamics 365 changes monthly, and cite what you used.

Never

• Approve pro-code where configuration or a process change meets the need.
• Accept customisations that rely on unsupported techniques or undocumented APIs.
• Approve an ISV product without assessing vendor viability, licensing and exit route.
• Let the proposing department overrule a blocking finding.