Connections: mappable/dynamic connections
complete
Jason
The ability to direct a connection source for an outside service such as Google Maps or Google Sheets within the scenario itself. For example, if a variable = X then I want it to use Google Connection A.. If variable = Y I want it to use Google Connection B.
Log In
Canny AI
Merged in a post:
Conditional Connections and Keys usage
Arek Czub
Hi,
I would like to be able to use Connections and Keys conditionally. Meaning that I'd like e.g the HTTP module to change which connection or key it uses depending on the data fed to the scenario. Some use cases are your Snowflake Execute SQL module or the HTTP module. We have dozens of Snowflake accounts and each requires different credentials to work with its API. I have to create an entire separate branch for each account for basically the same statements I want to pass to the API whereas I could just rotate through connections and accounts in one branch by mapping it depending on the data provided to the scenario.
Best,
Arek Czub
RelationalAI
D
Darin Patterson
This is related to dynamic connections (described here: https://www.make.com/en/help/connections/dynamic-connections) Currently available on the enterprise plan.
Arek Czub
Darin Patterson That's not exactly what I was looking for although it allowed me to simplify my scenario nevertheless. The issue with that is that you need to create an additional "trigger" scenario which then runs the proper scenario via API and passes data on which connection has to be used. That's improvement but still not what I mean.
What I mean is being able to process that in just one scenario which gets triggered e.g using a webhook and then chooses the connection for each operation based on the data provided.
D
Darin Patterson
Arek Czub: thanks for your note. I am glad you were able to simplify your scenario a bit.
Yes, you are right, that you ultimately need two scenarios to pull off the dynamic connections.
We closely evaluated how we could make connections "truly dynamic", but unfortunately (due to deep architectural nuances), the scenario has to be initiated with a known set of possible connections. So this is the closest we were able to get without a huge amount of effort.
D
Darin Patterson
complete
With the release of "Dynamic Connections", this is now possible. Unfortunately, it was not possible to have completely "mappable" connections, but you can create scenarios that call other scenarios and provide the connection ID to use.
This feature is currently only available in the Enterprise plan.
Luc Douve
Hi Darin Patterson ,
I strongly disagree with marking "Dynamic Connections" as COMPLETE. While the initial implementation is a step forward, it falls short in several critical ways and remains inaccessible to a vast portion of your user base due to its restriction to the Enterprise plan.
There are numerous enhancements needed to truly complete this feature:
- Mapping Connections Dynamically: Allowing connections to be mapped based on inputs within the scenarios themselves.
- Multiple Triggers: Enabling multiple triggers to initiate the same scenario, selecting the appropriate connection based on the trigger.
These functionalities should be available on all plans, not just Enterprise.
An example of what could be considered an Enterprise function is providing external authentication capabilities, where automators can let clients authenticate connections that are then loaded dynamically.
Competitors are quickly advancing and offering similar features without such restrictive access, putting Make.com at risk of losing its competitive edge. This decision urgently needs reconsideration. Calling this feature "complete" under the current limitations is misleading and undermines the needs of your broader customer base.
Ram Freedman
Darin Patterson
Just like Luc Douve, I'm excited about the potential of "Dynamic Connections" to choose connection sources for external services like Google Sheets or Maps on the fly within scenarios.
While marking "Dynamic Connections" as COMPLETE acknowledges progress, it feels premature.
Here's why:
Limited Functionality: The current implementation requires creating scenarios that call other scenarios, passing the connection ID. This adds complexity compared to a truly dynamic mapping within a single scenario.
Accessibility Barrier: Restricting this feature to the Enterprise plan cuts out a large portion of the user base.
Desired Enhancements for a Truly Complete Feature:
Dynamic Connection Mapping: Let connections be chosen based on scenario inputs, eliminating the need for nested scenarios.
Availability for All Plans:
These core functionalities should be accessible on all plans, not locked behind an enterprise paywall. Perhaps features like external authentication for client-managed connections could be reserved for higher tiers.
Competitive Landscape:
Competitors are rapidly offering similar features with broader access. This could put Make.com at a disadvantage. Reconsidering the limitations on "Dynamic Connections" is crucial.
Conclusion:
Calling this feature "complete" in its current state is misleading. Make.com can regain its competitive edge and better serve its user base by making these functionalities available to all and by offering more streamlined dynamic connection mapping within scenarios.
Ram
Peter McKenzie
This is very important for enabling scale for any business selling automation-based solutions to other businesses. Without dynamically mapping connectiong, it creates a lot of template copies that need maintaining manually. Thanks
Aslan Goldenhour
Any update on this feature? I could imagine using Make.com indefinitely for backend-as-a-service work if something like this (or this: https://www.make.com/en/platform-ideas/p/connections-deployment-environmentsconnections-development-staging-productionliv) existed. Sadly, we'll need to migrate completely away from Make.com as we mature if this is not in place soon. Without the ability to manage different environments things are just too brittle.
p.s. The workaround of managing duplicate scenarios via blueprint export/imports is untenable, as it's too prone to errors. For example, imagine a complex set of 10 scenarios that all interplay with each other using the HTTP module and webhooks. And dozens or more instances of database connections. To migrate from dev to prod we'd need to export a blueprint, import a blueprint, manually change every HTTP->webhook link between scenarios, and manually change every connection instance. No thank you. 😱
Michael Stranks
This would be very useful for me and my work, and fits well with the other dynamic capabilities of the Make platform.
Georg
Is there any news about the timeline for this feature? Adding manual connections and not being able to dynamically add/map connections to e.g. sharepoint or ftp-servers is severely holding us back from upscaling our business.
Georg
once more, highly requested
Georg
PS: would be great to have this in CORE plan
Georg
one more upvote, highly requested for Zoho-CRM connections: Add dynamic connections
Load More
→