Which CoE apps should not be run in/from the CoE environment?

[Anonymous]

For anyone who has setup and used the Center of Excellence Toolkit - what apps are include with CoE toolkit that should NOT be run from the environment that the CoE itself is running from? For example, if the Theme Gallery/Theme Editor builds themes that ultimately rely on Dataverse tables to run, shouldn't we move both the Theme Gallery and the Theme edit app out of CoE environment and into one that is shared or used by all of the Makers.  I don't want to have 1000 makers having access to the CoE environment just because they want to create a Theme, or use one and if I have to create a new environment to run them from, I would imagine that I would be a Sandbox environment with a full Dataverse database in it - probably there will be other apps in that environment which begs the question: are there other CoE apps that really should be installed somewhere else other then the CoE environment itself?  Which ones did you/would you move and install in another environment?

[joe_hannes_col]

Hello @Anonymous,

I would install all CoE apps in one environment, because:

• You will need less resources
• You have less administrative overhead
• You can use the supplied security roles to restrict users' privileges and access to data in the CoE environment

However, if your need to segment CoE data by using different environments is paramount, e.g. because of compliance restraints, you could install any CoE components without a dependency on the core components (ALM Accelerator, Power Platform Administration Planning, Theming, Creator Kit) in another environment.

[Anonymous]

So here is my example: imagine a company that has 100,000 citizens who develop Power Apps.  They WANT, no they DEMAND a THEMING application where they can Get the corporate THEME from the app and apply it to their app projects going forward.  Since the design of the THEME EDITOR and THEME GALLERY requires access to Dataverse tables, AND even the template's that are built from it, AND the final end-user product requires access those same tables, giving 100,000 people access to the Theme editor/gallery, thge template apps, and the end user final finished product should not take place in the CoE environment for many reasons.  If I do that I'll have DEV and Production versions of apps in my CoE environment, plus all of the other stuff and byproducts they generate. The Theme Apps and templates are documented that they "could" or "should" be kept im a ifferent enviro0nment other then the CoE for the reason mentioned above, so I was looking for OTHER PARTS supplied with the CoE that fall into that same category where they could or should be moved into an environment that is NOT the CoE environment.

[joe_hannes_col]

Hello @Anonymous,

If you have 100,000 premium licenses for the Power Platform, adding an additional environment is probably not going to bust your Dataverse resource capacity, so if you feel better about storing non-core CoE components in another environment, why not?

Still, your 100,000 makers will probably still have to access your CoE environment, e.g. to access the Developer Compliance Center.

And I disagree regarding the Theming components: the final products will not need access or be located in the Dataverse used to host the Theming components. Instead, you use the Theming components to create an .msapp file that is used as the basis for creating a canvas app with your corporate identity. This file can be downloaded to a local computer and for example shared through a SharePoint Online hub site for the Power Platform.

[Anonymous]

When it comes to "running" a tool in the CoE environment as a Maker, I have no problem setting that up and letting the makers run the tool, but items like the Theme Designer/Gallery seem to be different because no matter how many times we have tried, and no matter how many videos we have watched on using it, we still cannot break the connection between the AppPhoneTemplate (or the AppTabletTemplate) even after it has been properly attached to the theme.  If I follow all directions and setup the 2 templates as the final step in creating/publishing a  theme and its 2 templates, I then find that any Maker who downloads it cannot use it because if they try to import the modified template .msapp file (for either the table or phone form factor) into their own environment, it won't open and instead tells you either the Cat_Fontloader is missing, or that the app expects Dataverse tables for Themes/Styles to be present in that users environment and they are not.  Even a few of the U-tube videos suggest that you always have a dependency on the component and the Dataverse tables.  That means it can only work if we let the Maker grab the template form the Theme (download it to themselves) and then the only place they can use it would be to add it right back into the CoE environment (with a new name of course since adding it back in already is a duplicate name).  Then they forever have to run any app they create from the CoE environment.  Unless you can tell me you we are doing something wrong and that the design of Theme Editor and Gallery allow you to run the final templates without the dependencies of the Cat_Fontloader and the 2 Dataverse tables.   For that reason, it seems like it doesn't below in the CoE environment long term and should be in an environment separate from the other CoE tools.,,, Which is why I asked the question in the first place: if there are tools provided with the CoE that really don't require that they sit in the CoE environment, which ones are they and where are people moving those tools to?  Clearly the CoE documentation for the Theme designer/gallery explains this saying that it has no other dependencies on anything else.  No matter where the Theme tools are located, using them is way more complicated then it should be.