Build your first automation
An automation in Arino One is a trigger that starts it, conditions that filter it, and actions that carry it out — built in Automations → New flow and tested in draft before it touches live traffic. Keep each flow single-purpose: three small flows are easier to debug from the run log than one flow with a dozen branches.
Step 1 — Pick a trigger
Every flow starts with exactly one trigger. The common ones are an inbound message on any channel, a specific keyword or phrase, a form submission, a change to a contact attribute or tag, or a schedule (fixed time, or relative to another event such as "24 hours after last reply"). Pick the narrowest trigger that fits the job — a keyword trigger is easier to reason about than "any inbound message" with heavy conditions layered on top.
Step 2 — Add conditions
Conditions decide whether the flow continues past the trigger. Typical filters are channel (WhatsApp only, not SMS), a contact attribute (plan = "enterprise"), consent state (has marketing consent for this channel), or business hours (only during support coverage). Conditions evaluate against the contact's current state at that point in the flow, not the state when the trigger fired — build flows assuming a few seconds or minutes may pass between steps.
Step 3 — Add actions
Actions are what the flow actually does: send an approved message template, assign the conversation to a team or specific agent, set or update a contact attribute, add or remove a tag, or call an outbound webhook to notify another system. Chain multiple actions in sequence, but keep the chain short enough that you can name what each step does without looking it up.
Step 4 — Test in draft
Every new flow starts in draft. Use the test mode to run it end-to-end against a test contact, stepping through each condition and action to confirm the branch you expect is the branch that fires. Draft flows never touch live traffic, so this is the place to catch a misconfigured condition before a real contact does.
Step 5 — Publish and monitor
Publishing moves the flow from draft to live; it starts evaluating real traffic immediately. Watch the run log for the first day — it shows every contact that entered the flow, which branch they took, and any action that failed. A flow that looks correct in testing can still behave differently under real traffic volume, so this first-day check is not optional for anything customer-facing.
Common first automations
| Automation | Trigger | Typical action |
|---|---|---|
| Out-of-hours acknowledgement | Inbound message outside business hours | Auto-reply with expected response time |
| Keyword routing | Keyword match (e.g. BILLING, HELP) | Assign to the matching team |
| SLA escalation | Schedule check against unanswered time | Reassign or notify a supervisor |
| Consent-gated re-engagement | Tag change (e.g. "lapsed") | Send approved template, only if consent is current |
How this differs by instance type
| Connection status | Who builds flows | Notes |
|---|---|---|
| Connected ($50/month Arino Core connection) | Your team, with Arino support available | Arino can help build or troubleshoot flows as part of the connection; actions run through your own Infobip account |
| Unconnected | Your team, entirely | No Arino support if a flow misbehaves in production |
Costs to expect
Building and publishing flows is free either way — the flow builder is part of the platform. Ongoing Arino support for flows (help building them, troubleshooting a misbehaving flow) is available as part of the optional $50/month Arino Core connection. Every message a flow's actions send is a normal message or conversation and is metered separately by Meta/Infobip, not included in that $50 — see billing-and-plans for current figures. Unconnected instances have no Arino billing at all; usage is billed directly by Infobip and Meta.
Steps at a glance
- Pick a triggerIn Automations → New flow, choose what starts it: an inbound message, a keyword, a form submission, a contact attribute or tag change, or a schedule.
- Add conditionsNarrow the trigger with conditions on channel, contact attribute, consent state or business hours so the flow only runs for the traffic it's meant for.
- Add actionsChain actions such as sending an approved template, assigning the conversation to a team or agent, setting a contact attribute, adding a tag, or calling an outbound webhook.
- Test in draftUse the built-in test mode to run the flow against a real or synthetic test contact and step through each branch before anyone else sees it.
- PublishPublish the flow. It moves from draft to live and starts evaluating real traffic immediately.
- Monitor the run logWatch the flow's run log for the first day of live traffic, checking for contacts stuck at a step or actions failing silently.
Frequently asked
Can one automation trigger another?
Yes, an action can set an attribute or tag that is itself the trigger condition for a second flow. Keep the chain short and documented — three linked flows are already hard to reason about from the run log alone.
What happens to a contact mid-flow if they reply?
An inbound reply is evaluated by the console's normal routing at the same time the flow continues, so a well-built flow checks the contact's latest state at each step rather than assuming nothing has changed since it started.
Can an automation send a WhatsApp marketing message outside the 24-hour window?
Only using an approved template, and only to contacts with recorded consent for that channel and purpose. The flow's condition step is where you enforce the consent check before the send action runs.
Do automations cost anything beyond the $50/month?
The flow builder itself is part of the $50/month connection and management fee. Any message an automation sends is billed as a normal message/conversation, which is metered separately — see billing-and-plans for figures.
Can I roll back a published flow?
Yes, unpublish returns it to draft without deleting it, and earlier versions remain visible in the flow's history so you can compare what changed before a fault appeared.
Why did my webhook action fail silently?
The most common cause is an endpoint that stopped responding with a 2xx status; check webhooks-not-arriving for the diagnostic steps, since a failed webhook action does not by itself stop the rest of the flow from completing.
Apply this to your own deployment
This guide describes decisions we make on live instances. Tell us your channels, systems and region and we will map it to an architecture outline, a provisioning plan and an indicative commercial model — usually within one business day.