Microsoft Dynamics 365 · Programming
Microsoft Dynamics 365 is a platform, not a product. Anyone searching for "Microsoft Dynamics 365 programming" usually means one of five very different programming models — Dataverse plug-ins in C#, JavaScript Client API in the browser, Power Fx in the low-code maker, AL for Business Central, or PCF Controls in TypeScript. We classify these five worlds, show when programming rather than configuration is the right answer, and lay out our packages, day rates, and six typical programming mistakes. With 20+ years of Microsoft practice since CRM 3.0.
Terminology
Three terms get mixed up in the market — customization, configuration, and custom development. Anyone comparing offers should separate them cleanly.
Configuration means what you can achieve without a code editor — adjust tables, design forms, define business rules, build workflows, assign security roles, configure views. Anyone working in the modern Power Apps maker world sees configuration at first glance as "clickable". It produces solution artifacts that travel with dev-test-prod ALM — but no build, no compile.
Customization is Microsoft's umbrella term for all non-standard parts of a Dynamics 365 solution. In the narrower sense it means the code share — plug-ins, JavaScript, PCF Controls, Custom APIs, AL extensions. In the broader sense it also covers structural adjustments (custom entities, custom fields, custom workflows). We use "customization" in the broader Microsoft sense and say "pro-code components" when we concretely mean the code share.
Custom development means larger, often standalone software components — for instance a Power Apps Portal with custom branding, an Azure Functions backend layer for third-party integration, a native mobile app, or a custom web front-end against the Dataverse Web API. Custom development is the bridge between platform programming and free software engineering — and the area where our Independent Engineering team works with .NET, React, and Node.
A second dividing line runs between the module worlds: Customer Engagement (Sales, Customer Service, Field Service, Project Operations, Customer Insights) is extended via plug-ins in C#, JavaScript Client API, PCF Controls, Power Fx, and Custom APIs — this world runs on Dataverse. Business Central as the SMB ERP app is extended via AL extensions, its own language with its own runtime and compiler. Finance & Operations uses X++ and extensions in the Application Object Tree and is a third world, for which we work together with specialized F&O partners.
Programming models
If you search for "Dynamics 365 programming" or "Dynamics CRM programming", you mean one of these five models. They differ in language, runtime, where they sit, and skill profile — and are usually combined.
.NET · C# · Server-side
Server-side .NET components in C# that react to pre/post operation events in the Dataverse pipeline — for example "after saving an Account, recalculate the credit limit". Deployed in all CE modules (Sales, Customer Service, Field Service, Project Operations).
Skill profile: .NET depth, Dataverse SDK, IPluginExecutionContext, sandboxed plug-in limits (2-minute runtime, 5 MB outgoing).
JavaScript · TypeScript · Browser-side
Browser-side logic in the Unified Interface web form — show or hide fields, validations with dialog, sub-grid refreshes after API calls. Web Resources are deployed via ALM in solutions and versioned.
Skill profile: JavaScript ES6+, ideally TypeScript, Xrm.WebApi, Form Context lifecycle, async/await patterns.
Low-code · Declarative
Declarative formula language (Excel-like syntax) for canvas apps in Power Apps and cloud flows in Power Automate. Power Fx is both low-code in the maker portal and pro-code in YAML-based source control at the same time.
Skill profile: Power Apps Canvas, Dataverse connector, performance patterns for large lists, ALM with managed solutions.
AL · Pascal-like · ERP
Language for Business Central extensions, inheriting from the C/AL world of Navision. AL code runs as a versioned extension on the Business Central server (cloud or on-premises), with symbol files, translations, and an app manifest.
Skill profile: AL patterns, Business Central server architecture, AL Code Analyzers, translation workflows, AppSource submission process for ISVs.
TypeScript · React · UI
PowerApps Component Framework — TypeScript-based custom controls that are used as replaced fields or datasets in model-driven apps and canvas apps. For example an interactive Gantt chart instead of a sub-grid list, or a custom color picker.
Skill profile: TypeScript, React (optional but common), pac CLI, npm build toolchain, manifest schema, ControlContext lifecycle.
Azure · .NET · Custom APIs
Strictly not a "Dynamics 365" programming model — but in practice barely separable. Complex logic moves into Azure Functions or Dataverse Custom APIs because plug-in limits (2 min, 5 MB) would otherwise blow up. Call via Web API, REST, or Service Bus.
Skill profile: .NET, Azure Functions hosting, Service Bus, Application Insights, Managed Identity, OAuth against Dataverse.
Decision heuristic
Before every customization stands the question: can we do this without? A rough heuristic we use in the discovery spike to separate the shares.
| Requirement | Configuration (no-code) | Programming (low- or pro-code) |
|---|---|---|
| Form logic (show/hide field) | Business rules | JavaScript Client API (for multiple conditions or async lookups) |
| Workflow automation | Power Automate cloud flows | Dataverse plug-ins (when synchronous or transactional) |
| Connect external API | Power Automate connector (standard connectors) | Azure Functions or Custom Connector (when auth-specific or high-frequency) |
| Complex validation | Business rules for simple rules | Plug-in or JavaScript Client API (when cross-entity or aggregate check) |
| Custom UI component | Form designer with standard controls | PCF Control (when interactive element like Gantt, Calendar, Map) |
| Calculation logic | Calculated & rollup columns | Plug-in (when rollup limits or speed are critical) |
Rule of thumb: If you can express the requirement to 80% in the standard, configuration is enough. As soon as more than 20% shows up as "but with us it's different", pro-code components come into play. In the discovery spike we cleanly separate the shares — and avoid customization arising out of habit rather than necessity.
Selection criteria · vendor-neutral
These criteria apply regardless of whether you work with arades or with another Microsoft Partner. Anyone appearing as a "Dynamics 365 developer" should be able to answer all six — otherwise a one-sided skill profile with downstream cost arises.
01
How many plug-ins in production? How many Custom APIs? How deep does the understanding of Dataverse security, Business Units, Hierarchical Security, Field-Level Security sit? Anyone evading these questions has rarely built under load.
02
Source control with Azure DevOps or GitHub, managed solutions in test and prod, dev-test-prod environments, Power Platform Build Tools for CI/CD. Anyone working without an ALM pipeline builds solutions that no one except the original developer can extend.
03
If Business Central is involved or coming: real AL extension experience, not just C/AL legacy from Navision. Symbol files, translation workflows, AppSource submission process for ISVs, Business Central server architecture cloud and on-premises.
04
Anyone building form logic in 2019 patterns (var instead of let, no Promise.all, old Xrm.Page notation) leaves technical debt. ES6+, ideally TypeScript, clean async/await in the Form Context lifecycle — that's today's minimum standard.
05
Azure Functions, Service Bus, Application Insights, Managed Identity, OAuth against Dataverse — these skills are necessary as soon as plug-in limits get blown or external systems are in play. Custom code in Dataverse alone rarely suffices for a productive mid-market setup.
06
Day rate or fixed-price sprint — both models are legitimate, but they should be named openly. Anyone responding to "What does it cost?" with "it depends" and not committing to a range either has no pricing model or fears the answer.
Where arades is strong
We don't do everything equally well. These six areas are where we work from deep practice — with our own codebases, documented patterns, and productive mid-market implementations to back us up.
Server-side .NET components for CE modules. Deep in pre and post operation pipelines, plug-in steps with filtering attributes, clean separation between synchronous and asynchronous. With on-premises CRM history back to CRM 3.0, migration experience into the cloud.
TypeScript-based custom visuals — Gantt components, map components, custom sub-grid renderers. Plus classic Web Resources for form logic. We cleanly separate where a Web Resource is enough and where a PCF Control justifies the added value.
Power Fx in canvas apps with clear performance patterns, custom connectors for our own REST APIs, solution-based ALM with dev-test-prod pipeline. We use low-code where it carries — and build a pro-code backbone where it doesn't.
Extensions for Business Central Cloud and On-Premises. Our own app-manifest structures, translation workflows, AL Code Analyzer in CI. For ISV initiatives we know the AppSource submission process from our own practice.
When platform programming hits its limits, we have our own stack to back us up: .NET, Azure (App Service, Functions, Service Bus), React front-ends, Node back-ends. That's how we build Custom APIs, backend services, and special UIs as a clean extension of the Dynamics 365 world.
Quality gates, documented test strategy, code reviews with two-eyes principle, defined Definition of Done per sprint. Custom-code delivery as a process — not as "the developer knows what they're doing".
Packages & day rates
From a 1-week discovery spike to a multi-month embedded-developer retainer. Which form fits depends on the clarity of the requirement and the desired speed — not on volume alone.
1 week fixed price. Requirements analysis, architecture sketch, clickable prototype in the target environment, documented effort range for the follow-on sprint. Ideal when the requirement is still fuzzy — the spike sharpens it.
4 weeks fixed price. Concrete customization delivery — for example three plug-ins, one PCF Control, a JavaScript layer for a form, a Power Automate integration. With code review, test strategy, and ALM pipeline.
Monthly retainer. One to four developers for three to twelve months, embedded into your team or as an external squad. Suited for roadmaps with continuous delivery demand — for instance when building out an industry solution on Dataverse.
Concrete day rates after the 30-minute discovery — depending on seniority (Junior, Senior, Architect) and skill profile (plug-in, PCF, AL).
Six typical programming mistakes
These six mistakes show up in almost every custom-code estate we take on in an architecture review or knowledge-recovery phase — in code from third-party partners and sometimes also in our own from earlier years. Better named than hidden.
Direct SQL access to the Dataverse database, unauthorized DLL patches in the plug-in sandbox, "undocumented but working" API calls against Microsoft-internal endpoints. Works — until the next release wave. Microsoft does not tolerate this area, and a lift-and-shift into the cloud reliably fails because of it.
A plug-in in the pre-operation step calls an external API that answers in 30 seconds (or not). That blocks the user's save transaction, blows the 2-minute limit, and leads to timeout errors in every third operation. The correct path: asynchronous or via a Service Bus queue with an Azure Function.
The plug-in says "lookupOptionSetValue = 100000001" — the GUID or the OptionSet value of a lookup directly in code. Works in dev, breaks in test (different GUID), breaks in prod (different again). The correct path: configuration entity with schema-name lookup or FetchXML against a uniqueness column.
JavaScript file is patched multiple times without a solution update, the browser cache delivers the old version, the user sees a random mix. The correct path: versioned solution import, cache-busting suffix on every change, ideally via a build pipeline.
A canvas app that runs smoothly in the demo with 50 records takes 18 seconds for the first render in production with 12,000 records. Power Fx has clear delegation limits — ignoring them means building apps that work in demo and freeze in production. The correct path: take delegation warnings seriously, put aggregate logic in Dataverse instead of the client.
Customization is done directly in the production environment "because it's faster". Solutions are unmanaged, nobody knows what's really productive. With a rollback the solution is gone. The correct path: dev-test-prod environments, managed solutions from test on, source control for all custom-code parts.
Qualification
We have been programming Dynamics 365 since Microsoft CRM 3.0 (2005). Through every platform shift, every release-wave rebrand, every license-model change — and with our own codebase to back us up. Our practice-tested developers work in teams of two to four people with mixed skill profiles, not as full-stack lone fighters.
Frequently asked questions
We start with a discovery spike as a fixed price (1 week, from €6,500 net). From that comes a clickable prototype and a realistic effort range. A customization sprint over four weeks is offered as a fixed price from €25,000 net. Longer engagements run as an embedded-developer retainer with a transparent monthly or day rate. The concrete day rate depends on seniority and skill profile and is named after the discovery conversation.
AL (Application Language) is the language for Business Central — the SMB ERP app in Dynamics 365. AL code runs in extensions on the Business Central server and inherits from the C/AL world of Navision. Plug-ins usually mean Dataverse plug-ins: server-side .NET components in C# that react to pre/post events in the CE apps (Sales, Customer Service, Field Service, Project Operations). Both are pro-code, both are delivered with source control and an ALM pipeline — but they run on two different runtime environments.
Customer Engagement (Sales, Customer Service, Field Service, Project Operations) runs on Dataverse and is extended via plug-ins (.NET), JavaScript Client API, Power Fx, PCF Controls, and Custom APIs. Finance & Operations uses X++, extensions, and the Visual Studio Application Object Tree — a world where you more likely customize the SCM and Finance modules. arades serves the CE stack and Business Central in-house; for F&O custom code we work with specialized F&O partners from our network. Background in the D365 ERP topic area.
Some yes, some no. Plug-ins written in supported fashion (no direct SQL access, no impersonation outside the plug-in pipeline) can often be migrated to Dataverse with manageable effort. JavaScript for web forms and web resources must be rebuilt on the Unified Interface. Classic SSRS reports are usually replaced by Power BI. We review the custom-code estate in a discovery spike and deliver a migration plan with rebuild quota, lift-and-shift quota, and deliberate-non-migration quota.
For canvas apps and Power Automate flows: yes, with clear guardrails. We deploy Power Fx in productive mid-market apps, but we pay attention to four points — clean data-source architecture (preferably Dataverse), explicit performance tests with lists over 2,000 records, an ALM pipeline with dev-test-prod solutions, and a clear separation between citizen development and pro-code components. Where Power Fx hits performance or complexity limits, we build Custom APIs in Azure Functions as a backend.
Configuration means what you can achieve in the maker portal without code: customize forms, define views, set up business rules, build simple workflows, assign security roles. Customization means code: plug-ins, JavaScript Client API, PCF Controls, Custom APIs, AL extensions. Rule of thumb — if 80% or more of your requirement can be expressed in the standard, configuration is enough. As soon as more than 20% shows up as "but with us it's different", pro-code components come into play.
If your process is standard, standard is enough. Microsoft Dynamics 365 covers a great deal, and much of what was custom code ten years ago is configuration or Power Fx today. External development pays off when your process is a competitive advantage (industry logic, custom calculation models, integrated third-party systems) or when you need to land in the cloud with legacy custom parts. In the discovery spike we separate what becomes configuration and what we actually code.
Azure DevOps Repos or GitHub for source control, Power Platform Build Tools for solution deployment, Azure Pipelines for CI/CD. Dev-test-prod environments with managed solutions in test and prod, unmanaged in dev. For Business Central we use the official AL templates and the Microsoft AL Language Extension toolchain. PCF Controls are packaged via npm build with the pac CLI. ALM is not an add-on with us, it's a delivery foundation.
Rarely. Plug-in development in C# requires .NET depth and Dataverse API understanding. JavaScript Client API requires front-end experience in the Unified Interface lifecycle. AL for Business Central is its own world with its own patterns. PCF Controls are TypeScript with React parts. Power Fx is declarative. We work in small, mixed teams (typically 2–4 people) who share the models — the notion of the "full-stack Dynamics developer who can do everything" is a marketing fairy tale.
When what you code would be a Microsoft standard that's just unknown to you. When the code performs synchronous database operations in a plug-in that waits for an external API. When JavaScript carries form logic that a business rule could also express. When GUIDs are hard-coded instead of being retrieved via FetchXML. When no one but the original developer understands the code. Before every customization comes the question: can we do this without?
Further reading
The associated service page for the delivery format: discovery spike, customization sprint, and Application Care. With delivery models, discovery logic, and transition into Application Care.
Before you commission programming: module selection, license architecture, and roadmap. Discovery conversation, strategy workshop, and architecture review.
Four categories of extensions: AppSource marketplace, custom solutions, own solutions, plug-ins. Before custom development, it's worth looking at what already exists.
Three introduction packages and the 4-phase model (Discovery, Build, Migration and UAT, Hypercare). Programming is usually part of the build phase.
After go-live: predictable Application Care contract with monthly flat fee for custom-code maintenance, releases, and enhancements.
When platform programming hits its limits: our own stack with .NET, Azure, React, and Node — as a clean extension of the Dynamics 365 world.
30 min · free · no obligation
Tell us what is to be programmed — a plug-in extension, a PCF Control, an AL extension, or a Power Fx app. We classify, propose the fitting programming model, and give you a first effort range. On a fit, transition into a discovery spike.
