Protocols & Automation

Zapier / Make / n8n

Automation platforms already connect the systems nobody built a proper integration for. An assistant can reach them the same way, which frequently means reaching everything else too.

Protocols & AutomationRead-scopedPermission-awareAudited lookupsArabic & English

Automation platforms already connect the systems nobody built a proper integration for. An assistant can reach them the same way, which frequently means reaching everything else too.

What Zapier / Make / n8n holds, and why that matters here

Zapier, Make and n8n are automation platforms that sit between systems, moving data and triggering actions across hundreds of applications. Many organisations already run substantial automation through them.

For an assistant, they are useful in two directions: as a route to systems with no direct integration, and as a way to trigger existing automations conversationally rather than through a form or a schedule.

  • Existing automations — the workflows already built and running.
  • Connected applications — the systems these platforms already reach.
  • Triggers — what starts a workflow.
  • Run history — whether an automation succeeded.
  • Data mapping — how information moves between systems.

Questions Elbi can answer through Zapier, Make or n8n

Run this for me

Triggering an existing automation conversationally.

Did that automation work?

Run status, which is otherwise checked in a separate tool.

What is connected?

Which systems are reachable through existing workflows.

Why did it fail?

Error detail from a failed run.

When did it last run?

Execution history.

Reach a system with no direct integration

Using an existing connection rather than building a new one.

How Elbi works with Zapier, Make and n8n

  1. Each workflow gets a named entry pointA workflow Elbi may use starts from a webhook trigger: a Webhooks by Zapier trigger, a custom webhook in Make, or n8n's Webhook node. Elbi knows each one by name and purpose, such as "resend invoice" or "check delivery slot", rather than as a general route into the platform.
  2. Named fields, not free textElbi gathers what a workflow needs in conversation, such as an order reference or a preferred date, and sends it as named fields. The workflow does not receive the conversation itself unless you design it to.
  3. Answers need a workflow that repliesIn Make and n8n a workflow can send a result back in the same request, which suits lookups. A Zap started by a webhook normally runs after the call has been acknowledged, so Zapier suits "do this" better than "tell me this", and Elbi says the request was accepted rather than claiming it has finished.
  4. The workflow acts with its own connectionsDownstream systems are reached with the credentials stored in the automation platform, not the asker's. So a workflow Elbi can trigger should either be safe for anyone entitled to ask, or receive the asker's verified identity and check it before acting.
  5. Failures are reported, not hiddenIf a run errors, times out or has been switched off, Elbi says the task did not complete and hands over to a person with the details, instead of telling someone it is done.
  6. Consequential steps wait for a personWorkflows that move money, change an entitlement or message a customer can require a person's confirmation before Elbi triggers them. Everything else is exposed one named workflow at a time.

Workflow scope, platform credentials and what stays yours

Direction of accessOnly the workflows you list, each through its own trigger. Reading run history, where you want it, is a separate permission from triggering, and nothing in the connection is used to edit or create workflows.
Who can see whatWorkflows run with the platform's stored connections, so per-person limits are enforced by passing the asker's verified identity into the workflow and checking it there, or by exposing only actions that are safe for everyone allowed to ask.
CredentialsWebhook URLs, shared secrets and API keys are all issued from your Zapier, Make or n8n account. Turning a workflow off, deleting its webhook or rotating a key closes Elbi's route to it straight away.
Where data goesElbi sends only the fields a workflow needs. Its own conversation content is destroyed within 24 hours and no external AI service sees it; the automation platform keeps its own run history under its own rules, which is a reason to keep payloads lean.
AuditElbi logs each trigger with the workflow name, the fields sent, the result and the conversation. The platform's run history shows the same run from the other side, so the two can be matched.
If it is unavailableIf the platform is down, the workflow is paused or it returns an error, Elbi says so and offers a person rather than assuming the task went through.

What this replaces

The pragmatic value is reach. Organisations run applications that will never justify a dedicated integration — a niche scheduling tool, a regional service, something a department adopted independently. Where an automation platform already connects to it, the assistant can reach it too.

The second is conversational triggering. Automations are usually started by a schedule, a form or an event. Being able to start one by asking is genuinely useful for the occasional, human-initiated cases that do not justify building an interface.

The discipline is the same as everywhere else, and matters here because these platforms are deliberately permissive. Named automations, deliberately exposed, with anything consequential behind confirmation.

Who gets the most from an automation-platform connection

Organisations with existing automation

Reaching systems already connected.

Departments with niche tools

Applications that will never justify direct integration.

Operations teams

Triggering routine automations by asking.

Any long tail of applications

Coverage without building individual connectors.

Getting value from Zapier, Make or n8n

Start with workflows you already trust. A scenario that has run reliably for months from a schedule or a form is a better first candidate than one built new for the assistant, because its failure modes are already known.

Good first choices are small and started by people rather than systems: resend a document, book or move an appointment in a tool with no direct integration, check whether last night's sync ran, look something up in a regional service that only the automation platform reaches. Each becomes a named action Elbi can offer when someone asks.

Know when to move on. If one workflow ends up carrying a large share of your conversations, a direct connection to the underlying system is usually faster and easier to govern, and the automation layer is better kept for the long tail it suits.

What connecting an automation platform involves

  1. List the workflows by nameChoose the specific Zaps, scenarios or n8n workflows Elbi may trigger, what each one does, and what it must never do. That list is the scope.
  2. Add a webhook trigger and a secretYour team adds a webhook trigger to each listed workflow and, where the platform supports it, a header or token check, so that knowing the URL alone is not enough to start it.
  3. Define inputs and outputsEach workflow gets named input fields and, in Make or n8n, a response Elbi can turn into a sentence. Free-text inputs are avoided because they invite surprises downstream.
  4. Decide how identity is checkedWhere a workflow touches personal records, the asker's verified identity is passed in and checked inside the workflow before anything is read or changed.
  5. Rehearse the failuresA Zap that has been turned off, a scenario stopped by an error, an n8n instance mid-upgrade, a downstream system rejecting the request. Each should produce a clear "this did not complete", never silence.
  6. Launch with a few, then read the historyGo live with a handful of workflows and read a month of run history on both sides before adding more.

Personal data passing through an automation platform

An automation platform processes data in its own right: whatever Elbi sends into a workflow is handled by Zapier, Make or your own n8n instance, and is usually kept in that platform's run history. Under the Saudi Personal Data Protection Law it belongs in your record of processing, together with where the platform processes data.

Keep payloads to the fields a workflow needs, avoid passing the conversation itself, and for flows carrying sensitive records prefer a self-hosted n8n instance on infrastructure you control. On Elbi's side, message content is destroyed within 24 hours, usually when the conversation ends.

What organisations typically see

70%
of contact is status, eligibility or balance — the questions a connected system answers directly
24/7
coverage for lookups that previously waited for office hours
3x
faster first response when the answer is retrieved rather than requested
0
internal tickets raised for questions the assistant can answer itself

When an automation layer is the right tool, and when it is not

Zapier and Make are cloud services; n8n can be used in its own cloud or self-hosted, which some organisations in the Kingdom prefer so that workflow data stays on their own infrastructure. All three are adding their own AI and agent features, and for a team that only wants an AI step inside an existing workflow, those may be enough.

An automation layer is the right route when the target system has no API Elbi connects to directly, when the workflow already exists and works, or when the action is occasional. A direct connection is the better route when a system answers many questions a day, when per-person permissions matter on every call, or when speed matters, since each extra hop adds delay and another place for a run to fail.

The trap is letting the platform become an unreviewed back door: a long list of webhook URLs exposed just in case, each running with an administrator's connection. A short, named list keeps it defensible.

Common questions

Only those you deliberately expose. These platforms are permissive by design, which makes scope discipline more important rather than less.

Usually yes, by a step. It is a reach mechanism for the long tail rather than the right route for a high-volume system.

It reports the failure rather than silently succeeding, and can surface the error detail.

No. Elbi holds only the webhook URLs and secrets for the workflows you list, issued from your own Zapier, Make or n8n account. It never needs your login, and switching off a workflow or rotating its secret ends that route without going through us.

That is fine as long as the way in and the way out are simple: named inputs, and either a clear result or a clear failure. Branches, filters and code steps inside the workflow are mapped once and stay with your team.

Yes, where you list them, and any of them can require a person's confirmation first. Because the workflow acts with the platform's own connections, anything that changes a personal record should check the asker's identity inside the workflow.

Connect Elbi to your automation platform

Named Zapier, Make or n8n workflows, started from a conversation in Arabic or English.