Multiple instances of a solution in one environment by updating variables and names

[Manuel_P]

Hi,

I have built a complex Power Platform solution with several flows, multiple apps, environment variables and components.

This solution is connected to a SharePoint Site Collection, several lists etc. via environment variables and runs with a lot of settings and configuration for this site collection.

Now we are working with managed environments one for each stage (dev, test and prod) and automating the deployment and variable updates with DevOps. 

There is the situation that this Power Platform solution is really great and several departments want to use it. As they are different departments they need to have their own SharePoint Site Collection to manage all apps and data with their own settings, permissions etc..

I know that out of the box it is not possible to have multiple instances of one solution in one environments. The out of the box solution would be to create a new environment for each instance of the solution and deploy it there.

But the governance of our tenant will not allow this and has expressed the requirement that there shall only be one single managed environment for all instances of this solution. 

My question is: Is there any way to achieve this?

I have an idea of how this perhaps could be accomplished but before putting so much effort in it I would like to ask the community if there is a better way to achieve this or perhaps some tool or script available.

So, here goes:

- Export the solution.

- Extract the zip

- Extract all app-Files

- walk through all json and xml file names and content and update the following elements with e.g. an individual prefix for each instance e.g. "solution01_":

- solution name and id

- environment variable names and ids

- workflow names and ids

- app names and ids

- connection names and ids

- component names and ids

- update all usages of the variables and connections in workflows and apps

- package all apps

- zip the solution

- import the solution

In my imagination I now have two instances - a real copy - of my solution.

And these copies now can be deployed using the automated deployment process from dev to test to prod each using individual configurations.

What do you think? Would this work?

Is there maybe a known script, DevOps action, CLI, tool or whatever already available to perform this task?

Or do I need to create this myself from scratch?

Looking forward to any kind of feedback.

Thanks and best regards

[cchannon]

While that may be technically feasible, I would not recommend it because you'll run into compounding complexities with oodles of environment variables and other components all with irritatingly similar names... 

Instead, I would suggest you review your solution to figure out which pieces really need to vary from dept to dept. From the sound of it, just these environment variables and just so they can be used by Flows. An alternative approach might be to create a table for these values instead. One column being the Dept name and other columns being the variable values you need to store. This would allow you to look up the correct variable value from this table, based on the current user's dept instead of having to deal with tons of environment variables.

[Manuel_P]

Hi, Thank you for your response. 

I do not quite understand your suggestion.

The variables are not really the issue here. The re-useability of connections and triggering workflows with several SiteCollections and lists is acually is the underlying isse.

We have managed to manually do a proof of concept to check if it is possible to open the solution, update all names and ids, repackage the solution and install the copy as a second solution in the same environment. 

It is a bit tricky to find all ids and references but in the end it worked.

Our next step is to create a tool for automating this process as we currently cannot think of a better way of ding this.

Maybe someone has a better - more sustainable - idea?

[GuidoPreite]

to me looks like you need to implement a business unit segmentation (did you look into this? found some issues?)

because duplicating the solution to be installed in the same environment is a really bad idea

[Manuel_P]

Hi, what do you mean by "business unit segmentation"? I do not know this approach. Do you have any more context and information about that?

[GuidoPreite]

I don't know how your solution is made (sure needs to check the sharepoint connection) but inside a Dataverse environment (I don't know if you built a model-driven app or a canvas app but if the data source is a Dataverse environment is the same thing) you have the concept of Business Units.

I write an example.

Let's say your custom solution has a table called "Request" and you have two departments: "Dep A" and "Dep B", you create two Business Units under the root Business Unit (so they are at the same level) and you put the users of "Dep A" inside the "BU Dep A" and the users of "Dep B" inside the "BU Dep B", if you setup the security role correctly (meaning they can access only their own data or the data of the BU they belong, "Dep A" users will be only able to access records belonging to them and the same for "Dep B".

Regarding sharepoint if you use the OOB integration you need to pay attention where the documents are stored, maybe you will need some extra logic to move the documents for the main location to a specific location (based on your app) but that should work.

[Manuel_P]

Okay, Thank you for your feedback. I think I have understood your suggestion, but for the concept and architecture of the whole solution this would not work. It is a canvas app with multiple workflows connected to several lists in SharePoint. I am not using Dataverse Tables for storing the data. Additionally each Site Collection where the data is stored has individual configurations for each "Business Unit" so they cannot share the Site Collection itself. Every Business Unit needs their own Site Collection with their own flavor of workflows, permissions and settings.