Merge File repository and Server space connectors

Feature requests
1

Hi,

We have a kind of frustration about this. The file repository connectors can be created by end users using a network folder, and the server space connectors are generally created by an admin of the server. But when you are an end user, you would like to use both file repo and server space connectors inside one project. I don't think it's possible today : you have to choose one option.

The behaviour would be similar to embedded connectors. Today Easymorph desktop merge embedded connectors and either server space or file repo connectors. Why not merge the 3 sources of connectors ? When I say "merge" I mean that if you use an action that requires a connector, you can select among connectors from one shared source and among embedded connectors.

2

Hi Romain,

For me to understand the case better:

  • Why do users need to have local (file-based) repositories?
  • What prevents them from creating connectors in the shared (Server-hosted) repository and use them in local workflows?
3

There can be various reasons to have local repo. 2 Examples :

  • admin have no time to add this connector
  • connector to a "POC" database

We do not allow end users to add their own connectors on server side. One big reason : it's more an IT thing to provide access to a ressource like a database. We prefer to keep the ownership on this (it's highly technical and there are passwords there).

4

In the next release (6.1), we're going to introduce user-scoped connectors. Connectors of this type should be authenticated by each user, so credentials aren't shared even if the connector is shared. Users will be able to use connectors and, if permissions allow, create them, but not share credentials. As I understand, they create connectors anyway, they just store them in a local repository. In case of user-scoped connectors, all of them will be stored in a Hub (Server) repository which has the additional benefit of governance, so because Hub admins can see what connectors users create and use.

Do you think this improvement would work for the cases you described?

5

If a part of the connectors is official where details can't be seen, and another part is on the hand of the users, why not. I guess that's the current behaviour with shared + embedded connectors. I understand that classic database connectors would not have login + password, M365 connectors would not be authenticated etc. Because if one user authenticate a M365 connector and share it, that would be a major security issue.