What does this solve?
Half of the automation in a small company looks the same: take a new row from the table, put it in CRM, send an email, duplicate it in the chat. Writing code for this means having a repository, server, deployment, monitoring and a person who services all of the above. Make and Zapier remove all the hassle: authorization in services in a couple of clicks, ready-made connectors to thousands of applications, launch and retry on their side, execution log in the interface. The bundle is assembled in an evening by a person without a developer, and for the first months it costs less than a programmer’s hour.
How it works
Both platforms are built on the same scheme: a trigger event starts a chain of action steps, data flows between steps, and the fields of the next step are filled with values from the previous ones.
Triggers: instant and polling
An instant trigger works on a webhook: the service itself informs the platform about the event, the chain starts within seconds. Survey trigger - the platform visits the service on a schedule and looks for something new. The polling interval is tied to the tariff: on lower plans the pause is noticeable, on older plans it is shorter. The design flaw that comes up last is that the script is designed to respond “immediately,” with a poll trigger underneath it, and “immediately” actually means “sometime in the next few minutes.”
Zapier
Unit - Zap: one trigger and action sequence. Branching is done through Paths, screening through Filter, conversion of dates, strings and numbers through Formatter. There is a step with code in JavaScript or Python, there is the reception and sending of arbitrary HTTP requests (by a separate premium application). Tariffing - by task: each completed action is counted; triggers and runs cut off by the filter are usually not charged. The run log (Zap history) shows the data of each step; paid plans have an automatic restart of failed ones.
Make
Unit - scenario: a canvas with modules and connections, closer to a diagram than a list. There are routers (several branches from one point), iterators (decompose an array into elements) and aggregators (assemble elements back into one package) - this pair covers the work with collections, which is difficult in the linear model. Error handlers are attached to a specific module with a choice of behavior: skip, abort, repeat, rollback. Unfinished runs are put into a separate queue and restarted manually. Tariffing is based on operations: each activation of each module debits one unit.
Access storage
Connection to a service is an OAuth token or API key stored on the platform side. From this moment on, the external service has constant access to mail, disk, CRM and accounting under the rights of the one who pressed the connect button. Permissions are granted once and are usually broad: a particular connector requests the entire set of permissions, and not the minimum that the script needs.
When the connector is not enough
Both platforms have a universal HTTP module: custom method, headers, body, response parsing. Any API that does not have a ready-made connector is connected through it, at the cost of manual work with authorization and token renewal. As soon as three or four such modules appear in a script in a row, the savings relative to custom code evaporate.
Useful scripts
- Lead from the website or from the advertising account → card in CRM → notification to the person in charge in the messenger.
- New invoice or payment → line in the accounting table → reminder to the accountant at the end of the week.
- Request in the support form → ticket in the tracker → automatic response to the client with the request number.
- Publishing content: one entry in the database → formatting for each site → scheduled posting.
- One-time data migration between services, where writing a script is more expensive than running a package once through ready-made connectors.
Limitations
The cost grows non-linearly. Tariffing is based on the number of operations, and not on the benefit. A cycle for a hundred order items means a hundred write-offs, not one. A script that polls a service every few minutes and finds nothing new 95% of the time is still wasting operations. You need to check the consumption not at the time of assembly, but on the actual volume after a week of work.
Logic lives in someone else's interface. The script cannot be put in git, look at the line-by-line differential, run tests and roll back with one command. There is an export, but it is a snapshot, not a history of changes. Who changed the field in the third module six months ago is an unanswered question.
Data goes beyond the perimeter. Personal data of clients, the contents of letters and documents pass through the platform. For a Russian company, this is a separate legal issue about the place of processing and storage - it is resolved with a lawyer before the launch, and not after verification.
Payment from Russia does not accept a Russian card. This comes down either to a foreign legal entity, or to intermediaries, or to the refusal of the platform - and the issue has to be resolved at a time when a dozen combat scenarios are already working.
The coverage of Russian services is selective, and the depth of the finished connector is often limited by basic methods. Everything outside is again a manual HTTP module.
Debugging limited to log. There is no breakpoint, there is no step through the code; inputs and outputs of modules are available for the history storage period, which is also tied to the tariff.
Limits on the part of end services are not going away. Batch uploading through the connector hits the rate limit of the API and crashes - the platform will honestly write off operations for each unsuccessful attempt.
How to check the result
A test run in the editor and combat work diverge more often than it seems: in the test, the data is inserted manually or the last record is taken, but in battle something arrives that was not in the test - an empty field, Cyrillic in the identifier, an array instead of a string. Therefore, after switching on, the first real event is checked in its entirety, according to the log, and not according to the actual “green status”.
In the log you need to look not at the result, but at the input and output of each step. A typical find: the step worked successfully, but an empty line was left in the field because the source named the column differently. Formally, everything is green, in fact, cards without a phone number appeared in CRM.
Event replay checks for idempotency: the same event is run twice and there should be one record left on the target system. If two appear, a search for an existing object is added to the script before creation.
The flow of transactions is controlled by a counter in the office in a real week. A sharp increase means either a cycle where it was not planned, or a survey trigger that works in vain.
Error behavior is checked intentionally: access to the target service is temporarily broken, after which it looks like what the platform did - repeated it, put it in the incomplete queue, quietly skipped the event. The third option means that you need a separate error handler and notification.
Notifications about falls are turned on immediately and are addressed to a living person, and not to a general mailbox. A script that was disabled due to an authorization error and remained silent for two weeks was discovered following a customer complaint.
The lifetime of connections is checked separately: OAuth tokens expire and the connector falls off months after setup. Symptom - runs with an authorization error in the log; It can be treated by reconnecting the account and sending a reminder in the calendar.