Platform Ideas and Improvements

A simple request, but it will take som time to implement successfully. Please add dark mode.

copy condition of the filter and paste to another filter -------------------------------------- BEST PRACTICE: https://support.integromat.com/hc/en-us/articles/360001988734#copying-a-filter

It would be good to have a undo button and be able to restore a older version of your scenario. There's many times where I worked very hard then forgot to save and am able to see what I did in my history but I cant restore or undo. Once my computer updated while i was working and I lost all my progress. -------------------------- SEE ALSO: https://integromat.canny.io/admin/board/feature-requests/p/autosave-a-scenario https://integromat.canny.io/admin/board/feature-requests/p/version-history -------------------------- BESTPRACTICE: Store your work on an ongoing basis. When you find out, that you need to use a previous version, open the list of previous versions and select the one, that you would like to use (see the screenshot).

Being able to setup more than one trigger per scenario is useful when the same kind of data comes from different sources. Ex: Leads comming from Facebook Ads, and from another, generic, webhook. ------------------------- BESTPRACTICE: Create a "core" scenario that would perform the common data processing. Insert the "Webhooks > Custom webhook" module at the beginning of the scenario. Copy the webhook's URL. (see https://support.integromat.com/hc/en-us/articles/360006249313-Webhooks for further information about webhooks) For each trigger you would like to employ create a separate scenario and insert the corresponding trigger in it. Connect the "HTTP > Make a request" module after the trigger. Configure each "HTTP > Make a request" module to pass the data to the "core" scenario: paste the copied URL in the URL field and map the items in the Fields field. (see the attached screenshot and https://support.integromat.com/hc/en-us/articles/360006248533-HTTP for more information about making HTTP requests) SEE ALSO: https://integromat.canny.io/feature-requests/p/execute-a-scenario-sub-scenario

Currently, the “Maximum number of agent runs in thread history” setting replays the entire agent context (system prompt, context documents, and tool schema) for every historical run included. This creates compounding, unnecessary token inflation and repeated duplication of static context. This feature request is to change the behaviour so that Make.com only resends: • The static agent context once (system prompt, context docs, tool schema), and • The N most recent user/assistant messages based on the run-history limit. This would dramatically reduce token usage, speed up scenarios, improve clarity of conversation state, and bring Make.com in line with how modern conversational AI frameworks structure context windows.

There is a 300 second maximum for the sleep module. This isn't enough of a pause for some of my scenarios, so it'd be great if it could have a higher maximum (20 minutes etc.)

The Converger module is basically a counterpart of the Router module and it would enable you to merge several routes into one. ------------------------- BESTPRACTICES: https://support.integromat.com/hc/en-us/articles/360016984073-Converger When in doubt, please, contact our support ( https://www.integromat.com/en/ticket ) or feel free to post a question to our Facebook Integromat Community group ( https://www.facebook.com/groups/integromat/ ), where hundreds of specialists, users and fans are willing to help.

It is currently very cumbersome and time-consuming when a connection becomes faulty or has to be replaced for other reasons (e.g. re-authorization problems, employee has left the company,...). The current process requires you to create a new connection and then manually replace it in every single scenario and module that uses the old connection. With a large number of scenarios, this process is not only extremely time-consuming, but also very error-prone, as you can easily miss a module. solution: I suggest introducing a new feature directly to the “Connections” management page. Next to each connection (e.g. via the three dots), there should be a new option, such as “Replace connection” or “Swap connection”. The ideal workflow would be: When the connection is old/faulty, the user clicks on “Replace connection”. A dialog opens in which the user can select the new connection from the list of their existing (and compatible) connections After confirmation, Make automatically searches all scenarios and replaces each instance of the old connection globally with the selected new connection.

Currently, the Make platform does not provide metadata to identify the owner of a scenario. As a workaround, our team has adopted a naming convention that includes the user’s email address to indicate the DRI. However, this approach is not scalable and introduces unnecessary complexity. We would like to request an enhancement to include scenario owner information in the response from the Scenarios API endpoint. This would improve clarity, reduce manual workarounds, and provide a more reliable way to manage scenario ownership.

When developing new scenarios it's a pain to deal with testing/dev data. Fx. I get a webhook as a trigger for the scanerio and I have a bunch of modules in the scenario, that all use data from the webhook. Why can't I use the data from the webhook when running a single module? Faking data can often cause production error, because the data wasn't real. If I have already run a module and need the output in following module, why can't I use the output from that first module, when running the second module only? ---------------------------------------- SEE ALSO: Incomplete executions: https://support.integromat.com/hc/en-us/articles/360001988854-Incomplete-executions Enable "Choose Where To Start" for instant triggers / webhooks: https://integromat.canny.io/feature-requests/p/enable-choose-where-to-start-for-instant-triggers-webhooks Ability to "re-run" historical instances: https://integromat.canny.io/feature-requests/p/ability-to-re-run-historical-instances