A Make scenario that has quietly moved records for months breaks in one of two ways: the history fills with red modules and a short error string, or it goes silent and nobody notices for a week. Neither is random — almost every failure between Make and Bitrix24 (Alaio) comes from the same four places: the connection, the polling trigger, field codes, and the missing search step in front of a create.
Why does the connection fail after months of working?
Make reaches the portal through an application: either the listing installed from the Market, or a local app you registered yourself with a client id, a secret and a handler URL pointing at Make's callback. Two things freeze at that moment — the scopes the app may use, and the employee whose session authorized it. Remove the app from the portal, deactivate that employee, or trim the scopes, and every module in every scenario fails at once, with an authorization error rather than a data error.
The string tells you which side to fix. ERROR_OAUTH: Application not installed means the app is no longer on the portal, so reconnecting in Make changes nothing until it is back. An invalid or expired token means the refresh cycle broke and the connection has to be authorized again — that sequence is in expired token and invalid_grant. Editing the failing module fixes neither one.
Why does the Watch module miss records?
Because it polls. Watch Deals, Watch Leads and Watch Tasks are not event subscriptions: on the scenario's schedule they ask the portal what appeared since last time. Three settings decide what they see: the interval, whether the filter runs on created or on modified time, and how many items one cycle may take — a field that ships with a very small default. A bulk import of two hundred leads therefore trickles in a couple per run until the queue catches up, which reads exactly like a trigger that missed records. Watching by created time never notices edits; watching by modified time re-reads what the scenario itself just wrote.
Polling costs on both ends: the run happens whether or not anything changed, and every cycle spends portal REST calls. The portal allows roughly a couple of calls per second, so an iterator walking a few hundred records without pacing hits QUERY_LIMIT_EXCEEDED — and that ceiling is per portal, so the second scenario inherits it.
When the reaction has to be immediate, let the portal push instead: an outbound webhook aimed at a Custom webhook module, or a step inside the workflow itself. An HTTP request GET/POST fires at the exact point of the process you chose and sends only what you decided to send; Build JSON from fields assembles the body without hand-escaping quotes; Extract value from JSON by path reads the answer back into the process. Where a lost delivery is expensive — an order going into production, a document going out for signature — Reliable webhook retries on its own schedule instead of failing once and moving on. Both directions are covered in webhook troubleshooting.
Why does Create or Update fail when the data looks right?
Field codes, nearly always. Custom fields travel under their UF_CRM_… code rather than the label on the card; stages and pipelines go by id; phone and email are multifields, so a plain string lands in the wrong shape or silently does nothing. A stage can also demand fields that were optional a moment earlier, which is why a record a person saves by hand comes back rejected from a module. Check the payload against the real codes before suspecting the module: the walkthrough for the most common case is updating a deal field through the API, and the strings are sorted by cause in the REST API error codes map. Methods without a dedicated module go through Make an API Call, which obeys the same rules with none of the field mapping.
Why do duplicates appear after a re-run?
Because create modules create. Re-run a batch that died halfway and everything before the failure point lands a second time — nothing in the payload says "this one already exists". The shape that survives re-runs is search, branch, then create or update, and the cheapest place for it is the portal: find deal and find contact hand an existing record back to the process, so the branch happens before anything is written. What has already piled up is a separate job — see finding and merging duplicates.
Which half of the scenario should not be in Make at all?
The half that never leaves the portal. Moving a stage, filling a field, opening a task, branching on a condition: routing that through an external scenario buys a round trip, a second place to debug and a quota to watch, and buys nothing else. The workable split is that Make owns the systems outside, the portal owns its own records, and one call joins them — the in-portal side being ordinary workflow automation in Bitrix24. When it is that in-portal step that never started, the checklist is automation not running. The same trade-off for the neighbours is in connectors versus in-portal automation and in connecting Bitrix24 to n8n.
Where to go from here
Take the scenario apart into two lists: modules that touch systems outside the portal, and modules that only touch portal records. Move the second list inside, and what remains is usually one connection and one webhook — small enough to keep alive. The blocks for the portal side are in the robot catalog, and if the one you need is missing, describe the task: Roboteka builds missing automation rules for free and ships them to the shared library.