Connectors and Connections

Connectors and Connections

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:

  • Can use: a user can use the connection, but can't edit it. However, the user can see some of the parameters used (but not passwords).
  • Can use + share: same as above, but the user can continue to share the connection
  • Can edit: the user can edit the connection and update it to use her/his credentials. Although the connection can be edited, users don't get access to any includes passwords.
  • Owner: the owner is the person who created the connection and only owners can delete a connection

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).

Other articles of this series

  1. Centre of Excellence - Part 1
  2. Centre of Excellence - Part 2
  3. Managing Environments
  4. Power Platform Connectors
  5. When to use and when not to use
  6. Connectors and Connections
  7. Insufficient Change Management

要查看或添加评论,请登录

Oliver Wirkus的更多文章

  • Enhancing the SharePoint Online user experience with customized PowerApps forms

    Enhancing the SharePoint Online user experience with customized PowerApps forms

    SharePoint Online Forms Experience SharePoint Online has been an integral part of Microsoft 365 since the beginning…

  • Power Platform - Manage Licenses

    Power Platform - Manage Licenses

    If you are dealing with Power Platform for a long time, you probably will agree that managing licenses can soon become,…

    2 条评论
  • Power Automate - Hidden Trigger Properties

    Power Automate - Hidden Trigger Properties

    The ability to trigger a Power Automate Flow from within a PowerApps application provides many benefits. Especially the…

    1 条评论
  • Address Validation Example

    Address Validation Example

    Power Automate is not just a great tool to enhance business logic (like the famous Approval workflows used by so many…

  • A simple integration approach

    A simple integration approach

    I admit this might not be a sophisticated solution nor is it meant to be an article for tech-savvy Power Platform…

  • Why Branding?

    Why Branding?

    If I think about "Branding", the first thing that comes to my mind is the branding of a corporate website. I may have…

    2 条评论
  • SharePoint Online and Power Platform - My recommendations

    SharePoint Online and Power Platform - My recommendations

    When organizations roll out Power Platform, there are usually three groups of users: tech-savvy early-adopters, regular…

  • Unexpected User Acceptance

    Unexpected User Acceptance

    This post is not about a technical pitfall regarding Power Platform. Maybe, it could be considered a pitfall, but a…

    3 条评论
  • Power Platform - Rapid Screening App

    Power Platform - Rapid Screening App

    The more we are into Covid, there it becomes clear, that there won't be a normal 'Back to Work'. Organizations start to…

  • Insufficient Change Management

    Insufficient Change Management

    I think all of you will agree that Change Management is key to success for almost every digital workspace…

社区洞察

其他会员也浏览了