I get asked this question every now and again…
“What does it matter if we have our own publisher?”
It’s just an extension, it just looks nice… right? Right?
The formal answers from Microsoft on Publishers are available here (which is quite informative, and a great read). At its core, Publishers help distinguish your solution from other solutions in PowerApps/Dynamics.
A quick search of all publishers in a relatively new environment yielded these results (the ones highlighted are mine).
Code Abstraction
That’s a heavy number of Publishers in use by a variety of solutions. At its core, your Publisher is the best tool you have to differentiate all of your work (tables, resources, steps, flows, etc, etc) from anyone else. It’s the best, cheapest, and cleanest way to say “This is my sandbox, I live here, and everything in here I know, live and breathe”. In addition, you can set where your choice prefixes begin in case you want to keep a separate running count going.
At the very minimal use of the Publisher, your code will now look like your code, it will now be your code and everyone will know where it came from. Any guesswork from using “new_” goes out the window because now you no longer need to worry or think about “who put this there, who did this, where did this come from.”
When tied to a solution, no one even needs to think about this, because everything they do is tied to that publisher and it just happens behind the scenes.
Future Deployments
We’ve all had that experience where you are building a tool in a solution and you realize you don’t want anyone messing with it – so you bundle it into a Managed solution for people to install it on their own. If you’ve already created your own publisher, and have been using it all along, you’re now good to go because when the deployment happens, it is going to ship your publisher into that environment, identifying it as your application. If you had started with something like “new_” or “c4b1356_” – you’d be carrying around that deadweight forever and ever.
Standardization and Naming
You work hard, you do great work, and the last thing you want someone to see is that you are using the default, out-of-the-box Publisher. It’s akin to starting a new project in Visual Studio, packing all this great code into it, only for it to still be called Class1? What you’ve written is so much better than anything to be called Class1. Having a publisher sets the tone and the standard for everything that will come next in your application and the professionalism which you bring to it.
Start this way from the beginning.
I honestly can’t remember how long Publishers have been around, I want to say MSCRM4, but I’m not sure. All that to say there are some areas that I would love to see them expanded into;
- Case Naming – All Upper Case, Camel Case, Hungarian, all Lower Case – pick one and go with it – would love to see this as a drop-down.
- Associate to an Azure App User – would love to see publishers tied to app users that could then complete the lifecycle on App Deployments instead of PowerApps teams having to manage this on their own.
- Listing of Integrations – Whether it’s Azure Apps, Data Lakes or Azure Functions – knowing what is related to a Publisher would tie in everything to what your solution is doing.
- Default Configurations – I’ve worked on some projects where we share the publisher between different solutions (because it’s all the same environment, but we have broken the solution into different deployment models for efficiency purposes). Having a default configuration that gets shared across and then consumed by solutions would be a great way to manage this information all in one place.
It’s not AI, it’s not Mobile, it’s not super fancy and exciting, but yes, Solution Publishers have value – give them the 5 minutes they need so you are not trying to modify and change XML configuration files on the fly because you now decided things don’t look good.