AI and Copilot
Information architecture is the work that decides whether Copilot succeeds
Generative AI answers are only as good as the content behind them. The preparation that determines quality happens before any licence is assigned.
Article ยท Delivery
Choosing configuration over code, and knowing when not to
Configuration is cheaper to build and far cheaper to maintain, until the requirement genuinely exceeds the platform. A practical test for the boundary.
Every Microsoft business application project reaches a point where a requirement does not quite fit the platform. The choice is to adjust the requirement, configure a near-fit, or write code. That decision, repeated fifty times across a programme, determines what the solution costs to own for the next five years.
Why configuration usually wins
Configured behaviour is upgraded by Microsoft, documented publicly, understood by any competent administrator, and visible in the maker experience. Custom code is upgraded by you, documented only if someone remembered, understood by whoever wrote it, and invisible until it breaks. The build-cost difference is often modest. The ownership-cost difference is not.
A four-question test
- Is the requirement a genuine business rule, or an inherited habit from the system being replaced? Habits should be challenged before they are engineered.
- Does a configured near-fit satisfy the underlying business need, even if it changes the interaction? If yes, the difference is preference, and preference rarely justifies custom code.
- Will this rule change more than twice a year? Frequently changing rules belong in data or configuration, never in compiled logic.
- Can a competent administrator, three years from now, understand and safely change it? If not, the organisation has taken on a dependency it has not priced.
When code is the correct answer
Custom development is right when the requirement is genuinely outside the intent of the platform: complex calculation engines, high-volume integration with non-standard protocols, specialised algorithms, or performance profiles the platform is not designed for. Attempting these in low-code produces something worse than either option: fragile, undocumented, and hard to test.
| Signal | Lean configuration | Lean code |
|---|---|---|
| Change frequency | Rules change often | Logic is stable for years |
| Volume | Human-scale transactions | High-throughput processing |
| Ownership | Business administrators maintain it | Engineering team owns it |
| Testability | Behaviour verified through the interface | Requires automated unit coverage |
Record the decision
Whichever way the decision goes, write it down: the requirement, the options considered, the choice and the reason. A short architecture decision record costs ten minutes and answers the question that otherwise consumes a full day two years later.
Written by
Daniel Osei
Daniel designs and delivers Dynamics 365 and Power Platform solutions, with a strong bias towards configuration, explicit process design and data quality controls that hold up long after go-live. He has spent much of his career untangling CRM implementations that recorded administration rather than supporting work.
- Dynamics 365
- Dataverse
- Power Apps
- Process design
- CRM data quality
Relevant industries
- Government and Public Sector
- Professional Services
- Real Estate and Construction
Related insights
AI and Copilot
What actually blocks a Copilot rollout
Licensing is rarely the constraint. Five things stop deployments in practice, and four of them are decided before any technical work starts.
AI and Copilot
A practical Copilot readiness guide
A structured way to assess whether an organisation is ready to deploy Microsoft 365 Copilot, covering data, permissions, licensing, governance and adoption.