> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ledgerup.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Automations
> Recurring work Ari handles for you, outside of collections campaigns. Set up once, then it runs on every trigger.
export const AriMention = () => @Ari;
export const SlackMessage = ({children, name = "Bailey", initials = "B", color = "#611f69", avatar = "/images/bailey-avatar.png", app = false, time = "2:47 PM"}) =>
{avatar ? : initials}
{name}
{app ? APP : null}
{time}
{children}
;
Building your first one? [Building an Automation](/ari/guides/building-an-automation) walks through the decisions in the order you make them.
A procedure you want Ari to run every time a particular trigger fires. A trigger is the event that starts it: an invoice being paid, a deal moving to closed won, an email arriving.
The point is that setup happens once. You configure it the way your team works, then it runs the same way on every trigger and surfaces only the exceptions that need a person.
**You may see these called Ari tasks.** That was the previous name and both still appear in places. They are the same thing.
Automations are separate from [collections campaigns](/ari/answers/collections), which are purpose-built for chasing unpaid invoices and configured under Collections.
Three routes, all equivalent:
* Apply a template
* Click **+ Create Automation** and build it yourself
* Ask Ari to build it, from Slack or from the browser
The builder is visual, so triggers and actions read as a flow you can change. Decision nodes let one automation branch on a condition, a new customer gets a welcome email, an existing customer gets their setup reviewed.
Every automation keeps a full run history plus Ari's thinking on each run, so you can see why it did what it did.
Events from your connected systems, a schedule, or a manual run.
The event catalog covers **LedgerUp** (bank transactions, inbound customer email, contract opt-outs and renewals), **Stripe**, **Chargebee**, **QuickBooks**, **HubSpot**, **Salesforce**, **Attio**, **DocuSign**, **PandaDoc**, Google Drive and banking/reconciliation events. Your company can also define custom events.
The trigger editor only shows sources for systems you've actually connected, so the list you see is shorter than the list above.
No event fires at the moment an invoice *becomes* overdue. Nothing happens in the source system. That case wants a schedule that checks state, not an event trigger.
Common starting points:
| When this happens | Ari does this |
| ---------------------------------------------- | -------------------------------------------------------------------------------------- |
| A Stripe invoice goes `past_due` | Sends a reminder email to the billing contact, posts a summary in `#collections` |
| A customer's payment fails | Looks up their payment history and notifies the team with recommended next steps |
| A Salesforce opportunity moves to `Closed Won` | Looks up billing details, drafts an invoice for the deal amount, posts it for approval |
| A contract renewal is 30 days out | Posts the contract terms, billing status and outstanding balance to `#ar-team` |
| A customer emails asking for your W-9 | Verifies they're a customer, then posts an approval to send it |
You can build any of these by describing it to Ari:
create an automation: when a Stripe invoice becomes overdue, send a payment reminder email and notify #collections
Ari confirms the trigger, the action, and whether it should run automatically or wait for approval. All of it is editable afterwards.
Yes. Ari will not send, create, change, or delete anything until a person has approved it. Write access to a connected system is capability, not permission to skip that step.
What you choose is *when* the approval happens:
| Mode | Behaviour | Best for |
| --------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
| **Approval required** | Ari posts a plan and waits for you to approve, every run | Anything that changes data or contacts a customer |
| **Auto-execute** | You approve the behaviour once, when you configure the automation, and Ari then runs it on every trigger | Work you have watched enough times to trust |
Granting a write tool to an Agent Step lets Ari carry out that kind of action. It does not remove the approval.
Start every new automation in approval mode. Review a few real runs, then switch to auto-execute only if the behaviour is what you expected, and think twice for any step that emails a customer.
Almost always because two automations share one trigger, the same event is starting both of them. Automations on the same trigger **run independently and at the same time, and cannot see each other**, so one event produces two runs. That's how duplicate or conflicting work appears.
The real fix is consolidation: put work that shares a trigger into a single automation.
Silent completion won't help. It hides the Slack message but doesn't stop the run, so five automations on one trigger means five runs regardless of how many of them post.
If the duplication is one automation overlapping with *itself* (a new run starting before the last one finished) that's a different problem with a different fix. Set **Maximum concurrent runs** to 1 in Automation Settings to force strictly one-at-a-time processing.
Yes. Ari can keep a running file as its own record and read it back the next time the automation fires.
A common use: alert a colleague about an overdue invoice, but don't pester them. The automation runs daily and Ari tracks which invoices it has already raised and how many times, so it only follows up if the same invoice is still outstanding several days later.
This is the general approach for anything that looks impossible to express in a single automation's settings.
In **Knowledge → Instructions**. Anything there is always in front of Ari (in chat, in automations and in collections work alike) and Ari ignores it when it isn't relevant.
If your team keeps re-attaching the same spreadsheet or restating the same rule in chat, that's the signal to move it into Knowledge. It's both faster and more reliable than asking Ari to go and find the context each time.
A delay holds an automation for a set period after its trigger fires, before Ari does the work. It's close to exact, but not to the second: delays drift by roughly ten seconds either way, runs cannot see one another, and the order of two runs is not guaranteed.
Set a delay only when you have a specific reason to. Integration webhooks already wait for the underlying record to be written, so a delay added "to be safe" usually achieves nothing.
: initials}