How Do You Manage Publishers in Your Power Platform Setup?

(0) Share

Report

Posted on by Jitendra_jangid

128

Hi Everyone,

I’m looking for some insights and best practices around managing Publishers in Power Platform environments. Specifically, how is your organization handling this?
Here are some scenarios I’m considering:

Should we use a single Publisher across all solutions developed in the organization?
- If so, how do you avoid dependency or conflict issues when multiple teams or developers are contributing?
Or is it better to create a separate Publisher for each solution to keep things isolated and avoid conflicts?

Also, in scenarios with multiple developer environments, would it make sense to:

Create a base solution just to define the Publisher?
Deploy that base Publisher solution to each new environment?
Ensure it's included or referenced whenever a new developer environment is set up?

Is this a common practice, or are there better ways to handle this?

Thanks,

Jitendra

Categories:

Governance & administering

I have the same question (0)

All responses (3)

Answers (1)

Verified answer

Michael E. Gernaey 53,969 Moderator on at

Like (1)

Report
Copy link

Link copied!
Hi @Jitendra_jangid

Welcome, one thing we ask, please do not post in multiple places. Your question will get seen and it just spreads the other thin list of responders.

So as it relates to your questions.

Publishes are not specifically a way to categorize your apps, although they can set thought of that way. But let me give some direct incite into each thing you asked below.

I’m looking for some insights and best practices around managing Publishers in Power Platform environments. Specifically, how is your organization handling this?
Here are some scenarios I’m considering:

Should we use a single Publisher across all solutions developed in the organization?

This is completely up to you. You can be it on product lines if you want etc.

Many companies (including Microsoft) do them across product lines and even sub-lines

There is no specific "best practice" as long as it fits your needs and if you plan to publish on AppSource, which supports a single company having multiple Publisher Profiles, doesn't go against their rules

If so, how do you avoid dependency or conflict issues when multiple teams or developers are contributing?

I am not sure I understand. And let me be clear what I mean. When a company is building apps, they should have standards in place already not to name everything from app to app the same thing. that being said, your Publisher isn't going to cause or stop you from having conflicts. If you want to use one publisher that is totally fine.

Think about it like this, you wouldn't call two different apps the same thing would you? No, so when you have your naming conventions etc, just have specific guidance to people as it relates to a Flow (which would look silly having 10 named the same thing, although its allowed in the same solution, under the same publisher)

Or is it better to create a separate Publisher for each solution to keep things isolated and avoid conflicts?

Again, that's not what publishers are for, not really. Its more of a logical separation of product intent, then it is a way to stop solution 1 from having issues with solution 2

Also, in scenarios with multiple developer environments, would it make sense to:

Create a base solution just to define the Publisher?

Let's reverse that. Don't think of solutions to define Publishers ever. If you want to have a base solution which is awesome, then you should define within your Company, how do you define "base" across your portfolio regardless off if its SQL, or Azure, or a VM definition etc. Then use that same convention for your "base" Publisher, which holds all your "base" solutions, which could be more than 1. You might have a base 1 for flows, 1 for Tables, 1 for CoPilot.. I am not telling you to do that, but you could

Deploy that base Publisher solution to each new environment?

You would need to do this, and again forget Publisher, if you want Solutions to take dependencies on things that exist IN an environment, and that belongs to ANY solution regardless of publisher, you have to publish the parent solution first. So again publisher has nothing to do with this. But if you do create a Base "Publisher" with a base solution, then it would need to be in those environments first yes.

Ensure it's included or referenced whenever a new developer environment is set up?

Yeap soon as you build out your dev environments, you should or could have a Pipeline auto deploy whatever "base" solutions, regardless of their publishers to it.

Is this a common practice, or are there better ways to handle this?

Apologies I don't know to what question you are asking is common practice as you asked some great questions :-) so my answer is, I can only speak to well loads of big companies and customers.

It's not required to use a separate publisher, period

It is good to use Publishers to separate business units (I don't mean CRM BU's don't confuse)

It is good to use Publishers to separate different teams (image you are a huge company and you have 4 separate "orgs" that roll up into a primary VP, you don't want each to have the same Publisher

It is good to use a base Publisher for base solutions IF and again, IF you have a major set of product LINES and the base solution covers them all. That or you need separate Base solutions for each product line or subline

Hope that helps :-)

Was this reply helpful? Yes No
WillPage 2,323 Super User 2026 Season 1 on at

Like (1)

Report
Copy link

Link copied!

If you have any custom code components, whether you develop them in-house or you're using the Power CAT library or whatever, you need the publisher of the code components you use in the app to be the same as the publisher of the app (and all the other things) in a solution before you can deploy it to a managed environment.

So if you want minimal hassles sharing your custom code components around your organisation you should keep the number of publishers to a minimum. If someone published a bunch of components under publisher xyz_ and then a person using publisher abc_ adds one of these components to their app it'll work fine and everything will be great until they try to deploy to a managed environment. At that point they'd have to republish the custom components from source to publisher abc_, then delete the originals from the app and re-add the new ones and set them all up again. This could be a significant hassle so be aware before creating separate publishers all over the place.

Was this reply helpful? Yes No
Jitendra_jangid 128 on at

Like (0)

Report
Copy link

Link copied!

Hi Michael E. Gernaey

Apologies for the repeated posts of the same question. When I initially submitted it, I wasn't certain it had gone through, as it didn't appear in my activity for some reason - so I reposted it.

Thank you so much for taking the time to provide such detailed, point-by-point responses. This is exactly what I was looking for, I really appreciate your help.

Thanks for your response WillPage.

Was this reply helpful? Yes No