Issue triage (CoE Starter Kit)
Please check out our documentation:
Below are some frequent questions that are raised on GitHub, and the guidance provided should help you resolve those issues:
Please validate that the Azure Key Vault access control is correct using IAM. User needs to be in Key Vault Secret User role explicitly to read, and in the Key Vault Contributor Role to update.
Change the keyvault to rbac access from access policy:
If you have a large number of connection identities, this flow can fail due to content throughput limitations in cloud flows:
The CoE kit is built on top of the product, and as such bound to platform limitations. This failure is due to a limitation on the amount of data connectors can bring back, which unfortunately, you have exceeded. Note also that deleting individual flows and apps will not delete the connections they use, so they do pile up over time and deleting objects does not
We cannot fix that, nor can we safely create a script which will reliably connections safely for all tenants that will work over time.
Here are some things you can do to address:
- Manually use powershell to explore and delete unused or errored connections. That technology does not have this same size limitation.
- Contact product support to have them help you clean up old connections
If the import of the Core components solution failed with an error like below, it means you have not installed in the Creator Kit solution in the environment.
If the import of the Governance components solution fails with an issue like the below, it means you have not initiated Flow Approvals in the environment
If the import of the Core components solution fails due to a dependency on the Office 365 Management API connector, please follow these steps: https://github.com/microsoft/coe-starter-kit/issues/6018
If you can't turn on the flows in the CoE kit with the following error
Flow client error returned with status code "BadRequest" and details "{"error":{"code":"InvalidOpenApiFlow","message":"Flow save failed with code 'InvalidPaginationPolicy' and message 'The pagination policy of workflow run action 'List_Ai_Models' of type 'OpenApiConnection' at line '1' and column '3422' is not valid. The value specified for property 'minimumItemsCount' exceeds the maximum allowed. Actual: '100000'. Maximum: '5000'.'."}}".
This error indicates that you are using an insufficient or trial license. Note that we do not support trial licenses for the toolkit due to them having this lower pagination support.
See here for the license types: Performance profiles And here for pagination limits: Paginated items
And hence our requirements for licenses as described in our prerequisites.
Many of the flows in the CoE kit call child flows. The parent flow can only be activated (turned on) if all child flows are turned on. If you see an error message stating ChildFlowNeverPublished this means a child flow this flow depends on is not turned on. To find the child flow, look at the solution dependencies of the parent flow you're trying to turn on
Under required object, look for object type Process and note the display name
Go back to the solution and check that the flows you noted are on:
This means you missed to set an environment variable. You can set the environment variable by opening the CoE Admin Command Center and navigating to the Environment variables screen and updating from there
Usually an issue like this - either flow run fails or flow can't be turned on. This can happen when there's different people using the kit, e.g. one imported it, the other one turns on the flows and connection references get mixed up.
Can you please try going to the Default Solution > Connection references > Filter to the connector that's failing > click on it > make sure they have the user there that you're trying to turn on the flow with
Can't open setup wizard: It looks like this app isn't compliant with the latest data loss prevention policies.
We've added the PowerQuery connector with the latest release, so you'll have to update your DLP policy to include that. Note, you can always find our latest required DLP requirements in our documentation: https://learn.microsoft.com/en-us/power-platform/guidance/coe/setup#validate-data-loss-prevention-dlp-policies
Here's some other tips:
- Try activating/deactivating the model-driven app to clear the cache and resolve the DLP conflict
- Try opening the app via maker.powerautomate.com instead of make.powerapps.com
The method of collecting audit log events via a custom connector did not implement pagination, and this mail is intended to let you know that you need to continue making these chunks smaller to hopefully be able to cover your tenant usage.
We have recently launched a new way of collecting audit log events via an HTTP call which does implement pagination - if you do receive an email about your audit log events being truncated using the custom connector method, we recommend you switch to collecting audit log events via HTTP calls.
Alternative, we are now also in preview with using the Data Export feature of the product instead of the office audit logs. You can explore this product feature here: Set up Microsoft Power Platform self-service analytics to export Power Platform inventory and usage data (preview)
And read about the CoE Starter Kits integration with it here: What data source should I use for my Power Platform inventory?
Make sure you've changed the App Registration permission from Delegated to Application. Verify that:
If you're upgrading to a more recent version of the CoE Starter Kit, you may notice some apps have been marked as [deprecated]
We deprecated some canvas apps and replaced them with model driven apps that use custom pages, as that allowed us to use Creator Kit components for a Fluent UI look and feel and made collaboration on development easier for us. Unfortunately the change from canvas to model-driven apps isn't as seamless as just replacing the app, so here's some actions for you:
Here's what you need to do: If you are currently using one of the apps that's been marked as deprecated, unshare the deprecated version and re-share the new app with your colleagues.
Here's what we will do: The deprecated apps were left in the solution so that customers who are using them have time to unshare them and re-share the new version, get familiar with the new version or take a copy of the old version if they want to stick with it. There's no need for you to delete the app, we will delete it from the solution in about 3 months but we needed to give customers some time to migrate to the new apps - hence why we didn't just delete them.
Why are some flows still using the Dataverse (legacy) connector when it's been marked for deprecation?
The inventory of certain Power Platform resources is stored in Dataverse tables of the environments they're created from - desktop flows are stored in the Processes table, Chatbots are stored in the Bots table etc etc etc. We use the Dataverse (legacy) connector to loop through all environments in your tenant to get the inventory for those resources.
The modern/latest Dataverse connector has a few limitations - primarily that you can't connect to environments other than the current environment. https://learn.microsoft.com/en-us/power-platform/important-changes-coming#microsoft-dataverse-legacy-connector-for-power-automate-flows-will-be-deprecated-and-replaced-with-another-connector
Due to this limitation we are not yet able to shift to the modern/latest connector yet, but we will once that limitation is resolved in the connector. This is part of the Power Automate teams release plan here: https://learn.microsoft.com/en-us/power-platform/release-plan/2023wave1/power-automate/connect-other-environments-dataverse-connector and our work item is tracked under https://github.com/microsoft/coe-starter-kit/issues/2607
If you're wondering why we are not using an HTTP call to the Dataverse API instead:
- We can't use the HTTP with Azure AD connector with the Dataverse API endpoint as that only supports static base URLs and not dynamic ones - e.g. that means we wouldn't be able to dynamically connect to all environments in the tenant.
- We can't use the HTTP connector as most customers would not approve the use of basic authentication here, and for any other authentication methods admins would first have to create an Application User in all environments they have before we can query them, which is not feasible for customers with large and growing numbers of environments.
A Power Automate license has always been required to run the CoE kit.
The CoE kit contains flows that run in context of Power Apps (for which a Power Apps license is sufficient), but most of the flows run standalone outside of the context of Power Apps thus a standalone license is required. Some of this may not be enforced in the product, e.g. you will be able to turn on a standalone flow if you only have a Power Apps license but it doesn't follow our license guidance, see here the Power Apps use rights only include execution of cloud flows within the app context
Before the setup wizard, you likely just turned on the flows with your Power Apps license as the above guidance is not enforced today.
If an upgrade from a version over 3 months ago failed: I'm afraid we cannot assist with upgrade problems of this age / complexity as there are just too many specifics and unknowns of how you got into this state. We recommend upgrading at least every 3 months, see installing updates. That is how far back we test as well.
If all you are using us for is inventory, then we recommend you start from a clean environment.
If you are using us for more than that, you may need to hire a partner to manually clean up the state of the environment. You can find some via you can find them via AppSource
Some people have cleaned themselves from this state by manually cleaning out errored references listed for example, if they are familiar enough with Power Platform.
Others have overcome it with a classic overwrite upgrade.