Automations: Complete Guide

Automations put your studio on autopilot. Instead of remembering to chase a vendor, follow up on an estimate, or create the same task every time a project starts, you build a simple rule once — "when this happens, do that" — and Workroom runs it for you, forever, in the background.

What Automations can do

A few of the things studios use Automations for every day:

• Client follow-ups — when an estimate is sent, wait 3 days, and if the client hasn't responded, email a gentle nudge.

• Onboarding — when a new project is created, create a standard checklist of tasks and assign them to the right people.

• Procurement safety nets — when a product has been "Ordered" for weeks with no shipping update, flag it before it becomes a delivery surprise.

• Budget guardrails — when change orders push a project past a threshold, notify the lead designer.

• Lead handling — when a lead comes in, wait a few minutes, send a welcome email, then create a follow-up task assigned to a teammate.

If you can describe it as "when X, do Y (and maybe wait, and maybe only if Z)", you can build it.

Getting access

Automations is a premium add-on. If you don't see it in your sidebar, it hasn't been enabled for your workspace yet — reach out to the Workroom team to turn it on. Once enabled, you'll find Automations in the sidebar under the Management group.

The four building blocks

Every automation is a flow made of connected nodes:

A run is one execution — every time the trigger fires, a new run is created, and you can open any run to see exactly what happened, step by step. You wire the flow by dragging from one node's output to the next node's input.

Build your first automation

Let's build: "When a lead is created, wait 3 minutes, send a welcome email, wait 2 days, then create and assign a follow-up task."

1. Go to Automations → New automation.

2. You'll be offered the template library first. To build from scratch, close it or choose a blank flow.

3. Add the trigger: pick Lead created.

4. Add a Delay node → 3 minutes.

5. Add a Send email action → choose the recipient (the lead), write a subject and body, and insert dynamic fields (like the lead's name) to personalize it.

6. Add another Delay → 2 days.

7. Add a Create task action → give the task a name (e.g. "Follow up with new lead") and choose who to assign it to.

8. Name your automation at the top and set it Active.

9. Save.

Tip: Build in a draft/inactive status first, test it, then flip it to Active once you're happy.

Starting from a template

Clicking New automation opens a template library with a live preview of each one, organized into categories (client communication, procurement, budgets, onboarding, cascades, and more). Browse a category, hover to preview the flow, click to load it, then edit anything — wait times, recipients, copy. Templates are the fastest way to learn the patterns.

Triggers reference

Standard event triggers fire the moment something happens: Lead created, Project created, Estimate approved / sent, Invoice paid / sent, Purchase order status changes (e.g. an item received), and more across the document and project lifecycle.

Smart procurement triggers watch your data continuously and fire when something should have happened but didn't:

• Product status unchanged for X days — pick a status (e.g. "Ordered") and a number of days; catches stalled orders.

• Silent shipment / lead-time drift — catches items whose expected delivery has quietly slipped.

• Claim-window countdown — reminds you before a shipping-damage/freight claim window closes.

• Install confidence dropped — every project carries a live Install Confidence score; fires when it falls, so you know delivery risk is rising weeks ahead.

• Change-order threshold — fires when change orders push a project past a percentage you set.

• Spec-to-allowance drift — fires when selected specs drift beyond the client's allowance.

How the smart triggers run: event triggers fire instantly; the "watch" triggers are evaluated on a schedule (about hourly). So "status unchanged for 14 days" fires shortly after the 14-day mark, not to the exact second — which is exactly what you want.

Conditions & branching

A condition checks a value and decides what happens next — "only continue if the budget is over $50,000" or "only email if no response has been logged." When a condition has two outputs (met / not met), you can build branches — one path when it passes, another when it fails. Condition dropdowns are populated from your own workspace data (statuses, users, categories), so you always pick from real values.

Delays & waiting

A Delay node pauses the flow — for follow-up timing, staggering steps, or spacing out reminders so clients aren't spammed. Delays can be minutes, hours, or days. A run that's mid-delay shows as waiting and resumes automatically.

Actions reference

Send email

• Choose a recipient: the client, the record owner, a specific teammate, project stakeholders, or a custom address. Add CC/BCC.

• Write a rich-text subject and body, and attach files.

• Insert dynamic fields to personalize.

• Emails send through your studio's own email, so they come from you.

Create task

• Always give the task a name — a blank name makes it hard to find later.

• Assign by name — type the teammate's name and Workroom resolves it to the right person.

• Optionally delay creation (e.g. "2 days after the trigger").

Assign / update task

• Later steps can reference the task an earlier step created (e.g. create a task, then update or reassign it) — Workroom threads the created task through the run.

Sending email that actually lands

• Set up your company email first. If your studio hasn't configured a sending address, Send email actions can't deliver. Configure it in your workspace email/finance settings.

• The recipient is chosen once, clearly — you won't see a contradictory "to" field inside the editor, which prevents emails going to the wrong place.

• "Record owner" resolves to that person's profile email address.

• "My connected mailbox" as a send option is coming soon; use the company sender for now.

The "Needs Review" inbox

Some automations are set up to draft an action and hold it for your approval rather than acting on their own. Those land in the Needs Review inbox, where you can see the pre-drafted email or task, edit it, and approve or dismiss it. This is the safest way to automate client-facing communication — the automation drafts; a human presses go.

Smart procurement automations

Procurement is where automations save the most money. Recommended flows:

• Stalled-order watch: Product status unchanged for 14 days (status: Ordered) → notify the buyer + create a "Chase vendor" task.

• Delivery-risk alert: Install confidence dropped → email the lead designer with the project name.

• Claim protection: Claim-window countdown → email a reminder before the window closes.

• Budget guardrail: Change-order threshold exceeded → notify the project lead.

Vendor reliability learning

Workroom quietly builds a reliability scorecard for your vendors from how their orders actually perform against quoted dates. Over time it learns each vendor's typical slippage and can automatically apply a learned lead-time buffer when you create a PO, so your schedules reflect reality instead of optimism. It improves as your order history grows — no per-PO setup.

Build automations by chatting with Walter

Describe an automation in plain English to Walter and have it draft the flow:

"When a lead is created, wait 3 minutes, send a welcome email, wait 2 days, then create and assign a follow-up task to Andrea."

Walter builds a draft with the trigger, delays, email, and a named task assigned to the teammate you mentioned (it resolves names like "Andrea" to the actual member). Review, adjust, activate.

Tip: Be specific — "create a task called Follow up and assign it to Andrea" produces a cleaner result than "make a task."

Managing your automations

From the list you can search by name, filter by status (active/inactive), duplicate an automation to build a variant, trash one (with a confirmation) and restore it later, and open any run to see the step-by-step log.

Tips & best practices

• Start inactive, test, then activate. Never point a brand-new client-facing automation at live data on day one.

• Use "Needs Review" for anything client-facing.

• Name everything clearly — the automation, and every task it creates.

• Add conditions to prevent noise ("only if no response logged", "only over $X").

• Space out reminders with delays.

• One job per automation — small, single-purpose flows are far easier to debug.

• Check the run log after the first real fire.

• Duplicate, don't rebuild.

Troubleshooting

My automation didn't fire. Is it Active? Does the trigger actually match what happened ("Estimate approved" ≠ "sent")? Do your conditions allow it? Open a run to see where it stopped. For "watch" triggers, give it up to an hour.

The email didn't send. Confirm your company email/sender is configured. Open the run and read the step log — failed email steps surface the reason. Check the recipient resolved to a real address.

The task had no name / wasn't assigned. Always set a task name. Assign by the teammate's name; if it doesn't match a member, the task is created unassigned — check spelling against your Team list.

A run is stuck on "running." Open it — long delays show as waiting (normal). A genuinely errored step is logged; fix the node, re-save, and new triggers use the corrected flow.

The wrong recipient got the email. Re-open the Send email node and confirm the recipient selection (not a typed label).

How do I test without waiting for a real event? Build with short delays first (minutes), trigger the event on a test record, watch the run log, then increase delays and point it at live data.

I don't see Automations in my sidebar. It's a premium add-on — contact the Workroom team.

FAQ

Can one automation have multiple actions? Yes — chain as many actions, delays, and conditions as you need. Can it email the client and create a task? Yes — add both actions. Do automations run while I'm logged out? Yes — they run on Workroom's servers. Will editing affect runs already in progress? New triggers use the latest saved version; in-flight runs finish on the version they started with. Is there a limit? Build as many as you need — keep them small and single-purpose.