Answered

Power Apps for Teams - Connection not configured for this service

(1) Share

Report

Posted on by FelixR

Hey Community,

I have seen all the posts about this errormessage but none of them is quite like my issue because I am using Power Apps for teams.

My setup is the following:
I have a canvas app in Power Apps for teams that triggers a flow on the click of a button. The Flow is of course part of the solution that was published to the teams environment. There are no Co-Owners assigend to the flow, only me as the owner.

The flow works perfectly fine for all Members and Owners of the Team that the app is published in.

BUT:
A large portion of users will access the app as people who the app has been shared with. We have a security group set up for this type of access and the App has been shared with this security group. People accessing the app in that way report that they get the errormessage Connection not configured for this service when they click on the button that triggers the flow.

We discovered that this issue can be fixed by adding people temporarily to the Team that the app has been published in. Even after removing them from the team again, they can still trigger the flow without any issues. To me this is an indication, that the general setup should work but there might be an issue with synchronization of the allowed flow users.

The workaround of adding and removing people will not be a viable solution going forward, because we have a very large number of potential app users. We need some way of giving them access to the flow without automatically.

EDIT: It takes a while after somebody is removed from the team until their permissions are revoked. When we chaed the ability to trigger folws th enext day, the user could not trigger them anymore. So the workaround described above is not actually working.

Note: We cannot give the users Co-Ownership for the flow, because we do not want them to be able to edit the code. The option of run-only users is not available, because it is not an instant flow that is triggered manually, but rather triggered through Power apps.

Any ideas on how to solve this issue are appreciated

Kind regards!

Categories:

Building Power Apps

I have the same question (0)

All responses (11)

Answers (1)

Sort by

FelixR 19 on at

Like
a
(0)

Report
Copy link

Link copied!

We have investigated the issue a little bit further and I can now give you instructions on how to recreate the Issue.

1. Create an App in Power Apps for Teams.
2. Add a flow to the App that is triggered by Clicking a button. (In our Example we created a flow that sends an outlook mail.
3. In the Teams Environment, create a new Solution and add the App, the Flow and the connection References used by the flow to that solution.
4. Export the Solution as a Managed solution.
5. Deploy the solution to a new team
6. Share the app from the solution with a security-enabled group via teams.

-> Users that are part of the security group that the app has been shared with but not member or owner of the Team will not be able to trigger the flow in the app. Instead, they will get the error 'Connection Not Configured for this service'.

It is important to note that the app is in a managed solution. If we keep it in the unmanaged solution the setup works without error.
This leads us to believe, that there is still the chance that we are doing something wrong when exporting. Please let me know in case you have any ideas. Could it be the connection references? How do I fix these.

If somebody else manages to recreate the issue as well, I would be happy to hear that to, so that we can report it to microsoft as a bug, that needs immediate fixing!

Kind regards!

Was this reply helpful? Yes No
Verified answer

FelixRech 74 on at

Like
a
(3)

Report
Copy link

Link copied!

<span;>After extensive testing and several not too insightful calls with the microsoft support team, we believe to have found the source and a workaround to the problem described above.

<span;>These are the relevant cornerstones of our scenario:
<span;>- Power App developed in Power Apps for teams
<span;>- Power Flows are triggered directly from the app
<span;>- App and flows are put into a solution and exported into a new environment (it does not matter if solution is managed or unmanaged)

<span;>This is the source of the problem:
<span;>When a flow is triggered through the app, the app tries to find that flow based on the flow GUID. The GUID of the flow changes when it is exported into a new environment. But the flow reference in the app does not change during the export. Basically, the app in the production environment is trying to execute flows in the DEV environment. Since the users are not part of the DEV environment, they cannot execute the flow and get the errormessage "conmection not configured."
<span;>This behaviour is consodered a bug by Microsoft and they confirmed that there is already a feature request to solve it.

<span;>In the mean time, to proceed with our project, we have implemented the following workaround. We edited the App in the production environment and reconnected the flows and renweing the reference, this time to the correct instance of the flow.
<span;>Our app is published as a Managed solution and by editing it in production, an unmanged Layer is created. Everytime we want to deploy a new version from dev, we have to remove the unmanaged layer, deploy and apply the changes to the flow connections again.

<span;>Hope this helps.

Was this reply helpful? Yes No
Community Power Pla... Microsoft Employee on at

Like
a
(0)

Report
Copy link

Link copied!
Hi,

The problem exists in a similar manner when using PowerApps without 'Teams'.
Build app in dev environment as part of solution
connect various flows to app
deploy solution as managed to prod environment
add users as 'Basic users' to prod environment
ensure 'Basic User' role has 'Organisation' privelages to 'Process'
when users run the prod app in browser, all works well.
however, using the PowerApps client throws the error

Was this reply helpful? Yes No
SCTdan 604 on at

Like
a
(1)

Report
Copy link

Link copied!

I've had to give Basic User role Organization privileges for Solution as well as Process, have you tried that?

Was this reply helpful? Yes No
FelixRech 74 on at

Like
a
(1)

Report
Copy link

Link copied!

Thanks for follwoing up on the topic. Unfortunately, you are not able to manage permissons and roles in that level of detail in Teams environments.

Was this reply helpful? Yes No
SCTdan 604 on at

Like
a
(1)

Report
Copy link

Link copied!

Ah ok, didn't notice that you built it in PowerApps for Teams, not in a normal solution. Can't say I've ever done that before.
In your flows, under Run-only users, do you have your connections set to use a defined one? If they're set to 'Provided by run-only user', that can cause the issue. And I have seen that get reset when going from dev -> prod, so double check after import.

Was this reply helpful? Yes No
Community Power Pla... Microsoft Employee on at

Like
a
(1)

Report
Copy link

Link copied!

@SCTdan wrote:
I've had to give Basic User role Organization privileges for Solution as well as Process, have you tried that?

I have considered it, but what does that allow users to do? Will that mean the basic user is able to mess around with production solutions? I have trawledd the www for documentation on what the various privelages do but have not found any.

Was this reply helpful? Yes No
SCTdan 604 on at

Like
a
(1)

Report
Copy link

Link copied!

Yea that I am not 100% sure on. Luckily in the couple small organizations I've had to do that for, there are no users who are that curious (or capable), but that's hardly best practice.

Was this reply helpful? Yes No
HXZ 18 on at

Like
a
(0)

Report
Copy link

Link copied!

We are experiencing the same situation in 2023 (but in a regular environment) and are implementing the exact same workaround. Are there any new insights in your org on a better way of managing this situation?

Was this reply helpful? Yes No
FelixR 19 on at

Like
a
(1)

Report
Copy link

Link copied!

No news on this from me, I am afraid. We have moved on to an entirely different solution with Appian in the mean time.

Was this reply helpful? Yes No