Looking for a setting rather than advice? Run limits, versions, timeouts, Paused versus Off and the other reference details live in LedgerUp Answers. This guide covers the decisions; that covers the settings.
Before you start
What is an automation?
A saved workflow that starts on its own (either when something happens in a connected system, or on a schedule) and then hands the work to Ari with instructions you wrote. Ari investigates using its tools, and then either takes action, asks you to approve a plan, posts a summary in Slack, or finishes silently.What are the pieces?
Every automation is a left-to-right flow of nodes:What does the simplest automation look like?
Trigger → Agent Step → Post in Slack, or Silent Completion in place of the Slack step. That’s a complete, runnable automation. Everything else (decisions, extra agent steps, approval routing) layers on top of that spine. Build the spine first.Stage 1, Choose a trigger
Deciding what makes this run, and how often.Should I use an event trigger or a schedule?
An event trigger when there’s a specific moment you’re reacting to, a contract was approved, a Stripe invoice was paid or voided, a deal changed stage, an email arrived. A schedule when you’re reacting to the state of the system rather than a single moment, and there’s no clean event for it. The classic case is “process every overdue invoice”. Nothing actually happens at the moment an invoice becomes overdue, so a daily or weekly cadence fits better.Should I trigger on a LedgerUp event or a connected integration’s event?
Often the same real-world thing exists in both places. A contract is signed in DocuSign and approved in LedgerUp, and either can trigger an automation. If you’re using contract-to-cash, use the LedgerUp event. LedgerUp already screens your document source (DocuSign, PandaDoc, wherever contracts live) and surfaces a contract for you to approve. That approval is the point where the contract has been reviewed and is real. Triggering on the raw signature event fires earlier and skips your own review. Use the integration event only when you aren’t using contract-to-cash, or when you deliberately want to act before review.My event fires constantly. Is that a problem?
It’s manageable, but worth handling deliberately. Events firing more than roughly ten times a day are good candidates for a Decision / Filter node immediately after the trigger, so irrelevant events end the run before Ari does any real work. That keeps run history readable and the workflow fast.Can a schedule stop on its own?
Yes. A schedule can end never, on a specific date, after a set number of runs, or a combination. This matters most for recurring check-ins, following up daily on an unpaid invoice, or weekly on an unsigned contract. The end condition stops the schedule once the task is done, instead of letting it run indefinitely.Stage 2. Write the Agent Step
Telling Ari what the job actually is. This is where quality is won or lost.What makes a good Agent Step instruction?
Give Ari the same context a human would need to do the job. That’s the single biggest lever on quality.- Goal-oriented beats step-by-step. Say what outcome you want, not a rigid click-by-click script.
- Specificity is optional, but it buys consistency. Vague instructions still work. They just produce more variation run to run. Add detail anywhere you’d be annoyed by that variation.
Can I chain multiple Agent Steps?
Yes. Connect a second Agent Step after the first and it runs as a follow-up in the same conversation, so it has the first step’s context. Use this when a job has genuinely distinct phases (gather, then draft; reconcile, then escalate) rather than merging everything into one instruction block.Where does Ari’s output go?
Wherever the next node says. Connect the Agent Step to Post in Slack and Ari posts; connect it to Silent Completion and Ari finishes quietly. Connect both and Ari decides per run. Instruct it explicitly, “post only if you found an exception, otherwise finish silently.” This is how you avoid a channel full of “nothing to report.”What are Tools, and when should I change them?
Tools are the actions Ari is allowed to take in that step. By default an Agent Step uses your agent profile’s tools, which include querying and sending an approval plan. That default combination (a query tool plus an approval tool) covers roughly 99% of what an automation needs. Ari can look anything up, and anything it wants to change comes back to you as an approval. Two reasons to customize:- The step needs an action the default profile doesn’t cover. To have Ari create a customer or an invoice, you add that specific tool. The tool is what makes the action possible; it still goes through approval.
- A specific tool fetches something niche the step needs, or performs an action you’ve decided to trust. If a tool obviously matches the job, adding it is fine.
What is Knowledge on an Agent Step?
Saved instructions you’ve written once and want to reuse. Attach them to a step instead of pasting the same paragraph of policy into every automation.Can I choose the model for a step?
There’s a Model dropdown, but leave it on Default model unless LedgerUp has advised otherwise for your setup.Stage 3. Add decisions and filters
Deciding when the automation should not proceed, and where else it could go.What is a Decision node, and when do I need one?
A Decision node picks exactly one route out of the ones you’ve defined. It’s an agent in its own right. It can search Stripe, Salesforce and your other connected systems to work out which route applies. Three patterns cover almost all uses:- End the run early. By far the most common. You only want the automation to proceed in certain cases, brand-new customers only, non-enterprise accounts only, emails actually about billing. Everything else stops here.
- Route to different instructions. If your trigger covers several distinct scenarios, split them. A single “email received” trigger might fan out to five Agent Steps, one per email category, each tailored.
- Flag for human attention. Add a route whose job is “this needs a person,” connected to an Agent Step that escalates.
Why use a Decision node instead of writing the rules into one Agent Step?
Observability. With a Decision node you can open a run and see exactly which route it took and why the conditions were met. If the output isn’t what you wanted, you can trace it to a specific branch and fix that branch’s instructions. With one large Agent Step containing every scenario, it’s hard to tell which path Ari took. Which makes it hard to know what to change, or how to tailor instructions per scenario.How many routes can a Decision node have, and do I need a “stop” route?
As many routes as you need. Use Add route to add more. A single automation can fan out into many procedures depending on the type of event. You don’t need a stop route. Two routes with one of them stopping is just the default shape, not a rule. You can rename the stop route to something meaningful, or remove it entirely and have every route continue somewhere.What’s the difference between Agent-selected and Deterministic?
Agent-selected (the default). You write instructions and an agent picks the route. Flexible, handles fuzzy judgment, and can look things up. Deterministic: fixed, coded rules. No judgment, no lookups. The route is decided by matching against the event data itself: a specific sender address, an invoice sequence, a customer name pattern. Deterministic filters are high value because they cut noise before Ari ever sees the event, which improves the quality of the input Ari does get. Common uses: ignore all email from consumer addresses, process one specific customer only, act only on mail from a known billing address. Runs stopped this way appear in run history under Filtered out deterministically and don’t consume a full run.I’m not technical. Should I use deterministic filters?
Yes, but don’t hand-write them. Deterministic filters use a pattern-matching syntax that’s fiddly even if you are technical. Describe the rule you want to Ari in plain language and ask it to configure the filter. This is one of the clearest cases where asking Ari beats building by hand.What is Route guidance in Advanced, and how is it different from Instructions?
Functionally the same thing: extra text the decision agent reads. It exists as a separate box to prompt you to think route by route (“what specifically should make the agent pick this one?”) and more detail there produces better decisions. If you’d rather write everything in the main Instructions box, that works identically.Stage 4, Route approvals
Deciding who signs off, and where the request lands.How does an approval work?
When an Agent Step wants to do something that needs human sign-off, Ari sends the plan for approval and the request lands in an approval inbox for someone to approve or reject. Nothing is executed until it’s approved.How do I set up an approval inbox?
1
Open Automation Settings
The button at the top right of the automation, not Settings in the left sidebar, which is company settings.
2
Approval inboxes → New approval inbox
Name it after the work, for example “Contract Triage.”
3
Set the defaults
Under Approval defaults, set the approval inbox and optionally a default assignee.
4
Save the automation
What is Thread behavior on the Post in Slack node?
It controls how the post is placed in Slack:Stage 5. Save it and check it’s finished
Distinguishing “it saved” from “it does the job.”How do I know my automation is finished?
Two different questions, with different answers. Is it valid? If it saves, yes. Validation runs at save: every node needs its outgoing connections, and you can’t save an automation whose end node has been deleted. A successful save means it can run. Is it complete? That’s on you, and this is the trap. After saving, trace each route with your finger and ask “and then what?” Look for the End label to confirm where the flow actually terminates.How do I try it out without touching anything real?
There’s no simulation mode, so build in two passes.1
First pass: routing only
Build the trigger and decisions without the action steps, save it, and let a real event fire it. Read run history to see which route it chose. Nothing is touched because nothing is attached yet.
2
Second pass: attach the actions
Once the routing looks right. This matters most for anything that emails a customer or writes to your billing system.
Stage 6. Turn it on and watch it
Knowing whether it’s doing what you meant.What should I check once it’s live?
Set it On, then check back on four things:- Run history → Runs: what actually happened, and which route each run took.
- Run history → Filtered out deterministically: events your fixed rules stopped before any agent work. These don’t count against your limits.
- Run history → Queue: anything waiting. A growing backlog usually means the trigger is noisier than you expected.
- Edit history: every save is a version, so you can see what changed and when.
How do I stop it safely while I make changes?
Pause it. Paused holds processing but keeps collecting events, so nothing is missed. Turn it back On and it works through the backlog with your new logic applied. Use Off only when you genuinely don’t want the automation running at all. Off doesn’t receive events, and anything that happens while it’s off is gone.Build it yourself, or ask Ari?
Worth deciding once, rather than per automation.Ari can build automations. Should I just have Ari do it?
Build your first few yourself, then let Ari handle changes. Ari is genuinely good at creating automations and will go with whatever you describe. That’s exactly why building the first ones by hand pays off:- You develop intuition for what makes a good automation, which makes you much better at describing what you want afterwards. Ari supplies capability; your job is judgment, and judgment comes from having done it once.
- You know what’s actually in there, so when a run does something surprising you know where to look.
- You’re invested in it. It’s your automation, and Ari does the last 20%.
So when should I ask Ari?
- Deterministic filters and any rigid, hard-coded rule. These are difficult to configure by hand even if you’re technical. Describe the rule in plain English and let Ari write it.
- Updates to an existing automation once you understand its shape, adding a route, tightening instructions, changing a schedule.
- Anything you can describe but can’t find in the UI. Ari can create, update and change automations.
Worked example
One automation, built as a thought process. The clicks change; the questions don’t.The goal, in one sentence: when a contract is approved in LedgerUp, have Ari draft an email to the billing contact asking for a PO number, the correct billing email address, and any vendor portal preferences.
Step 1. What starts this?
Is there a specific moment, or am I checking a state? There’s a clear moment: a contract gets approved. So this is an event trigger, not a schedule. Had the goal been “chase every customer who never sent us a PO,” there’d be no single moment and it would need a weekly schedule instead. Which event, though? The contract exists in two places, signed in DocuSign, approved in LedgerUp. Both can trigger. Choose contract approved in LedgerUp, because this setup uses contract-to-cash: LedgerUp already screens the document source and surfaces a contract for a human to approve. That approval is the moment the contract is real and reviewed. The DocuSign signature would fire earlier and skip your own review.Step 2, Should this run every single time?
Does this make sense for every contract that gets approved? No. For an existing customer you already know how to invoice them. You have their PO process, their billing contact, their portal. Emailing to ask again is noise, and worse, it’s noise sent to a customer. This is the most common reason to add a Decision node: stop the run early for cases that shouldn’t be processed at all. So: a Decision node immediately after the trigger. Agent-selected or deterministic? “Is this a brand-new customer?” is a judgment call that requires looking something up, and a decision node can look things up, because it’s an agent with access to Stripe, Salesforce and the rest. So agent-selected, with instructions describing what counts as new. Name the routes after outcomes. “Stop” is much less useful than “Existing customer, no action.” In three weeks, run history is the only thing telling you why a contract was skipped.Step 3, What should Ari actually do?
What would I have to tell a new hire to get this right? That framing is the whole trick. Write down what you’d say out loud: who to email (the billing contact on the contract), what to ask for (PO number, correct billing email, vendor portal preferences), tone and length if it matters, and what to do when the billing contact is missing or ambiguous. Does Ari need special tools for this? No. Leave it on profile defaults. Query plus send-for-approval is right for roughly 99% of automations. You’d only customize if you wanted Ari to send the email without asking you first, which means deliberately removing the human checkpoint. For a first draft going to a live customer, you want the checkpoint.Step 4. Where does the result go?
Who needs to see this, and where do they approve it? Connect the Agent Step to Post in Slack if your team lives in Slack. But the approval is a separate thing: the drafted email goes to an approval inbox for someone to approve before it sends. You don’t need Slack for that at all. In Automation Settings: create an approval inbox named “Contract Triage,” set it as the approval default, add an assignee if one person owns the queue, and save. Approvals from this automation now land in their own queue instead of a general pile.Step 5, Is it finished?
Is it valid? If it saves, yes. Is it complete? That’s the trap. You could save this cleanly with the “new customer” route leading nowhere, completely valid. Approve a contract and it would run, show you which decision was made, and do nothing. So after saving, trace each route and ask “and then what?”Step 6. Turn it on and watch
Save, set it On, and check run history for what happened and which route each run took. A growing queue usually means the trigger is noisier than you expected. Pause while you’re rewriting instructions; turn off only when you don’t want it at all.The shape you end up with
Pre-launch checklist
Run through this before you set an automation On for the first time.1
Can you state the goal in one sentence?
If not, the instructions won’t be clear enough either.
2
Does every route end somewhere?
Trace each one and look for the End label. A route with nothing attached is valid and does nothing.
3
Are routes named after outcomes?
“Existing customer, no action,” not “Route 2.”
4
Should this really run every time?
If not, add a Decision node right after the trigger to stop the cases that shouldn’t proceed.
5
Did you add any write tools?
If so, confirm you meant to remove the human checkpoint for that action.
6
Do you know where approvals land?
Set the approval inbox rather than letting requests pile into a general queue.
7
Did you run the routing first, without the actions attached?
Especially if this emails a customer or writes to your billing system.