Publisher prefix in Power Platform: the decision you can't undo

A publisher prefix is three to six characters that Dataverse glues onto every custom component you create - table names, column names, choices, relationships, plugin actions, the lot. The default is new_, which is Dataverse's way of telling you "you forgot to pick a prefix." Every new_customer column you see in a live system is the fossil record of that oversight.

Changing the prefix after components exist is not a setting toggle. It is a component-by-component clone-and-migrate, followed by code and flow updates, followed by data migration from the old components to the new. We have done this twice. We try very hard to not do it again.

Here is the prefix decision framework we use on day zero of every Power Platform project.

Why the prefix matters after the system is live

The prefix is in:

• The schema name of every custom table and column (acme_customer, acme_loyalty_tier)
• The Web API endpoint path (/api/data/v9.2/acme_customers)
• The unique name of every plugin step, custom API, and action
• The filename inside exported managed solution zips
• Relationship navigation properties (acme_account_acme_order)
• Audit logs, report columns, view XML, FetchXML query strings

It shows up wherever a developer, integration, or power user has written code against the system. The prefix is effectively a namespace, and changing a namespace touches every consumer of that namespace.

Our selection rules

Rule 1: Client-specific, three to six characters.

Four is our sweet spot. Three is tight but workable (acm_ for Acme Corp). Five or six gives room if the client's name has no obvious short form (tribe_, summit).

Avoid anything that could collide with common prefixes: sys_, adm_, app_, org_, crm_, ms_ are all out. Avoid anything that could be mistaken for a Microsoft-owned prefix: msdyn_, mspp_, msft_.

Rule 2: Match the client's actual brand, not an agency nickname.

If the project folder on our server is "Kangaroo Logistics" but the company's legal name is "Roo Transport Holdings," ask the client what they want. They will live with the prefix longer than we will. Default toward their actual brand word.

Rule 3: Avoid ambiguity with their existing tooling.

Some clients have an existing Dynamics 365 or Power Platform deployment with a prefix already in use. If they have roo_ components from a previous consultant, decide explicitly: are we extending their existing solution (reuse roo_), or building parallel (root_, roo2_, or a new brand prefix)? Both are valid, the mistake is being accidental.

Rule 4: Document the decision in a commit in the repo.

A single line in the project README: "Publisher prefix: acme_, chosen 2026-01-15 with client approval." When a new developer joins six months later, they do not need to guess.

Agency pattern: multi-client from one codebase

We sometimes maintain a shared accelerator solution (common plugin utilities, base table patterns) that gets imported into each client's environment. The prefix question for the accelerator is: use our agency prefix (sapota_) or the client's.

Our pattern: the accelerator uses our agency prefix and ships as a managed dependency solution. Each client project's main solution uses the client's own prefix and depends on the accelerator solution. This keeps the accelerator components clearly marked as external (not something the client should modify), and lets us update the accelerator independently of client-specific work.

The alternative - forcing every new client's components into the agency prefix - fails the first time the client wants to take over maintenance. It is their system; the namespace should be theirs.

The migration cost if you get it wrong

When we have migrated prefixes on live systems, the work breaks into:

1. Component inventory. List every table, column, relationship, choice, plugin step, and custom API on the current prefix. A mid-sized project has 50-200 components.
2. New-prefix clones. For each component, create a copy with the new prefix. Columns and choices are straightforward; tables require manually recreating the schema since you cannot rename them.
3. Data migration. Copy row data from old tables to new tables. Maintain GUID stability if any integration depends on specific GUIDs (trickier - use overriddencreatedon and importsequencenumber patterns).
4. Code and flow updates. Every plugin, flow, canvas app, model-driven form, and integration that references old-prefix components has to be updated. Grep across the codebase for the old prefix; search flow JSON for the string; check canvas formula references.
5. Cutover. Switch production traffic to the new tables. Keep old tables read-only for a grace period.

A mid-sized single-solution system is two to three weeks of dedicated engineering work. A multi-solution system with heavy integrations is a quarter.

The two exceptions we make

Exception 1: internal throwaway projects.

If we are building a seven-day internal tool for one team that will not outlive the problem it solves, we skip the careful prefix dance and use a short generic prefix. Nobody will inherit this.

Exception 2: migrations from new_.

If we inherit a system that uses new_ (the default), we do plan a prefix migration as part of the cleanup - usually in the first month, before the inherited system grows further. Keeping new_ means every future component also has to live under new_, perpetuating the decision.

The ten-minute conversation

On day one of a new project, we have a ten-minute conversation with the client technical contact:

• "What prefix do you want us to use? Three to six characters, something recognizable as yours."
• "Do you have any existing Power Platform or Dynamics components? What prefix are they on?"
• "Is this greenfield or extending an existing deployment?"

Ten minutes spent here saves weeks of migration work later. It is the highest-ROI conversation in the project.

If you are staring at a live Dataverse system with new_ components and you are trying to decide whether the migration cost is worth it, the honest answer depends on how long you expect the system to live. A system you expect to retire within a year? Leave it. A system that is the foundation of a client's next five years? The migration is almost always worth doing before it grows further.