Connectors and Connections
Oliver Wirkus
Working with organizations to improve automation, collaboration and information management in Microsoft 365
In my earlier post on Power Platform Connectors, I already mentioned why connectors are a foundation of Power Platform strength. In this post, I want to dive a little bit deeper into how connectors can be used in an organizational environment.
What is a connection?
In terms of terminology, we need to distinguish between 'Connector' and 'Connection'. A 'Connector' is an artifact, that allows a flow or an app to exchange data with a service or an application. You might compare it to a 'driver' that is used by an operating system to exchange data, but that is how far similarities go. A connector requires credentials and other parameters to connect to that service or application, and that's what a connection is needed for. Technically, a connection is a set of parameters required by a connector to connect to a service or application. Depending on the connector, those parameters can be different.
How are connections handled in Power Platform?
As mentioned above, connections can include credentials required to connect to a service or application. If a developer creates an app (or a flow) that connects to a SharePoint Online list, the connector requires the credentials of the current user. Some connectors are able to retrieve credentials automatically (like the SharePoint Online connector) and some require the user to enter credentials (like the SMTP connector).
Because user credentials are used, connections are per se private to a specific user - unless shared, but connection sharing will be covered later. Here is an example of what that means: let's assume the user 'John Doe' uses a PowerApp application that sends email notifications via the SMTP connector. By default, John Doe is asked upon his first usage of the app (or flow) to provide the parameters required by the SMTP connector. Once he entered the parameters, a connection is created automatically, if the provided parameters are valid. Let's further assume, another user 'Fred Nerks' uses the same app as well. It will be the same for him and both users end up with their private connections used by the SMTP connector.
Where are connections stored?
If you want to check your connections, simply navigate to e.g. make.powerapps.com and log in. Once logged in, expand Data in the left navigation and click on Connections. You should see a list of connections if you have used apps or flows before. Also, keep in mind, that connections are environment-specific. This means, that a connection exists within a specific environment only.
Within the list of connections, you can check when the connection got modified last and it's status. More actions are revealed, if you expand the context menu of a specific connection. Here you can Edit, Share, Delete and view details. The details view can be very helpful because it lists all apps and flows that use that connection.
Edit connections
Each user can edit her/his connections by selecting a specific connection, expanding the context menu, and selecting Edit. However, there are some UI glitches that I hope Microsoft will fix soon. If you edit a specific connection and click on save, the connection gets verified again. Only if the verification succeeded (means: the connection can be established), the updated connection is saved. If the parameters of the connection include a password, you need to provide that password to be able to save the connection.If you don't, an error message is shown if you click on Save.
Some connections appear to be editable, but if you try to save updates, you get an error message regarding insufficient permissions. This indicates, that -although it looks editable- the connection can be edited by the current user. Most likely, that's because the connection is a shared connection (see below). This is not the best possible user experience and I wish Microsoft would provide an update to make it a consistent experience.
Sharing connections
Connections can be shared with other users. Before we have a closer look at use cases, let's look at sharing options (permissions) first. I think you agree that sharing a connection can be problematic, especially if the connection contains user credentials. Basically, a connection can be shared with these access permissions:
领英推荐
Sharing a connection works similar to any other sharing options in M365: select a user (or group), select the permission level, and click on Save. Unfortunately, there is no email (or notification) sent when a connection is shared. This means, that users can't know if a connection is shared with them. This is a UI glitch that Microsoft should improve ASAP. Another UI glitch is that you can open the Share dialog for all connections - even those that you are not allowed to share! For those connections, the elements within the Share dialog are greyed out, but not every user notices that when looking at the dialog. Here is my suggestion: if the Share dialog is opened for a non-shareable connection, add a banner notification at the top of that dialog.
Another potential UI glitch is this: an owner can share a connection, but also 'un-share' a connection. If an owner 'un-shares' a connection, that connection is immediately removed from the list of connections of all affected users, but again no notification is sent. This is likely to cause some confusion for users because an app (or flow) that worked yesterday now shows an error. From a user's perspective, 'un-share' works similar to deleting a connection, but that deletion was performed by somebody else.
Sharing use cases
What are use cases for connection sharing? Let me first state, that in general, I discourage or dissuade users from sharing a connection. Common or typical apps or flows rarely require shared connections. In addition, personalized connections are a security feature - means: as long as connections are personalized, users will only have access to data via apps or flows, that they can already access. It is similar to SharePoint Search: users only see search results of content, that they can access.
Still, there might be use cases that benefit from shared connections. An example is again the SMTP connector. If personalized connections are used, emails and notifications sent via the SMTP connector show the current user as the sender. If the fictitious user 'John Doe' runs an approval flow and the flow sends notifications via the SMTP connector, those notifications originate from John Doe's email account. However, sometimes it makes sense to use a different sender address (like no-reply.powerplatform@my_org.com) if non-personalized notifications should be sent but still originate from the organization. In that case, the app developer might create a connection using a technical account and share the connection with all users that the app itself is shared with. In that case, the sharing permission "Can use" might be the best option as it prevents users from changing the connection.
Another potential connection sharing use case might be implementing something like "elevated privileges" (if you are an old-school SharePoint developer used to deal with server-side code, you know what I mean). This means, that a shared connection is used to enable users (via an app or flow) to access data they usually do not have access to. I strongly recommend against ideas like this as this is anulling security features of Power Platform.
Multiple connections of the same kind
Recently, I was asked if a user can have multiple connections of the same kind - means multiple SharePoint Online connections or multiple SMTP connections. The answer is: Yes! Let's assume, there are two (2) apps hosted in an environment and both apps use a SharePoint Online list as the data repository. In cases like that, it is likely that there are multiple SharePoint Online connections listed per user. Usually, that is not a problem, but it can become an issue for developers. Let's assume, a developer creates a flow that also uses a SharePoint Online list as a repository. If the developer adds e.g. a SharePoint Online 'Read Item' action to the flow, the developer needs to be careful with what connection to be used. Both existing SharePoint Online connections will be shown and an additional option to create a new connection is also shown. Picking the wrong connection here might result in some additional debugging time.
Summary
Although sharing connections is doable, I recommend being very careful with this feature. There are use cases that benefit from shared conenctions, but based on my experience with different clients, shared connections often cause issues or at least confusion. If you want to use shared connections in your organization, ensure your users know about conenctions and how they are managed in Power Platform. I also recommend adding guidelines regarding connection sharing to your corporate Governance document and to a Center of Excellence (Part 1 and Part 2).