Why agency automation usually disappoints
The pitch is always the same and the reality rarely matches. You wire up a rule, it works in the demo, and then a month later you notice the follow-ups stopped. Usually because the automation was running in the browser, so it only fired when someone happened to have the tab open, which is precisely never at the moment a client signs something at eleven at night.
The other failure is opacity. Something did not happen and there is no way to find out why. No log, no step trace, no indication whether the trigger never fired or the action failed. So the team stops trusting it, goes back to doing the task manually, and the automation sits there enabled and ignored.
And the third: the automation only knows about one part of your business. A tool that can automate tasks but has never heard of your invoices cannot chase a payment. We wrote about the broader shape of this in how to automate agency workflows.
What Arpixa Automations is
Arpixa Automations is a graph, not a list. You build on a canvas by dragging nodes from a library split into Triggers, Actions, and Logic, then connecting them. A workflow can hold up to 50 nodes, which is more than enough for a full onboarding sequence and small enough to stay comprehensible.
Crucially, execution is server-side. When a qualifying event happens in your workspace it is written to a queue, and a scheduled runner picks it up, matches it against your enabled automations, and walks the graph. Time-based triggers like an invoice going overdue or a client going quiet are evaluated on the same schedule. Nothing depends on a browser being open.
The editor keeps a local draft as you work and warns you about unsaved changes, and there are 14 prebuilt templates to start from, covering things like project kickoff, client onboarding, an invoice chaser sequence, a payment thank-you, feedback collection, and re-engaging a quiet client.
What you can do with automations
| Capability | What it does |
|---|---|
| A visual canvas, not a rules list | Drag triggers, actions, and logic onto a node canvas and connect them. The library is grouped into Triggers, Actions, and Logic, with a minimap and controls for navigating a larger workflow, up to 50 nodes per automation. |
| 13 triggers and 17 actions | Triggers cover proposal accepted, invoice paid, invoice overdue, contract signed, form submitted, project status change, project completed, task completed, deliverable approved, new client added, client inactive, and member added. Actions cover creating projects, tasks, invoices, and documents, sending email, inbox messages, notifications, review requests and follow-ups, updating status and client fields, tagging, assigning a member, archiving, calling a webhook, generating a message with AI, and waiting. |
| True and false branching | A condition node has two outputs, so one workflow can handle both paths. Compare a project, invoice, client, form, or task field using equals, not equals, greater or less than, greater or less than or equal, contains, is empty, or is not empty. |
| Wait steps that survive the gap | A delay node pauses a workflow for minutes, hours, days, or weeks. The wait is persisted server-side with a resume time, so a seven-day pause genuinely resumes seven days later rather than dying when a browser tab closes. |
| Test runs before you switch anything on | A Test Run walks the whole graph with synthetic sample data and prints a step-by-step log, reporting Test Passed or Test Failed with a step count. You find out that step four has no recipient before a client does. |
| Run history with real logs | Every execution is recorded as successful, partial, or failed, with a timestamp, a step count, and console lines per step. Partial and failed runs also raise a notification, so a broken automation announces itself instead of quietly doing nothing. |
Triggers, actions, conditions, and delays
Triggers are the 13 things that can start a workflow: Proposal Accepted, Invoice Paid, Invoice Overdue, Contract Signed, Form Submitted, Project Status Change, Project Completed, Task Completed, Deliverable Approved, New Client Added, Client Inactive, Member Added, and Webhook Received. Some carry their own filters — a project status change can be narrowed to a specific target status, and an invoice paid trigger can require a minimum amount.
The events currently queued for server-side execution include a proposal being accepted, an invoice being paid, a contract being signed, a form being submitted, and a booking being created, alongside the time-based overdue and inactivity checks. These are the ones to build on if the workflow has to fire while nobody is watching.
Actions are the 17 things a workflow can do: Create Project, Create Task, Create Invoice, Create Document, Send Email, Send Notification, Send Message, Review Request, Send Follow-up, Update Status, Update Client, Add Tag, Assign Member, Archive Project, Send Webhook, AI Message, and Delay. Message and email content supports placeholders such as client name, invoice number, project name, and contract value, filled in from the event that triggered the run.
Conditions give you branching. A condition node has separate true and false outputs, so one automation can send a high-value-payment alert down one path and a normal confirmation down the other. Nine operators are available: equals, not equals, greater than, less than, greater or equal, less or equal, contains, is empty, and is not empty, against project, invoice, client, form, and task fields.
Delays sit in the Logic group with branching, and take an amount plus a unit of minutes, hours, days, or weeks. The wait is stored server-side with a resume time, so an invoice chaser that waits three days and then seven more actually behaves that way.
An external automation platform, or automation that knows your data
Generic automation platforms have to be told what a client and an invoice are, through connectors you maintain. Arpixa automations already run inside the workspace holding that data.
Connecting apps
Workflows
Self-hosted flows
Alerts
ArpixaAll of it, connectedTesting, run history, and guardrails
Automation is only useful if you trust it, and trust comes from being able to check.
Test Run executes the graph against synthetic sample data — a sample project, client, email address, invoice amount and number — and prints a step-by-step log, ending in Test Passed or Test Failed with a step count. You see the shape of a real run without touching a real client.
Execution History is a second tab beside the canvas. Each run is recorded as successful, partial, or failed, with its timestamp, the number of steps executed, and the console lines each step produced. Runs that partially or fully fail also generate a notification naming the automation, so you learn about a broken workflow from Arpixa rather than from a client.
The guardrails are deliberate. Outbound email is rate limited to three messages per address per ten minutes, which caps the damage a misconfigured loop can do to a client relationship. Webhook targets must be HTTPS, cannot carry credentials in the URL, and cannot point at localhost, cloud metadata endpoints, or private network ranges; requests time out after ten seconds. And on the Free plan the builder runs in preview mode: you can construct and explore automations, but they do not execute until you upgrade.
One honest note on scope: a public REST API with issuable, scoped keys is not available yet. Outbound webhooks from an automation action work today; the developer platform for inbound programmatic access is still in development.
How it connects to the rest of Arpixa
- A proposal being accepted can kick off a kickoff task, a notification, or a message.
- An invoice being paid or going overdue can drive thank-you notes and chaser sequences.
- A contract being signed can create the invoice and the project in one flow.
- Intake forms in Docs & Briefs can trigger a workflow on submission.
- Actions write into Projects and client records, so automation is not confined to sending messages.
- Automation runs and failures appear in the workspace activity log — see Ops Hub and Members.
Automate the follow-ups you keep forgetting
Start free in minutes, or log in to your Arpixa workspace. See pricing for plan details.
Arpixa has a real Free plan (not a trial), with Starter at $12/month, Pro at $29/month, and Advanced at $89/month. Free is preview mode with no active automation rules; Starter includes 5 rules and 1,000 webhook operations a month, Pro includes 50 rules and 10,000 webhook operations, and Advanced is unlimited. Annual billing lowers the effective monthly cost, and the pricing page is the source of truth for current plan limits.
How to build an automation
- Open Automations and start from one of the 14 prebuilt templates or a blank canvas.
- Drop in a trigger, then the actions you want, and connect them in order.
- Add a condition node where the path should split, and wire the true and false outputs.
- Insert a wait step where a follow-up needs to arrive days later rather than immediately.
- Run a Test Run with sample data and read the step log before going live.
- Enable the automation, then check the execution history to confirm real runs are succeeding.
Related reading: how to automate follow-up reminders and webhooks for agency workflows.
Frequently asked questions
How do Arpixa automations work?
You build them on a visual node canvas: a trigger, then actions, with optional condition nodes that branch on true or false and delay nodes that pause the workflow. Each automation can hold up to 50 nodes. When a matching event happens in your workspace, the automation is queued and executed on the server, walking the graph step by step and recording a run log.
Do automations run when nobody is logged in?
Yes, for the event types that are queued server-side. Events including a proposal being accepted, an invoice being paid, a contract being signed, a form being submitted, and a booking being created are written to a server queue and executed by a scheduled runner, so they fire whether or not anyone has the dashboard open. Time-based triggers such as invoice overdue and client inactive are evaluated on the same schedule. Wait steps are persisted with a resume time, so long delays survive too.
What conditions can I use?
A condition node compares a chosen field against a value. The fields cover project name, status, and id, invoice amount, number, and status, client name, email, and id, plus form title and task title. The operators are equals, not equals, greater than, less than, greater or equal, less or equal, contains, is empty, and is not empty. Numeric comparisons are done as numbers, and text comparisons are case-insensitive.
Can automations call an external service?
Yes, through the Send Webhook action, which posts a JSON payload you define to an HTTPS endpoint. It is protected against being pointed at internal infrastructure: only HTTPS is allowed, credentials in the URL are rejected, and localhost, cloud metadata hosts, and private network ranges are blocked. Requests time out after ten seconds. A public REST API with issuable keys is not available yet; it is in development.
What safeguards stop an automation misfiring at a client?
Several. Test Run lets you dry-run the whole graph against sample data first. Outbound email is rate limited to three messages per address per ten minutes, so a loop cannot spam a client. Webhook targets are validated against internal addresses. Runs that partially or fully fail raise a notification with the reason rather than failing silently. And on the Free plan automations are preview mode: you can build and explore them, but they will not execute until you upgrade.
How many automations can I run on each plan?
The Free plan is preview only with no active rules. Starter includes 5 automation rules and 1,000 webhook operations a month, Pro includes 50 rules and 10,000 webhook operations, and Advanced is unlimited on both. See the pricing page for current details.