CRM development process

(3) Share

Report

Posted on by DELDYN

582

Hi,

I'm new to CRM and i want to understand the difference between it and FO in terms of development.

For example, in FO:

We use visual studio
We use devops when checking-in the code
If there is ISV model, we can't look at their custom code, and if we need to add to it, then we need to create extensions, and sometimes we might be blocked and need the ISV to do sth to make the change
Or there could be custom code owned by the client, that was done by another company but still not ISV, so if a new company works for the client, they can edit the custom code directly as they have access to the model that was created by another company

How would that change for CE, how would the 4 points be different?

Categories:

Microsoft Dynamics CRM

All responses (4)

Answers (1)

Sort by

Verified answer

Syed Aqib Raza 243 on at

Like (3)

Report
Copy link

Link copied!
Coming from F&O, the biggest difference is that CE/Dataverse is much more solution and metadata driven, whereas F&O is more code/model driven.
For your four points:
1. Visual Studio
In F&O, Visual Studio is central to development (X++, models, extensions, etc.).
In CE, you can do a lot through Power Apps/Power Platform without Visual Studio: tables, columns, forms, views, business rules, apps, flows, etc. For more advanced development you use Visual Studio/VS Code for things such as C# plugins, JavaScript/TypeScript, PCF controls, custom APIs, etc.
So Visual Studio is still important in CE, but it isn't the starting point for every customization.
2. DevOps / source control
CE also supports proper ALM and source control. The key concept is Solutions.
Typically you have:
DEV → unmanaged solution → source control/CI-CD → TEST/UAT → PROD
Unmanaged solutions are normally used for development, while managed solutions are deployed to downstream environments. Microsoft explicitly recommends managed solutions outside development environments.
Azure DevOps/GitHub can be used for source control and pipelines. Power Platform also has native capabilities around Git integration and pipelines.
3. ISV/custom code
The concept is very similar to what you're used to in F&O, although the mechanics are different.
If an ISV provides a managed solution, you generally don't just open their solution and modify their code. You extend/customize around it, subject to the component's managed properties and the extension points available.
Managed solution components aren't directly editable in the same way as your own unmanaged components. You can create your own unmanaged customizations on top of managed solutions, which creates solution-layer/dependency relationships.
So an ISV might provide:
ISV Managed Solution ↓ Your Solution ↓ Your customizations/extensions
If the ISV doesn't expose an appropriate extension point, you may still need the ISV to provide a change, similar in principle to being blocked by an ISV model in F&O.
4. Client-owned customizations from a previous implementation partner
This is where you need to distinguish between Dataverse components and the actual source code.
If the previous partner created an unmanaged solution and you have access to the development environment, you can generally customize those components.
However, if they created a C# plugin, for example, having access to the Dataverse environment doesn't automatically give you their original:
PluginProject.sln Plugin.cs Unit tests CI/CD pipeline
You would need the source repository/project to properly maintain and rebuild that code.
The same applies to JavaScript, PCF controls, Azure Functions, etc.
So I wouldn't think of CE as "there are no models and everything is editable." Instead, think of it as:
F&O: Visual Studio ↓ X++ / Models / Extensions ↓ Build & Deploy CE: Power Apps / Visual Studio ↓ Dataverse Components + Code ↓ Solution ↓ Source Control / CI-CD ↓ Managed Solution ↓ TEST / UAT / PROD
One important point when moving from F&O to CE is that Solutions are essentially the equivalent of the packaging/ALM boundary you need to understand first. They contain components such as tables, columns, forms, views, apps, flows, web resources, etc., and are the mechanism used to move customizations between environments.
So the short answer is: CE absolutely supports professional development, source control, CI/CD, extensions and ISV solutions. The major difference is that the development model is much more component/solution/metadata driven, with code being used where configuration isn't sufficient.
Suggested answer

CU23070650-1 47 on at

Like (2)

Report
Copy link

Link copied!

Hi,
From my understanding, CE/CRM development is quite different from F&O, especially because CE is built on the Power Platform and Dataverse. However, there are still similarities in terms of source control, customization, and ALM.
Regarding your four points:
1. Development tools
In F&O, Visual Studio is the primary development environment for X++ development.
In CE/Dataverse, development can be done in multiple ways depending on the requirement. For example, we can use Power Apps for low-code/customization work, Power Automate for automation, Power Pages, and JavaScript/TypeScript for client-side customizations. For pro-code development, we can use Visual Studio/VS Code and Power Platform CLI for things such as Dataverse plug-ins.
So, it isn't necessarily "Power Apps instead of Visual Studio"; it depends on whether we are doing low-code or pro-code development.
2. Source control / DevOps
In F&O, we commonly work with Visual Studio and Azure DevOps for source control, branching, check-ins, builds, and deployments.
In CE/Power Platform, the main ALM (Application Lifecycle Management) concept is the Solution. We normally develop using an unmanaged solution in the development environment and then move the solution through the environments, commonly as a managed solution for downstream environments.
Azure DevOps can still be used for source control and CI/CD. Power Platform also provides tools such as Power Platform Pipelines and Git integration for managing the ALM process.
3. ISV/customization scenario
This is where CE is somewhat different from the F&O model approach.
In F&O, if an ISV provides a model/package and we don't have access to its source code, we generally extend their objects rather than directly modifying their code.
In Dataverse, solutions and solution layers are used to manage customizations. If an ISV solution is installed as a managed solution, we cannot directly edit the components in that managed solution. Instead, we normally create our own solution and customize/extend the relevant components where the platform allows it. This also creates dependencies between our solution and the ISV solution.
For example, if an ISV provides a table, we may be able to add our own columns, relationships, views, forms, or other supported customizations through our own solution rather than modifying the ISV's original solution.
For pro-code components such as a plug-in, however, the situation is different. We don't get the ISV's original C# source code just because the plug-in is installed in Dataverse. If we need a change inside that plug-in's logic, we would generally need the ISV/vendor to provide the change.
4. Custom code owned by the client
This is also different from the F&O model concept.
In Dataverse, the important question is not simply whether another company originally developed the customization. We need to look at which solution owns the component, whether it is managed or unmanaged, the solution layers, dependencies, and what type of component it is.
If the customization is part of an unmanaged solution in the development environment and we have the required permissions, we can generally modify the components. If it is a managed solution, we cannot directly edit the managed component; we would normally create our own customization/solution on top of it where supported.
Deployment
One other important difference is deployment.
In F&O, we are familiar with models/packages, builds, deployable packages, LCS, etc.
In Power Platform/CE, Solutions are the primary packaging and deployment mechanism. We develop in an unmanaged solution and can export it as a managed solution for deployment to Test/UAT/Production. Power Platform Pipelines or Azure DevOps pipelines can then be used to automate the movement between environments.
So, I would summarize the major difference as:
F&O: Models/packages + X++ + Visual Studio + Azure DevOps + LCS
CE/CRM: Solutions + Power Apps/Power Platform + Dataverse + Azure DevOps/Git + Power Platform Pipelines

Hope these below links would help you,
Application lifecycle management (ALM) with Microsoft Power Platform - Power Platform | Microsoft Learn
Solution concepts with Power Platform - Power Platform | Microsoft Learn
Suggested answer

ParthPatel249 220 on at

Like (1)

Report
Copy link

Link copied!
The answers above cover the solution/ALM comparison well, so I'll add a few things not yet mentioned that trip people up most when moving from F&O to CE:
1. Layers: the closest F&O analogy
You'll recognize this instantly: F&O has USR/CUS/ISV/SYS layers stacking on top of each other. CE has the same concept via solution layers, just packaged differently. Each solution import creates a new layer on top of a component, and the topmost active layer wins at runtime. You can literally view this in Advanced Settings → Solutions → a component → Solution Layers it shows every solution that has ever touched that field/form, in order. This is the fastest way to answer “why isn't my change showing up” something else is layered on top of you.
2. Security model is different, not just development
F&O uses Duties → Privileges → Roles tied to menu items/AOT objects. CE uses Security Roles → Privileges (Create/Read/Write/Delete/Append/Append To/Assign/Share) per table, scoped by Business Unit level (User/BU/Parent-Child BU/Organization). There's no direct AOT-object security equivalent it's row-level and table-level, which changes how you design multi-entity customizations and ISV solutions (an ISV solution import does NOT grant privileges automatically; you must separately assign security roles).
3. Debugging/tracing tools differ
F&O: attach VS debugger to AOS, use Trace Parser.
CE: no direct server attach for plugins in the same way. You use:
Plugin Trace Log (enable via System Settings) for server-side plugin/flow errors
Application Insights integration for deeper telemetry
Browser dev tools for client-side JS/PCF debugging
Fiddler/Plugin Registration Tool's "Profile" feature to replay plugin execution locally in VS
4. Config differences across environments (no web.config equivalent)
In F&O you often manage environment-specific config via parameters tables or deployable package settings. In CE, environment-specific values (URLs, GUIDs, connection strings) are handled through Environment Variables and Connection References, which are themselves solution components they get exported with your solution but their values are set per-environment. This is the CE equivalent of not hardcoding environment-specific values into code.
5. Dependency checking before you delete/change anything
Before modifying or removing a component, CE has a built-in "Show Dependencies" action on any solution component it tells you exactly what else (forms, views, plugins, flows) references it, across managed and unmanaged layers. Useful when working on top of someone else's (ISV or previous partner's) customizations, since you often don't have full visibility otherwise.
These are the practical, day-to-day differences that matter once you're actually in the environment building things, on top of the solution/ALM concepts already covered above.
Suggested answer

Travis South 212 on at

Like (1)

Report
Copy link

Link copied!

You may be able to see and extend Dataverse components in an environment, but that does not mean you have the original C#, JavaScript, PCF, Azure Function, pipeline, or repository used to build them. For any handoff from another partner, I would verify the solution layers and confirm that the client actually has the source repo and deployment assets needed to maintain the custom code going forward.