Microsoft Dynamics 365 CRM development and customization on Dataverse

Buyers say CRM, CE or customer engagement. Microsoft calls them customer engagement apps: Microsoft Dynamics 365 Sales, Customer Service, Field Service and Customer Insights - Journeys. They share one platform, Microsoft Dataverse, with the same tables, security model and solution packaging. One development approach therefore covers all of them, and model-driven Power Apps built on the same tables.

Business Central and Finance and Supply Chain Management are separate ERP products. They use AL and X++, not Dataverse plug-ins, and need different specialists. If your project spans both worlds, the CRM side is built here and the ERP side follows its own product rules; our product comparison explains the split.

Before we change anything, we confirm which apps and licenses you run, which solutions are installed, and what was customized outside a solution.

If customers or dealers need a separate website to submit or view records, review Power Pages development for customer and partner portals. The portal plan defines each audience's sign-in, permitted records and access checks. It is a different scope from changes to the internal CRM screens.

Usually, yes. Most CRM problems come from a few causes: a data model that grew without a plan, security that no longer matches the organization, or customizations nobody owns. Fixing those in place keeps your data, history and integrations. Replacing the platform repeats the migration and retraining cost.

We start with a review of the environment. It needs:

• System customizer access to a sandbox copy of production.
• The installed solutions, plus the source code of any plug-ins and PCF controls.
• A list of integrations, the application users they run as, and scheduled jobs.
• Known problems from users and support tickets from the last few months.

The review lists what to keep, what to repair and what to retire. Changes made directly in production as unmanaged customizations are captured in a solution first, because they sit in the unmanaged layer above every managed solution and can hide the behavior of later releases.

Dataverse security has several layers, and most access problems come from mixing them up:

• Security roles grant privileges per table at an access level: user, business unit, parent and child business units, or organization. Roles add up, so one generous role widens access everywhere it applies.
• Business units separate data between regions, brands or legal entities.
• Teams give groups shared ownership or access to records without copying roles to every person.
• Column-level security profiles restrict reading or updating single columns. They do not apply to system administrators, so the administrator role stays with very few people.
• Application users run integrations with only the privileges each integration needs.

We document the model in a role matrix your administrators can maintain, and we test it with real user accounts rather than an administrator login.

The steps above describe project work: MS Dynamics Guys agrees a change, builds it, passes acceptance and hands it over. Some companies already run their own CRM backlog, code reviews and releases. They need extra people inside that process, not a provider with a separate one.

• C# and PCF work. A Microsoft Dynamics 365 CRM developer joins your team. Your lead assigns plug-ins, custom APIs and controls. The developer builds, tests and documents each one in your solution.
• Configuration and testing. A CRM consultant runs workshops, configures forms and security roles, and prepares user acceptance testing (UAT). The consultant hands each rule that needs code to a developer as a written requirement.
• The sales process alone. A Sales consultant works with your sales operations lead on leads, pipeline stages and forecasts.

In staff augmentation, your lead directs that person day to day, and the agreement covers onboarding, access and the exit.

Dataverse protects shared capacity with service protection limits. Each web server applies them to each user on its own. Microsoft's documented defaults are 6,000 requests and 20 minutes of combined execution time in a five-minute sliding window, plus 52 or more concurrent requests, and Microsoft says these values can change. Integrations and bulk jobs reach these limits long before people do.

We design for them up front. Integration users are split by workload, bulk work uses batches and asynchronous processing, and every client handles the retry response Dataverse returns when a limit is reached. Synchronous plug-ins stay short, because the user waits for them and the platform stops plug-ins that run too long.