Changing Publisher Prefix

[sdedic]

Hi,

I can't find any relevant source stating that changing prefix of the publisher is advisable or what are the best practices when working with publishers. Does anyone know if changing the prefix of a custom publisher for a new solution can trigger any issues in already created solutions?

So, let's say I have a solution "Solution 1" and the publisher for that solution is "My Publisher" with the prefix "prefix1". Now, when I want to create new solution "Solution 2", I want to choose the same publisher "My Publisher" but this time change the prefix to "prefix2". Will that create any unwanted results in Solution 1?

Hope question makes sense.

Best

[ShaheerAhmad]

Changing the publisher prefix in Microsoft Dynamics 365/Power Platform can have implications for existing solutions that are associated with the original publisher prefix. It's important to understand the potential impacts before making any changes.

Changing the publisher prefix can affect the following aspects:

1. Entity Logical Names: Entity logical names in the existing solutions are generated based on the combination of the publisher prefix and the entity schema name. Changing the prefix can break references to entities in existing solutions, causing issues with data integrations, workflows, and custom code.

2. Web Resources and Customizations: Web resources (such as JavaScript, HTML, CSS) and customizations (such as forms, views, charts) that reference the original publisher prefix may need to be updated manually to reflect the new prefix. Failure to update these references can result in errors or broken functionality.

3. Solution Dependencies: Solutions developed using the original publisher prefix may have dependencies on other solutions or components that rely on the prefix. Changing the prefix could lead to dependency errors or inconsistencies in solution deployments.

To mitigate potential issues, it is generally recommended to carefully plan and assess the impact of changing the publisher prefix. Here are some best practices to consider:

1. Test in a Sandbox Environment: Before making any changes in a production environment, thoroughly test the impact of changing the publisher prefix in a separate sandbox environment. This allows you to identify and resolve any issues before affecting live solutions.

2. Update Existing Solutions: If you decide to change the publisher prefix, it's essential to update all existing solutions that are associated with the original prefix. This involves updating entity logical names, web resources, and customizations to reflect the new prefix.

3. Communicate with Stakeholders: Inform users, developers, and administrators about the planned changes to the publisher prefix and the potential impact on existing solutions. This helps ensure everyone is aware of the changes and can coordinate their activities accordingly.

4. Develop a Migration Plan: Create a well-defined migration plan that outlines the steps for updating the publisher prefix in all affected solutions. This plan should include comprehensive testing, a rollback strategy, and clear communication channels.

It is highly recommended to consult with your Dynamics 365/Power Platform administrator or a Microsoft support team to assess your specific scenario and obtain guidance tailored to your organization's needs.

[sdedic]

Hi @ShaheerAhmad,

thank you for your answer. So, does this mean if I have different clients and I want to prefix objects inside solutions with client's name, I will have to create Publisher for every solution/client?

I know I can always use some random name for prefix, but that's something I am trying to circumvent and have everything more client-specific.

Best

[ShaheerAhmad]

Yes, if you want to prefix objects inside solutions with a client's name, it is recommended to create a separate publisher for each client. This allows you to maintain a client-specific naming convention and avoid conflicts between different clients.

By creating a publisher for each client, you can assign a unique prefix to their solutions, ensuring that entity logical names, web resources, and customizations are specific to that client. This approach helps organize and differentiate solutions for each client, making it easier to manage and maintain the system.

While it may involve creating multiple publishers, this approach provides a clean separation between clients and reduces the chances of conflicts or naming collisions. It also allows for more granular control and customization based on the specific requirements of each client.

Remember to carefully plan and consider the implications of creating multiple publishers. You may need to adjust your deployment processes and update your migration plans to accommodate the use of multiple publishers. It's always a good practice to consult with your Dynamics 365/Power Platform administrator or a Microsoft support team to ensure you follow the best approach for your specific scenario.

Mark as Solution if this helps. And Kindly give a Thumbs Up. Thanks

[sdedic]

According to the following links, changing prefix and display name is ok if you do that before you start building the solution:
Solution concepts - Power Platform | Microsoft Learn
Create a solution in Power Apps - Power Apps | Microsoft Learn

"When you change a solution publisher prefix, you should do it before you create any new apps or metadata items because you can't change the names of metadata items after they're created."

I think I got the answer!

Best

[LIB_SA]

Hello - I've a question I hope someone on this thread can answer. I have two different publishers in PROD for solutions - cla and kky. I have an environment variable of an email when flows fails. It has a prefix of kky. Will this variable be recognized in my managed solutions that were created with cla?

[sdedic]

Hi @LIB_SA,

What do you mean by "Will this variable be recognized in my managed solutions that were created with cla"? As far as I know that environment variable should already be inside the solution before you are importing it to the prod as managed solution, otherwise I am not sure how something that doesn't exist inside the solution could be recognized.

Could you please provide more details and explain a bit more your situation?

Best

[LIB_SA]

Thank you for replying @sdedic - basically in PROD I had managed solutions and later wanted to add a variable for a hardcoded email when the flows triggered within the app failed. This variable would be the same regardless of the publisher of the solution. I edited all the flows with this variable but when I attempted to import a solution with the variable inside it, it caused an error and wouldn't import the variable. (In the Microsoft documentation, I read a note that the ordering of when you import solutions calling a variable come into play so I suspect there was an issue going on with that?) I found a workaround on another post where someone recommended creating an Unmanaged solution of variables and publishing it as Unmanaged to PROD. I tested doing this and then triggered flows in PROD that had different publishers using the variable and it worked. So that's what I'm using for now but am open to better solutions if there are any. Thank you again.