Connecting workflows to clients

Hello community!
I’m working on automating workflows for a client’s company and am looking for the best way to connect all the workflows to their existing systems and processes. Could anyone provide insights on the most effective approaches for linking workflows across different tools and platforms within the client’s organization?

Specifically, I’m looking for recommendations on how to:

  • Integrate workflows with the client’s internal systems (CRM, ERP, etc.)
  • Ensure data flows seamlessly between different departments
  • Optimize the scalability and reliability of these workflows over time
  • Set up permissions, access control, and security features across workflows for the team

I’d appreciate any tips or examples from your experience!

Thank you in advance!

Hi @IRON_GULLA,

that always depends on the exact automation, but you’ll most commonly use:

  • Webhooks to instantly trigger an automation when something in the client system happens

  • API calls to the client system to get, create, update and delete data

For anything specific, you’d have to outline the automation you want to set up. In that case, feel free to always tag me. I’ll do my best to respond ASAP :smiley:

~ Julius

1 Like

Hi @IRON_GULLA

Make.com does not offer predefined organizational frameworks, but there are several strategies that can be implemented effectively depending on the requirements:

1. Legacy System Flows:

If the automation flow is triggered by the source systems, the scenarios in Make will typically follow a webhook → respond webhook structure. In this case, Make receives an automation request, processes it, and sends a response back to the caller indicating success or failure.

2. Make-Controlled System Flows:

For instant or time-triggered actions, the scenarios are usually Make-controlled. These flows typically begin with the “watch” modules of the tool that triggers the action and perform the necessary tasks accordingly.

3. Complex Multi-System Automations:

In cases where an automation trigger leads to a chain reaction involving multiple scenarios, HTTP or webhook modules are key. For example, Scenario #1 may receive the initial trigger, but it could be Scenario #10 that sends the final success or failure response. In such cases, the source system must also support receiving data via webhooks.

Permissions and Access Control:

Ideally, non-technical teams should not have direct access to the Make.com platform. Triggers should be generated through the source system to maintain control and security. However, if access is required, Make.com offers team packages with infrastructure to manage permissions effectively.

I understand this is a high-level overview, but further details would help in providing more specific recommendations. I hope this was helpful!

1 Like