If you've ever sat in an Actionstep implementation meeting and watched the consultant demo Steps automation and conclude "so really, everything you need is in here," you've seen the problem this post is about. Actionstep's built-in workflow engine is genuinely the best in the legal practice management market. It still cannot do about half the things UK law firms need from automation in 2026, and most of the people selling it do not distinguish between what it covers and what it does not.
I'm Robin, I run Laires Labs, a solo AI engineering studio in London. Many of my law firm builds touch Actionstep or Clio at the practice management layer. This post is the teardown I wish existed when I first started quoting UK firms running on Actionstep.
The short answer
There are three distinct things called "Actionstep automation" in 2026. First, the Steps workflow engine, the core product USP that drives matter progression and fires internal actions like sending emails, creating tasks, and generating documents. Second, Document Automation, the template-merge product that produces DOCX and PDF output from matter data. Third, custom code against the Actionstep REST API, which is the only one of the three that integrates with anything outside Actionstep. Steps and Document Automation are genuinely good products for what they do. They stop at Actionstep's data boundary. Most firm pain sits on the other side of that boundary.
The three meanings of Actionstep automation
Worth naming these precisely before anything else, because the marketing conflates them.
The Steps workflow engine is what Actionstep sells first. Every matter in Actionstep runs on an ActionType (matter template), which defines a sequence of Steps (stages) and the transitions between them. When a matter moves from one Step to another, the transition can fire actions: sending an email from a template, creating a task for a specific user, generating a document, setting a reminder, advancing the matter automatically based on elapsed time or a condition. This is what most Actionstep users have in mind when they say the firm has automation: a matter type like "Conveyancing Sale" that runs the whole sale through eight Steps with automatic document generation and task creation at each transition.
Document Automation is the template product. A firm builds its document library as templates with merge fields that pull from matter data. When a matter reaches the right Step, Actionstep generates the document automatically, ready for review. Document Automation supports conditional blocks inside templates (if this clause applies to this matter type, include it) and branching based on field values. It is a real product feature and for matter-type-specific document generation it works well.
Custom code against the Actionstep REST API is what an engineer means when they talk about automation in the Actionstep context. The REST API (documented at docs.actionstep.com) lets you read, write, query, and subscribe to changes on most Actionstep entities. Anything in the Actionstep UI is mostly reachable via the API, plus things you cannot do in the UI: cross-system integrations, bulk transformations, custom reporting, specialised conditional logic that exceeds what Step transitions can express.
The distinction matters because the most common automation pain in UK law firms (AML chase, Companies House lookups, disbursement matching, Land Registry pulls, cross-matter reporting) does not sit inside Actionstep's data boundary. Steps and Document Automation, however good, cannot help with any of it.
What the Actionstep REST API actually exposes
The REST API uses OAuth 2.0 with a per-user authorisation flow. Your custom code logs in as an Actionstep user (typically a dedicated API user) and operates with that user's role permissions. Access tokens are short-lived with refresh token rotation for long-running integrations.
The entities you will touch in most law firm builds:
/actions: matter records. Create, read, update, search. Actions carry status, Step, participants, custom fields via Data Collections./actiontypes: matter templates. Defines the Steps, default participants, data collection schemas. Read-only for most API users./participants: contact records. Clients, counterparties, expert witnesses, counsel. Linked to Actions via ActionParticipant relationships with a role./steps: workflow stages. Query which Step a matter is currently on, advance via the workflow transition endpoint./filenotes: matter file notes. Write notes from external transcription or email parsing./timeentries: billable and non-billable time. Create from external calendar or call recording sources./tasks: matter tasks. Create from external triggers, complete from external dashboards./documents: file library attached to matters. Upload, download, metadata management. Separate multipart upload flow from the standard JSON endpoints./emails: logged email history against matters. Actionstep can receive forwarded email and log it; the API allows querying and filing external email against matters./trusttransactions: trust account transactions. Read for reconciliation; write is restricted to users with trust permission./datacollections: custom field schemas per ActionType. Always pull these first to map the field codes for the specific firm.
Data Collections are the first surprise for engineers new to Actionstep. Every ActionType has its own set of custom fields organised into Data Collections. A field like "Completion Date" on a conveyancing matter might be in a collection called "Conveyancing Details" with a specific field code that differs from the same concept on a different matter type. Pull the schema per ActionType during build time rather than hardcoding field codes.
The second surprise: role-based permissions. Your API user has a role in the firm, and the role controls what it can read and write. A role can see every field on /meta but silently fail on writes where it does not have permission. Design API users with the minimum role needed and verify permissions early.
What the API does not do
The honest gap list, from builds where this has come up.
Steps workflow definitions are UI-only. You cannot modify an ActionType's Step definitions or transition rules via the REST API. Workflow design is an admin-UI task. Your custom code can advance a matter through Steps, read its current Step, and trigger the transition endpoint, but it cannot say "add a new Step at position 5 across all conveyancing matter types." That stays in Actionstep's admin.
Webhooks are event-scoped. Actionstep supports webhooks for a defined list of events (matter created, matter updated, Step advanced, document uploaded, etc.). Anything outside the supported event list has to be polled. For real-time-ish reactions, the webhook list covers most common cases; for rarer trigger conditions, you will be scheduling poll jobs.
Bulk operations are rate-limited. The API handles thousands of requests per hour comfortably, but a migration touching 50,000 records needs batching and deliberate backoff. A naive loop will hit rate limits.
The billing engine is partial. Time entries, disbursements, and invoice line items are accessible, but the actual bill calculation logic (how time entries aggregate into an invoice, how disbursements roll up, how trust offsets apply) is internal. Reading bills is possible; re-computing them externally is not.
Steps transitions run Actionstep's internal actions, not external ones. When a Step transition fires, it can send an email, create a task, or generate a document inside Actionstep. It cannot call your AML provider, your Companies House integration, or your finance system. To involve an external system on a Step transition, you listen for the webhook in custom code and fire the external call from there.
Document Automation templates are firm-specific and UI-built. Custom templates are created in Actionstep's template editor. You cannot upload or modify templates programmatically at scale. If your firm wants 30 tailored engagement letters generated in the next week as a one-off, custom LLM-drafted generation (via the API, writing to /documents) beats trying to build 30 templates.
What you can actually build
The patterns that actually ship in UK law firm clients on Actionstep. Each of these is custom code against the REST API, not something Steps or Document Automation covers.
AML and client onboarding integration. Webhook on matter create, fan out to the firm's AML provider's API (Smartsearch, Veriphy, AMLCC, Credas), write AML status back to the Action, advance the Step when AML clears, escalate to a partner when AML flags. Build time: 2-3 weeks. The work is in the provider API and the escalation logic, not in Actionstep.
Companies House and Land Registry pulls on matter intake. Webhook on matter create where the matter type is commercial or property, lookup the counterparty company, pull directors and charges from Companies House, pull title register from Land Registry, attach as file notes or documents on the matter. Build time: 2-3 weeks. The Actionstep write-back is straightforward; the external API handling is where the time goes.
Cross-system disbursement matching. Watch the firm's shared inbox for supplier emails (search providers, experts, court fees), parse matter reference from the subject or body, match to the Actionstep matter, create a disbursement entry with the right cost code. Build time: 2-4 weeks. Email parsing is the interesting part.
Bulk document generation beyond Document Automation. Cases where Document Automation's template library is too narrow: a firm handling 40 unique engagement letters per week needs matter-specific paragraph drafting. Custom code reads matter data via API, calls Claude or GPT for the matter-specific sections, assembles the full document using the firm's house template, uploads via /documents. Build time: 2-3 weeks. The LLM prompt work is most of the job.
Cross-matter partner dashboards. A custom UI that aggregates data from /actions, /timeentries, /tasks across all matters, shows fee-earner utilisation, matter ageing, partner exposure, upcoming deadlines. Actionstep's reporting is serviceable for standard views; firm-specific dashboards need custom. Build time: 4-6 weeks. Mostly UI work.
Call recording to file note pipeline. Adviser records a client call (Otter, Fathom, or a softphone integration), transcription runs, LLM summarises to the firm's file note style, write-back to /filenotes on the right matter. Build time: 2-3 weeks. The transcription is commoditised; the summarisation style and the matter-matching are the work.
None of these are Steps workflow jobs. None of them are Document Automation jobs. None of them are Zapier jobs at real firm scale (Zapier hits task limits and breaks on Actionstep's rate limits fast). All of them are two to six weeks of custom code running on your own infrastructure.
When Steps and Document Automation is the right answer
Despite the limits, the product is genuinely capable for what it was designed for.
Matter progression workflows. A conveyancing matter running through its Steps with emails, tasks, and documents firing at each transition. Actionstep's Steps engine handles this elegantly and you should not try to replicate it in custom code.
Template-driven document generation. Firm-specific engagement letters, standard form NDAs, standard court forms, standard client letters. If the document is template-able with merge fields and the firm uses it frequently, Document Automation is the right answer.
Internal task routing. Deadline-driven reminders, role-based task allocation, escalation when a Step stalls. Steps handles this without custom code.
Scheduled client communications. Periodic review emails, anniversary letters, status-change notifications. Steps + email templates does this.
What Actionstep's product does not do: integrate with anything outside the Actionstep database. The moment the workflow needs to talk to an external API that is not email, you have outgrown the built-in tools.
When Zapier or n8n is the right answer
For simple connect-app-to-app workflows where one Actionstep event triggers one action in one external tool, with no fan-out and no conditional branching. New matter created, post a Slack notification. Document uploaded to Actionstep, copy to a shared Dropbox folder.
Zapier has an Actionstep integration of variable completeness, and n8n can drive the API directly. The constraints: rate-limited by Zapier or n8n's own task quota, no real fan-out logic, hard to handle Actionstep's API errors gracefully, hard to version-control or audit. Fine for one-off connectors. Painful for anything you want to maintain seriously.
When custom code is the right answer
When the workflow involves any of these:
- Two or more external systems beyond Actionstep (an AML provider, Companies House, a finance system)
- Conditional logic that branches more than a Step transition can express
- Bulk operations against Actionstep data
- An LLM call as part of the decision logic (drafting, summarising, extracting)
- A custom dashboard that anyone in the firm interacts with
- Compliance evidence the firm's PI insurer or the SRA will want to audit
The threshold I use: if you are describing a workflow and find yourself saying "and then if X, but unless Y, except when Z" more than once, you are past Steps and Zapier and into custom code. The build vs buy framework sits behind this rule of thumb.
What it costs
Actionstep itself: roughly £80-£130 per user per month in the UK for the standard Practice or Practice Plus tiers, with the top tiers adding trust accounting and advanced reporting. Steps workflow and Document Automation are bundled, not add-ons.
Zapier or n8n setup by a reseller: £800-£3,000 per workflow one-off plus £40-£200 per month for the workflow platform subscription. Reasonable for one or two simple connectors.
Custom build against the REST API: £12,500 upwards one-off, plus £100-£300 per month for hosting and LLM API costs if applicable. Floor exists because a real build needs scoping, build, error handling, deployment, documentation, and post-launch support. Smaller jobs are better served by the reseller tier or by leaning harder on Steps.
The custom build path's economic argument for Actionstep firms: Steps and Document Automation are already paid for in the subscription, so custom code only needs to justify the work it does outside Actionstep's boundary. That makes the incremental build cost a cleaner decision than in products where the built-in automation is a separate add-on.
A note on the Actionstep Marketplace
Actionstep maintains a Marketplace of integration partners. For mainstream tools (DocuSign, Xero, QuickBooks, Clio Grow-equivalents, court form vendors), the Marketplace partner is usually the right answer. For anything firm-specific, the Marketplace does not help and a custom build against the REST API is the route.
Who owns Actionstep
Background context that occasionally matters at procurement. Actionstep was founded in Auckland, New Zealand, and acquired by The Riverside Company (a US private equity firm) in 2021. It operates globally with formal UK operations (Actionstep Operations UK Limited is registered at Companies House). The roadmap direction is American-PE-owned but with strong AU/NZ and UK roots. For a small UK firm evaluating ownership risk, it sits somewhere between a founder-led vendor and a Silicon-Valley-scale-up: safer than the former, less consolidation-risk than the latter.
Book a call
If you are running a UK law firm on Actionstep and trying to work out whether your next workflow problem needs Steps, a Marketplace integration, or a custom build, that is the call to book. Twenty minutes, no pitch. Tell me the workflow and I will tell you which of the three is right and what each would cost you. You walk away with a one-line answer per option, and a scoped build estimate if custom is the right path.
Don't book if your problem is "fire a templated email when a matter moves to a new Step", Steps handles that and you do not need an engineer. Don't book if your problem is "post a Slack notification on new matter", buy a Zapier subscription.
Book a 20-minute call or read the full UK law firm buyer's guide if you are earlier in the decision.
Thinking about a system like this?
20-minute call, no slides. We'll map it against your stack and I'll tell you if it's worth building.
Book a callQuestions buyers actually ask
Actionstep is a practice management system for law firms, most popular with mid-market firms of 10-100 fee earners. It handles matter management, document storage, time recording, trust accounting, and billing. Its core differentiator is the Steps workflow engine, which lets a firm define a multi-stage process per matter type and drive the matter through it automatically. UK uptake is particularly strong in conveyancing, employment, and private client practices.
Robin Laires
Ten years software engineering, former tech lead at Jellyfish, one of the UK's largest independent digital agencies. Now founder of Laires Labs, a London studio building bespoke AI systems for UK firms: ads ops, sales intelligence, intake routing, research pipelines.