Catalogue › Solution Architecture › extend-or-configure

Extend or configure

Department

Solution Architecture

Stages

Initiate, Implement, Operate

Modules

All

Status

reviewed

Copilot Cowork

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

Claude Code

/plugin install solution-architecture@d365forge

Licence

CC BY 4.0, by Simon Foote, Robert Peledie

Every extension is a liability the organisation carries for the life of the system. It must be tested against each Microsoft update, understood by the support team and kept compatible with features Microsoft adds later. The question is never whether something can be built, because almost anything can, but which is the lowest rung of the ladder that meets the need acceptably.

Projects go wrong when the build approach follows the skills of whoever picks up the story. A developer writes a plug-in for what a business rule would do, a maker builds a flow for logic that must run inside the transaction, or an ISV product is bought for one feature. Each choice is defensible alone; together they produce an estate nobody can upgrade with confidence.

When to use

• A gap from the fit-gap register needs an architectural build decision.
• Someone proposes a plug-in, PCF control, custom page, ISV product or Azure component.
• The design authority asks why a requirement was not met with standard features.
• A post-go-live enhancement request needs a consistent sizing of build approach and run cost.

Not this skill: business-analysis:fit-gap-analysis to classify and record the gap register, business-analysis:fit-to-standard to challenge the process first, design-authority:customisation-challenge for the independent challenge, and platform-engineering:plugin-design, platform-engineering:pcf-controls or platform-engineering:power-automate-patterns for the build itself.

Questions to ask first

1. What business outcome does the requirement serve, and what is lost if standard behaviour is used instead? This tests whether the gap is real or a preference.
2. Must the logic run inside the save, or can it run afterwards? This alone rules whole rungs in or out.
3. How often does it run, and at what volume? High-volume logic is a poor fit for some low-code tools.
4. Who will maintain it after go-live, and with which skills? A solution the run team cannot support is not a solution.
5. Does it depend on premium connectors, ISV subscriptions or Azure consumption? These add running costs; confirm with the Microsoft licensing guide or your partner.

Approach

Climb the ladder one rung at a time and record why each lower rung was not enough. From lowest to highest cost of ownership:

1. Adopt the standard. Change the process to fit the product where the difference adds no business value. This is the cheapest option and the one most often skipped.
2. Configure. Columns, forms, views, business rules, business process flows, SLAs, routing rules, schedule board settings and app settings. Configuration moves with the product and needs no code skills to maintain.
3. Low-code. Power Fx formula columns, cloud flows, custom pages and similar tools. A good fit for logic that can run asynchronously or is owned by makers, within the limits set out in platform-engineering:power-automate-patterns.
4. Pro-code inside Dataverse. Plug-ins, custom APIs, client scripts and PCF controls. Right for synchronous, transactional or high-volume logic and for interface needs configuration cannot meet, but it needs developer skills in the run team.
5. ISV or AppSource product. Sensible for a substantial, well-bounded capability such as document generation, address validation or mapping that a vendor maintains. Check the vendor's record of keeping pace with Microsoft updates, its support model and how you would exit.
6. External services. Azure Functions, Logic Apps or Service Bus for heavy processing, long-running work or integration patterns that do not belong in Dataverse.

Score each candidate against the same criteria: fit to the requirement, run cost, upgrade exposure, test burden, skills needed to maintain it, and licensing. Prefer the lowest rung that scores acceptably, even when a higher rung would be more elegant.

Unsupported techniques sit off the ladder altogether. Manipulating the page DOM, calling undocumented endpoints or changing data outside the platform's APIs can break without warning on any update, and no business case justifies them.

Record each decision in the blueprint's decision log with the rung chosen, the rungs rejected and why. Gap types repeat, so once the design authority agrees an answer for one type, reuse it as a pattern rather than arguing it again.

Outputs

• A build decision for each gap or proposal, recorded in the decision log of the solution-blueprint.
• A customisation register listing every extension, its rung, owner and upgrade risk.
• Assessment notes for any ISV product proposed.
• Entries in the raid-log where a decision carries upgrade or support risk.

Scale notes

SMB

Stay on the bottom three rungs wherever possible, because the support team is small and may not include a developer. When code is unavoidable, make sure the partner hands over source, documentation and a support arrangement. Do not skip recording the decision; it is the only defence when the next consultant asks why something was built.

Enterprise

Standardise answers to recurring gap types in a pattern catalogue owned by the design authority. Workstreams propose, the solution architect applies the ladder, and anything at rung four or above goes to independent challenge. Track the size and risk of the customisation register as a programme measure.

Hand-offs

platform-engineering:plugin-design, platform-engineering:pcf-controls or platform-engineering:power-automate-patterns build the chosen approach, and integration-and-data:integration-architecture picks up rung six when the need is an integration. design-authority:customisation-challenge must clear anything at rung four or above before build starts.

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

• Use unsupported customisation techniques such as DOM manipulation or undocumented endpoints.
• Write custom code for a requirement that standard configuration meets acceptably.
• Choose a build approach the run team cannot maintain.
• Recommend an ISV product without checking its update record, support model and exit path.
• Climb a rung without recording why the lower rungs were rejected.