Choosing the Right Publisher and Prefix in Dynamics 365

When you create your first own solution, Dataverse asks for a publisher and a prefix. The dialog looks inconspicuous, and many inexperienced consultants tend to click through it quickly. The prefix then ends up in front of every field, every table and every option the team ever creates, and it cannot be changed afterwards.

What the prefix does technically

If you create a field called "Customer number" in a solution with the prefix contoso, its technical name becomes contoso_customernumber. From then on, this name appears in every script, every query and every integration.

The purpose is freedom from collisions. Two solutions from different origins can both create a field "Status" without getting in each other's way, because their technical names differ. In addition, the prefix makes it possible to identify which dependencies on third-party solutions exist within a solution.

The most common mistake: keeping the default prefix

Anyone who does not create their own publisher works with the default publisher of the environment, and its prefix is new. Accordingly, all columns created this way are called something like new_customernumber, new_project or new_status.

That works flawlessly from a technical point of view, which is often exactly why nobody notices it for years. It becomes unpleasant in two places. First, the name no longer says anything about who built a component, and in an environment that has grown over years, that is the only trace left. Second, other solutions like to use the default prefix too, which makes collisions more likely precisely there.

The second most common mistake: too many prefixes

The other extreme is just as widespread. Every sub-project creates its own publisher, and after three years the components of a single environment carry five different prefixes.

For operations this means: you can no longer see at a glance what belongs together. Filter the field list by one prefix and half of it is missing. A single prefix per organization is the better choice in the vast majority of cases, even when several service providers are involved.

My rules of thumb for the choice

• Keep it short. Two to three characters. The prefix precedes every name and uses up space within the length limit of technical names.
• Letters, lowercase, starting with a letter. The platform accepts only letters and digits and does not allow a digit as the first character.
• Base it on the company, not the project. con survives, contoso2024 does not.
• Do not use new, nor any of the prefixes used by Microsoft such as msdyn or msdynce.
• Decide once and document it. The next service provider needs to know which prefix to use, otherwise the next one appears.

When it is too late

Changing an existing prefix means recreating every affected component and migrating the data. For a grown environment that is practically out of the question.

What remains realistic: know the current state and set a clear rule for everything new. A solution export shows how many prefixes are in use and how your own components are distributed across them. One dominant prefix with a share of over ninety percent is a good sign. Three prefixes with a third each mean that three teams worked independently of each other here, and that often explains why the solution feels inconsistent. Numbers like this are one of the cheapest hygiene indicators, as described in why solution hygiene saves time and money. And whether the solution carrying the prefix should be delivered managed or unmanaged is the next decision, covered in what is an unmanaged solution.