Publishers and prefixes

What it does

Every solution has a publisher, and the publisher carries a customisation prefix and a choice value prefix. The customisation prefix goes on the schema name of everything you create — contoso_accountnumber — so solutions from different publishers can coexist without colliding.

Key facts

The publisher of the solution where a component is created is the owner of that component. The owner controls what other publishers' solutions may and may not change about it.
Ownership can move between solutions belonging to the same publisher. It cannot move across publishers.
Once a component is introduced by a publisher in a managed solution, you can't change that component's publisher. This is why a single publisher per client gives you room to rearrange your solution layering later and multiple publishers doesn't.
The choice value prefix is a number generated from the publisher prefix. It's prepended to option values so you can tell which solution added an option.
The Common Data Services Default Solution uses the Microsoft Dataverse Default Publisher, whose prefix is randomly assigned — the cr8a3-style prefixes everyone recognises.
You can change the publisher on an unmanaged solution through Solutions > ... > Settings.
Changing a prefix only affects things created afterwards. Schema names of existing metadata can't be renamed.
Don't use _upgrade anywhere in a solution name. It's a reserved word in the upgrade process.
Setting a preferred solution controls where components land when you create them outside a solution context. Without one, you're working in the default solution.

When to use / skip

One publisher per client organisation, created on day one, used everywhere. That's it. The only reason to introduce a second publisher is if you're genuinely shipping something as a separate product with its own lifecycle — an ISV offering, or a shared platform component that a different team owns and versions independently. Everything else is one publisher. The cost of getting this wrong isn't cosmetic: cross-publisher component ownership can't be moved, so a second publisher created casually in month two permanently constrains how you can reorganise solutions in year two.

Configuration decisions

The prefix itself. Short, lowercase, recognisable, and something the client will still be happy with after a rebrand — which argues for the product or programme name rather than the company name.
Whether the client needs more than one publisher, which they almost certainly don't.
The preferred solution for each maker, so components created outside a solution context don't scatter into the default solution.
Whether ISV-supplied publishers are left alone, which they should be — never create your components under someone else's publisher.
Where the publisher is created and how it gets into every environment, because the same publisher has to exist consistently across dev, test and production.

Gotchas

Changing the prefix later does nothing to what already exists. You end up with cr8a3_ columns sitting next to contoso_ columns forever, which is ugly and, more practically, makes every FetchXML and every integration harder to read.
The random default prefix is the tell that someone built directly in the default solution. If you see cr followed by digits in a client's schema, ALM was retrofitted.
Choice value prefixes matter more than people expect. Options added under different publishers get different numeric ranges, and integrations that hardcode option values break when the same logical option has different values in two environments.
Creating a component in the wrong solution binds its ownership to that publisher immediately. In an unmanaged environment you can still fix it; once it ships managed, you can't.
A publisher created independently in each environment isn't the same publisher. Import it as part of a solution instead.

Consultant notes

Do the publisher and prefix in the first hour of the first environment, before anyone builds anything. It's five minutes of work and it's genuinely unfixable later.
Argue the prefix out with the client rather than picking one yourself. They'll live with it for a decade and they'll notice if it's the name of a company that got acquired.
When you inherit an environment with a default-publisher prefix, don't try to rename anything. Standardise going forward, document the split, and stop.
Watch for makers creating components outside solutions. Set preferred solutions and check periodically — the default solution filling up is the earliest visible symptom of ALM discipline slipping.

Revisit if component ownership ever becomes transferable across publishers, or if prefix renaming gains platform support.