Zapier is synonymous with cloud automation: connecting web applications and automatically exchanging data. This way, processes are automated and your information is always informed. But Zapier has got a lot of competition and we have already written several times on this blog about Make as a true Zapier alternative.
Make offers some advantages over Zapier, which we will go into in a moment. So you may come to a point, or already be there, where you are thinking of moving all your Zaps to Make. However, such a move be well thought out and planned. After all, you don't want to realise halfway through that it wasn't a good idea after all.
That's why in this post we give you 3 very practical and sometimes technical tips on how to switch from Zapier to Make.
Why switch from Zapier to Make at all?
At its core, there are three advantages of Make over Zapier that stand out strongly:
Make allows for more complex processes and thus automation
Make has some exclusive features that are enormously practical
Make is cheaper than Zapier, especially for many processes
But let's start at the top:
Make's interface is a modular one. This means that the process and workflow is represented by the arrangement of the individual modules. In addition, you can insert further modules at any point via drag-and-drop.
On the one hand, this makes it much clearer how your process works in the first place and where there may still be a need for improvement.
You can immediately recognise where errors occur, eliminate them and even define who should be informed about which errors in your scenario via error handlers.
You also gain a lot of flexibility. Individual modules can be exchanged, including the trigger at the beginning. This means you can re-model your processes at any time, adapt them to changing requirements or duplicate them in part or in their entirety.
In all three respects, Make is several steps ahead of Zapier. This makes the switch from Zapier to Make easier.
More options thanks to the switch from Zapier to Make:
The far more complex automations are closely related to the next point: Features that are exclusive to Make. One of these is mathematical formulas that you can insert at almost any point in your process. These are similar to Excel. This way you can model in even more detail at which point which data should be transferred.
Other exclusive features include:
Automatic error handling and the possibility to stop scenarios when an error occurs.
Work with files, including customising, reformatting and modifying data, as well as archiving ZIP or RAR files. Simply put, Make allows versatile ways to process data. Especially compared to Zapier.
Users can choose when to start processing the data in their scenarios. In Zapier, you have no "go back in time" chance.
Planning made easy; Expand the scheduling of your automated processes, which allows you to run scenarios on certain days and at certain times. For example, you can easily run a scenario in Make WITHOUT code virtually every fortnight. This would not be possible in Zapier.
GDPR First, Risk Second: Make offers the option to disable logging of transferred data.
Mathematical functions, similar to spreadsheets, for use in scenarios.
Break up data bundles or merge individual data with the help of iterators and aggregators. You can even build loops!
The ability to parse and manipulate HTML and to scrape data from a website. This is a bit more complex, but Make is clearly better than Zapier.
Encoding and decoding of URLs within text and binary functions.
Array manipulation, JSON/XML parsing and serialisation, cycles and transactions.
Pricing as the main reason for switching from Zapier to Make
Last but not least, Make pursues a slightly different pricing strategy:
Both platforms, Make and Zapier, offer free plans. By the time you read this blog post, however, you will probably be long past that point. Afterwards, a very different picture quickly emerges:
All prices refer to annual billing. The cheapest plan at $19.99 comes with 20 Zaps, i.e. 20 processes and 750 tasks per month. Tasks at Zapier mean ...
After that, it goes straight to $49, or 2000 tasks and an infinite number of zaps. In addition, custom logic paths are also enabled here, i.e. even more comprehensive dependencies and complexity.
Make, on the other hand, starts at $9 per month and 10,000 operations. Operations are to Make what tasks are to Zapier.
Accordingly, you get more operations with Make in a $9 package than with Zapier in a $49 package. In our experience, the standard package for $29 already offers sufficient capacity for most companies. And if you do exceed your limit, you can always flexibly add 10,000 operations for $9.
This is how the change from Zapier to Make succeeds:
In principle, there are various possibilities, which differ in terms of effort but also in their long-term nature. Certainly, a mixture of all approaches is the most recommendable. The change from Zapier to Make is a good opportunity to take a closer look at the existing processes and possibly optimise them. That is also the first suggestion:
Move processes from Zapier to Make
If you have been on Zapier for a long time and have accumulated some processes and zaps, then it is worth manually moving from Zapier to . Make offers almost all the functions that Zapier also offers. That's why the move is easy and the modular interface gives you a better overview (in our eyes) of the process of your automations and the interrelationships.
Since Make offers lower costs per operation and lower maintenance costs, the time spent is worth it in the end.
For this very purpose, we have put together ready-made packages that make the move from Zapier to Make easy for you. Whether 5, 10, 20 or many more zaps, we move them according to the highest development standards and thus make the switch much easier for you.
This type of change is probably the most accurate and especially the most successful in the long term.
Using the Make Zapier module
Make also offers Zapier as its own module. This has basically only two functions: Send data to Zapier or receive data from Zapier.
This way you can build a bridge to Zapier and connect both automation platforms. For example, you could map the particularly extensive processes in Make and only leave the steps in Zapier that require few operations or must be mapped in Zapier.
Conversely, this also means that you will keep your Zapier account and share the load between two platforms. This could be relevant if you use apps that are only supported by Zapier but not (yet) by Make. This reduces your effective costs for switching from Zapier to Make, but you still keep both.
You really don't want to use Zapier any more? Then there is a solution for this too. Here's how to switch completely from Zapier to Make:
Using Webhooks and HTTP Requests
In principle, all applications supported by Zapier have a suitable API interface. Zapier makes use of this. Make can also do this, however, via a small diversions. Make has modules for webhooks and HTTP requests. These can also be used to process data from applications that do not have an Make app.
A very good example of this is the Videoask application. Videoask is the sister of Typeform and works very similarly - only via videos. You can package your questions or tasks in videos and send them to countless people. They in turn answer your questions via text, audio or video. Videoask can even depict multi-step and conditional processes.
However: Videoask is not yet supported as an app by Make. However, the application offers the possibility to integrate webhooks. These send data to your MakeScenario after every incoming response, for example. And there they arrive in excellent quality: so you can process the required information perfectly, even without a Videoask app.
Cloud Integration, iPaaS, SaaS, BPA… Ough, hard to keep track of all these terms. They are currently used frequently (and increasingly) in the context of automation, and it is sometimes difficult to make a clear distinction and distinction. We have already written blog posts on the terms iPaaS, SaaS and BPA, but we’ll take them up again here to make the difference.
But let’s start with cloud integration, because that’s the central umbrella term in which we embed all the other technologies in this blog post.
To illustrate these advantages, an example is suitable that we know well from our everyday work as an automation agency:
The central data to be used here is the data of a major customer. This can be the simplest information, such as the address. This address is required in numerous but completely different processes in the company: on the one hand, for correct invoicing in accounting. On the other hand, in the CRM system, where all the data of the large customer is also stored. But the address is also important in sales, for example, when employees go to the sales meeting on site.
Now the customer announces that the address of the company has changed after a move. This information will reach you by e-mail. There are now two options:
01. The e-mail is forwarded to all affected departments, accounting, sales, customer service, marketing… All persons open their corresponding program, CRM, accounting software, marketing tools (such as newsletter marketing) and change the data already stored there of the customer. This means that in multiple applications, different people do exactly the same thing: change one address. 02. But there is also an alternative: By connecting your applications, thus by integrizing them, the customer’s e-mail, or rather the information it contains about the address change, is automatically passed on to all affected applications: CRM, accounting, marketing, ERP. This does not require any clicks, because the cloud integration detects a trigger, i.e. address change, and thus automatically starts the process.
What sounds unimpressive in a single process becomes more effective when such a process occurs several times a day or weekly. Because there is a lot of data that is available in different applications and should always be correct. If these applications are cloud applications they are suitable for cloud integration.
But cloud integration doesn’t just happen. There are now a variety of applications that enable and implement this. Such tools usually allow us to link the relevant cloud applications on a central platform and define clear rules on when, how, where, how much data should be passed on and what happens to them.
IPaaS, SaaS, BPA, ABC – who can still see through it?
To realize cloud integration, there are various applications and technologies that are sometimes used interchangeably.
Cloud integration cannot be done without SaaS, iPaaS and BPA
Cloud integration is rather an umbrella term that includes numerous technologies, such as SaaS, iPaaS and BPA, and this is also absolutely necessary. Cloud integration is a concept that is made possible by appropriate technologies.
However, all terms share the commonality that they are cloud-based and thus offer enormous potential for growth and scaling. In addition, they are often cheaper to implement and maintain because changed requirements are easy to implement.
As an independent automation agency, we implement cloud integration according to your requirements. We use a variety of SaaS tools and iPaas (strictly speaking BPA) software. Together we find individual solutions that are flexible and scalable.