Configuration, Low‑code, Pro‑code

DfE follows a configuration‑first approach when building CRM services on Dynamics 365 and the Power Platform. This ensures solutions remain simple, maintainable and aligned with Microsoft best practice. Teams should always use the out‑of‑the‑box capabilities of the platform before considering customisation.

This tiered approach helps deliver changes quickly, reduces long‑term support needs and ensures solutions are easier to upgrade, test and operate across all environments.

Start with configuration (out‑of‑the‑box first)

Configuration is always the first option and should be used wherever the platform already provides the required behaviour.

Why configuration comes first

It reduces complexity and speeds up delivery.
It avoids unnecessary custom logic that must be maintained long‑term.
It ensures solutions stay close to the Microsoft product roadmap.
It is easier to test, deploy and support across environments.

Examples of configuration

Creating or modifying tables, columns, forms and views.
Configuring email templates, dashboards, and apps.
Using security roles, teams and business units.
Setting up queues, SLAs, routing rules, duplicate detection.

Use low‑code only when configuration is not enough

If configuration cannot meet a requirement, the next option is low‑code tools such as Business Rules, Power Automate and Power FX. These provide automation and logic without writing full code.

Why low‑code comes after configuration

Low‑code offers flexibility but introduces more moving parts.
It must still be maintained and kept aligned with ALM practices.
Overuse can create performance issues or fragmented logic.

Examples of low‑code

Business Rules for simple form-level logic (show/hide fields, set field values).
Power Automate flows for lightweight automation or simple integrations.
Power FX in command bar buttons or canvas apps.

Low‑code is powerful but should only be used when out‑of‑the‑box configuration cannot meet the requirement.

Use pro‑code only when the platform cannot meet the need

Pro‑code represents the highest‑complexity option and should only be used when configuration and low‑code cannot deliver the required behaviour.

Why pro‑code is the final option

It requires specialist skills and increases long‑term support overhead.
It must be thoroughly tested and version‑controlled.
It adds deployment complexity and strict ALM requirements.
It risks introducing dependencies outside the core platform.

Examples of pro‑code

Plugins for synchronous, complex or high‑performance server‑side logic.
JavaScript for more advanced client‑side scripting not possible with Business Rules.
Azure Functions / Logic Apps for bespoke integration or processing.
Custom PCF controls when no standard UI component meets the requirement.

Although pro‑code should be used only when configuration or low‑code cannot meet the requirement, there are cases where using a plugin for simple logic is appropriate. If a plugin provides a more efficient, scalable or predictable solution, particularly where synchronous execution or high performance is needed, it may be the preferred option.

Pro‑code is essential for certain scenarios but must be used sparingly, with clear justification and aligned to the solution design.

Summary

Teams must always start with out‑of‑the‑box configuration, move to low‑code only when needed, and use pro‑code only for requirements that cannot be met by the platform. This tiered approach ensures Dynamics 365 and Power Platform solutions are consistent, maintainable and aligned with DfE’s design principles and long‑term CRM strategy.