Actionstep MCP Server
release notes.

Your firm’s server now accepts more AI tools. Until now it recognised Claude and nothing else. It now also recognises ChatGPT, Notion, Microsoft Teams and Copilot Studio out of the box, and another tool your firm wants to use can be added on request. Everything about how it works is unchanged — each person still signs in with their own Actionstep account, still sees only what they could see in Actionstep themselves, and every action is still recorded under their name.

A connection from anything other than Claude was refused outright. A firm connecting Notion was turned away over the address it was being sent back to after sign-in, with nothing on either side to explain why. That address is now recognised, along with the ones the other tools use.

Sign-in now works the way each tool expects it to. AI tools differ in how they present their credentials when they connect. The server previously accepted only one of those ways — the one Claude uses — so a tool doing it the other, equally standard way could not get in at all. Both are now accepted, and a tool that sends details that disagree with each other is refused rather than let through on a guess.

Every sign-in now states which server issued it. When a tool is handed back to your firm’s server after signing in to Actionstep, the response now names the server it came from, so the tool can confirm it is talking to the one it asked for and not somewhere else. Some tools require this before they will complete a connection at all.

Tools that look up the connection details for themselves now find them. Rather than being told how to connect, some AI tools work it out by reading a standard description the server publishes. That description now covers everything those tools look for, and a request that arrives without a valid sign-in points them straight to it instead of simply being turned away.

No reconnect is needed this time. The number of actions is unchanged at 71 and nothing about what they accept has changed, so every existing connection keeps working exactly as it is. This release is only about which tools are allowed to connect in the first place.

Asking for a matter’s emails showed you the oldest ones. On a matter holding hundreds of emails the list always started at the very beginning, so recent correspondence simply never appeared — on one long-running file, asking for the most recent 200 returned emails from December 2022 to April 2023 and nothing after. Emails now come back newest first, and you can work back through the whole matter a page at a time. Each answer says which page you are looking at and how many emails the matter holds in total, so you can see at a glance whether there is more behind it.

Search a matter’s emails instead of scrolling through them. You can now narrow to a word or phrase in the subject line, to emails in or out, to a date range, or any combination of the three. “Every email where we asked the client for documents” becomes one question rather than an afternoon. Whichever filters you used are printed above the results, so what you were shown is never in doubt.

Many more emails in a single answer. Full detail on every email — recipients and the opening lines of the message — is what limited how many could be returned at once. You can now ask for a one-line-per-email summary instead: date, direction, sender and subject. It is the right shape for sweeping a long matter for the one email you are after, and full detail is still there when you want to read.

Matter summaries now show genuinely recent emails. The RECENT EMAILS section of a matter summary was drawing from the oldest emails on file and showing the newest of those. It reads from the newest correspondence now, as its heading always claimed.

Emails with no send date no longer show a dash. Drafts and some filed copies carry no sent time, and used to appear with no date at all. They now fall back to when the email was received or filed. Direction is spelled out as “inbound” or “outbound” rather than a single letter.

A filter that didn’t take hold is now an error, not a quiet full list. If a search narrowing isn’t applied for any reason, the results are checked against what was actually asked for and the answer fails outright rather than presenting the matter’s entire email history under a heading that says it was filtered. Asking for a page past the end, or for something with no matches, says so plainly too. An email sweep is the kind of thing a decision gets made on, so a wrong list is worse than no list.

A one-time reconnect is required this time. The number of actions is unchanged at 71, but the email action now takes the filters described above, and the list of what each action accepts is read once when you connect. Until the Actionstep connector is reconnected once, per place you use it, that place still has the old email action and cannot search or page through a matter’s emails. Nothing breaks in the meantime — everything else keeps working exactly as it did.

Ask a question of your firm’s whole data set, not one matter at a time. Three things your firm has always held in Actionstep were simply unreachable through its API — every fee earner’s KPI targets, the trust ledger, and lifetime financial totals per matter. They are now available to your assistant, along with everything else the firm records. Four ready-made views cover the questions most firms ask — KPI targets by fee earner and month, the trust ledger for a matter, what a matter has billed and what is still owing, and billable hours and fees by fee earner by month — and anything outside those four can still be asked for directly.

See what you can ask before you ask it. A companion action lists the ready-made views and the underlying tables, explains what each column holds, and says which views leave out impossible dates — the timesheet entry dated in the year 8973 that would otherwise turn up in a monthly total. Useful in its own right, and it is what your assistant reads when a question doesn’t fit one of the four views.

Every reporting answer says how old it is. This data is refreshed overnight, not read live from Actionstep, so every answer — including one that finds nothing — states the date it was taken and says plainly that it is not live Actionstep data. Past a threshold it carries a warning instead. A trust figure or a WIP total that is a day old is exactly the kind of number that ends up in an email to a client, so it never arrives without its date attached.

A one-time reconnect is required this time. Two new actions bring the total to 71. Until the Actionstep connector is reconnected once, per place you use it, that place still sees 69 actions and cannot reach the reporting data. Nothing breaks in the meantime — everything else keeps working exactly as it did.

Reporting can read, and only read. Nothing in the reporting data can be created, changed or removed through it — the reporting copy is rebuilt from Actionstep every night, and Actionstep remains the only place anything is written. That is enforced in seven independent layers rather than by asking nicely: the request is screened before it runs, the connection itself is opened read-only, and the database engine refuses every write instruction and every attempt to reach any other file on the server. A single request also can’t be made large enough to slow the server down for everyone else.

A failed overnight refresh keeps yesterday’s data serving. Nothing is swapped in until it has been checked end to end, and a refresh that came back holding materially less than the copy it would replace is refused outright — a partial export that quietly made every answer smaller would be far worse than an answer that is a day old. Your firm’s administrators are emailed when a refresh fails, and the attempt is recorded in the activity log either way. The worst case is stale, never wrong and never missing.

See how a contact connects to other contacts. Directorships, group and trust structures, body-corporate management chains, employers, family, and which firm acts for whom — all of it was already in Actionstep and none of it was visible to the assistant. This is the other half of a conflict check: searching a name answers “have we acted against this person”, and relationships answer “and what else is this party”. Relationships point in a direction and both directions are reported separately, because a check that merged them would misstate who controls whom. You can record a new relationship and remove one, and the assistant reads it back before confirming.

Set the matter’s billing email address. The address a matter’s invoices are emailed to could only ever be read — setting it on a new matter meant a separate trip into Actionstep every time. It can now be set through the assistant, including several addresses separated by commas, which is what Actionstep itself allows. Three other fields on that same Actionstep screen — the email template, the invoice template and the number of copies to print — are not reachable through Actionstep’s API at all, and still have to be set in Actionstep.

Advancing a step can now create the tasks, documents and messages that step lists. Ask what a step change will bring with it and you get the tasks, document templates and messages it offers; you can then have the step change create them in the same request. Nothing fires on its own — you choose what does.

A custom data update now tells you what was stored, not what was sent. After writing a field the assistant reads it straight back and shows the row — old → new — and says the confirmation came from that read-back. If the field comes back holding something different, both values are shown side by side rather than the change being confirmed. If the read-back itself can’t be completed, it says “accepted, unverified” rather than claiming either outcome.

A one-time reconnect is required this time. Three new actions bring the total to 69, and the step-change action gains new options. Until the Actionstep connector is reconnected once, per place you use it, that place still sees 66 actions and cannot use the new step-change options. Nothing breaks in the meantime — everything else here applies immediately.

Billing email addresses are kept out of your firm’s activity log. A tool used at every matter opening would otherwise accumulate client billing addresses in plain text, once per matter, in a log whose whole purpose is to record who did what rather than to hold client data. The address is now hidden in that log; the row still records the person, the matter, the time and whether it worked, and the address itself is always readable in Actionstep.

The assistant will not clear a matter’s billing email. An empty value is meaningful in Actionstep — it is how emailed invoices are switched off for a matter — so leaving the address out of a request means “don’t touch it”, never “empty it”. Turning off emailed invoices stays an Actionstep action. A blank address inside a list of several is refused outright rather than quietly dropped, because silently shortening a delivery list is how one recipient stops receiving bills with nobody told.

A refused deletion was being recorded as a successful one. When a deletion was rejected because the record reference was malformed, nothing was deleted — but your firm’s activity log recorded the attempt as having succeeded. An accountability record saying “that worked” about something that never happened is the wrong way round, and it now records a refusal. This affected all eight deletion actions. It is a narrow class — the reference had to be malformed, so no record was touched either way — but it is a second reason not to read the “succeeded” column as gospel for rows written before this release.

A custom data field could quietly be written twice. Before writing, the assistant checked whether the field already held a value — but it only looked at the first 200 records on the matter. Past that point it concluded the field was empty and added a second value alongside the first, while the matter went on displaying the original. It now looks across the whole set, and where it cannot get to the end of that set it refuses to add a value rather than risk a duplicate: not writing is recoverable, a duplicate is not.

A custom data update could confirm a write that never landed. The confirmation was based on Actionstep accepting the request, not on the record having changed — the same mistake as reporting a request back as a result. A write that does not appear in the record is now reported as a failure, plainly, instead of being confirmed.

A step change said it would create tasks, and created none. Asking what a step change involved listed tasks as “created on transition”; the step change then advanced the matter and no tasks appeared. The wording now reads available on transition and says plainly that nothing fires on its own, and the step change itself can now create them when you ask for them.

Record an amount that isn’t hours × rate. A write-down, a write-up or an agreed fixed sum can now be stated directly when recording or correcting time, instead of being fixed by hand in Actionstep afterwards. A stated zero counts as a real figure — a genuine write-off — while a negative amount is refused, because that is a credit note rather than a time entry. Stating a figure takes precedence over the assistant working one out, but it will still not touch an entry that has been billed, or convert a fixed fee. This is the one part of this release that waits for a reconnect.

A correction now shows what you asked for and what Actionstep did, separately. The confirmation lists the change you requested — including the amount, when the assistant worked it out on your behalf, and what it derived it from — and then what Actionstep actually applied. Where the two agree there is no warning at all, which is new: the old wording could not tell “we corrected it” apart from “Actionstep happened to already agree”, so it warned either way. Where they disagree it now says so plainly, and where the assistant deliberately left the money alone it names the reason.

Changing only the hours now says what it did not change. On a correction, the hours you pass set the recorded actual hours and nothing else — the billable hours and the stored amount stay as they were. That differs from recording a new entry, where hours set both, which is surprising enough to be worth stating: the confirmation now tells you, and points at billable hours if changing what is charged is what you meant.

Template lists are now alphabetical. They used to come back in the order Actionstep happened to create them. Every firm’s listing order changes with this release.

A template search that finds nothing now tells you what it looked at. Instead of a bare “no templates matched”, a miss answers with real numbers — “all 660 templates in the catalogue were searched” — and, because templates belong to particular matter types, it says when the name does exist elsewhere in the catalogue and how to see it. Every answer also states what was searched, how many matched in total, and whether anything was left out.

One-time reconnect, and only for the new option. The list of available actions is unchanged at 66, so nothing breaks if you do not reconnect. Reconnecting the Actionstep connector once, per place you use it, is what lets you state an amount directly. Everything else here — the corrections, the guards, the clearer confirmations and the whole template search fix — applies immediately, without waiting.

Correcting a rate now changes what the client is charged — last release’s advice no longer applies. In v1.13.0 we told you to make rate corrections that matter in Actionstep itself, because the assistant could change what an entry said without changing what it billed. That is fixed, and the instruction is withdrawn: a rate correction through the assistant now moves the billed figure with it, in the same single change, so there is no moment where the entry reads one rate and bills another. In exchange the assistant now writes money values, which it did not before — so it writes one only on a correction you asked for, only when your change implies exactly one figure, and it always tells you when it did.

Three things it still will not overwrite. An entry that has already been billed is refused outright and the invoice is named — correcting half of it would leave the record disagreeing with what the client was charged, which is worse than either finishing or not starting; the date, description and activity code remain correctable. A fixed fee is never recalculated from hours, and cannot be forced to be. And an amount that already disagreed with hours × rate is treated as a deliberate write-down and left alone, because the assistant cannot know the figure you intended — it declines and tells you how to state the new one.

A corrected rate went on billing the old amount. Correcting an entry’s rate updated the rate on the record but left the stored amount frozen at the old figure — and the stored amount is what gets billed. A 0.1 hour entry saved at a $650/hr default instead of the fee earner’s own $700/hr was corrected to $700/hr and still charged $65.00, and had to be put right by hand in Actionstep. A correction now rewrites the amount in the same change as the rate: that entry now reads $700.00/hr and bills $70.00.

An entry could show a rate and charge nothing. Recording time with a manual rate but no rate card stored an amount of $0.00. The entry then displayed its rate on every screen and report while billing nothing at all — the shape most likely to reach an invoice unnoticed, because nothing about it looks wrong. The assistant now supplies the amount itself in that one case, and leaves it to Actionstep in every other, so a correctly calculated figure is never written over.

A template search only looked at the first 200 templates. Searching by name filtered a single page of results, so in a catalogue of 660 or 1,600 templates anything past the two hundredth record came back as “no templates matched” — indistinguishable from the template not existing. It was found when a firm searched for a template it certainly had and was told it did not. The name search now runs across the whole catalogue.

An explanation that was simply wrong is gone. Every mismatched amount used to be explained with the same sentence — that Actionstep does not recalculate a stored amount when hours or a rate change. On a newly recorded entry nothing had changed, so the sentence sent people looking for a change that never happened. Each outcome now carries its own explanation.

Ask about time across matters, not just one. Time entries no longer need a matter to be listed. Ask by fee earner, by date range, by billed or unbilled, with an optional per-matter roll-up — "what has this fee earner recorded this month that hasn't been invoiced yet?" now simply works. At least one filter is always required, and a date window applied by default is stated in the answer rather than assumed.

Look up a single time entry, disbursement or task by its reference. Until now these could be corrected and deleted but never read back, so "what does that record say now?" had no answer. Each leads with the matter it belongs to, because a bare record number carries no context and these are what you reach for before a deletion. A single calendar appointment can now be fetched by reference too.

Check whether someone is a fee earner. Lists every Actionstep user account held by a contact and states the conclusion — active, inactive, or not staff at all. One person can hold two accounts, which we found in practice; a check that assumed one account had no defined answer in that case, and it gates who work can be billed against.

Where a rate came from is now shown beside it. Each entry reads $700.00/hr (Partner · Timekeeper) — the card's name, then whether the price came from that fee earner's own rate, the card's default, or a manual override. It isn't warned about, because a card default is perfectly legitimate for anyone without an individual rate. It's shown because one default sitting among forty individual rates is what exposed two partner entries stored at the base card price instead of that partner's own rate.

Money that can't be resolved is disclosed, not guessed. An entry carrying neither a stored amount nor a stored rate contributes nothing to the total, and the total says so — "2 of 45 shown entries carry no stored amount and are excluded from the dollar total." Filling the gap from the rate card and labelling it as an estimate was considered and rejected: a total gets quoted into a client conversation and travels without its label, whereas a stated shortfall prompts someone to ask.

Fixed fees, and amounts that don't add up. A fixed-fee entry reports its stored amount and is never multiplied by hours; its hours still count toward the hours total. And where a calculated entry's stored amount disagrees with hours × rate by more than a cent, the discrepancy is spelled out. The stored amount always wins the arithmetic — the warning never changes a number.

Rate card lookups now say what they are. The rate card tools were always correct, but printing a bare dollar figure next to a job title is precisely the reading that caused all of this. They now carry one line — these are base rate-card values, not what any individual fee earner charges. Amounts also read $650.00 rather than $650.0000.

Your firm's activity log is readable again. Search filters and paths were being clipped at 48 characters, which left many rows recording nothing usable about what was actually asked for. They now record up to 256. Rows written before this release stay as they are — the shortening happened when they were written.

One-time reconnect to see the new actions. Four new actions bring the total to 66. As with any change to the available actions, they appear after you reconnect the Actionstep connector once, per place you use it. Nothing else changes and there's no forced re-sign-in.

Nothing in Actionstep was written incorrectly, and no correction to your data is needed. We read the full activity log back to November 2025: every billing call the server has ever handled was read-only — not one time entry or disbursement was created or changed by it. This was a reporting fault, not a data fault. It does mean any fee figure quoted from the assistant before this release was understated, so re-check anything that went to a client on the strength of one.

Correcting a rate doesn't change what the client is charged — and the assistant now tells you. Actionstep does not recalculate a time entry's stored amount when you change its hours or its rate through the API; the original amount stays frozen. The stored amount is what gets billed, so correcting an entry through the assistant changes what the record says without changing what is charged. This is Actionstep's behaviour, not ours, and we've deliberately not had the server write a money value to work around it. Instead it's now surfaced in three places — the entry listing, the update confirmation, and the guidance the assistant reads before it offers to correct anything. Make rate corrections that matter in Actionstep itself.

A guard on those wider searches. An Actionstep filter it doesn't understand isn't rejected — the API returns the entire table and the answer looks perfectly ordinary. On our test tenant that's more than 145,000 time entries. So no request is ever sent without a filter, and every row that comes back is checked to actually carry the fee earner and matter that were asked for. One wrong row and the request fails, naming what it saw, rather than reporting a figure quietly built from the whole firm.

Every time entry's rate and amount was understated. When listing a matter's time entries, or reading the fees section of a matter summary, the assistant followed the entry's link to your firm's rate card, read the card's price for that rate band, and recalculated the amount from it. The rate actually applied and the amount actually stored sit on the time entry itself, and were never read. Wherever a fee earner charges something other than the base card price — a rate set for them individually, a historic rate from before an increase, or a "custom rate" placeholder card — the figure reported was wrong, and always too low. On the matter that surfaced it, the reported fee total was 14.9% short of the true figure. Both now report the rate and the amount Actionstep stored, and a total is the sum of those stored amounts rather than a recalculation. The rate card contributes its name and nothing else.

Dates in a matter summary's fees section never worked. Every date rendered as a dash, and because the same missing date was also the sort key, "the five most recent entries" was arbitrary — an active matter could show you five entries from 2023. Fees now read real dates, in real order, and match the full time entry listing exactly.

Disbursement quantities in matter summaries. The summary read the unit price and ignored the quantity, so 40 pages at $0.50 totalled $0.50 there while the disbursements list correctly said $20.00. Both now derive it the same way.

Recording or correcting time now reports what Actionstep applied. Both previously discarded Actionstep's response and restated your request back to you — an update would confirm "rate override → $350.00/hr" whether or not Actionstep had honoured it. Both now read the response and report the rate and amount actually applied, and say so plainly when that differs from a rate you specified. It's the same mistake as the reporting fault above: treating the request as the result.

Your assistant can now delete eight kinds of record. Tasks, time entries, disbursements, a matter's rate override, calendar appointments, custom-data rows, a contact's role on a matter, and file notes. Until now the assistant could only read, create and update — cancelling an appointment or removing a file note written on the wrong matter meant a trip into Actionstep.

Correct a file note. File notes couldn't be edited at all before this. The text can now be corrected — but the matter it sits on and the time it was recorded deliberately can't be, because re-dating a contemporaneous record is exactly what would rob it of its evidentiary weight.

Two things the assistant can now look up. A matter's document folders, and which custom data collections and fields exist for a matter type — field names that previously could only be discovered by chancing upon a matter that happened to have them filled in.

Correcting is offered before deleting. Where an update does the job — completing a task rather than removing it, fixing a time entry's hours, rescheduling an appointment — the assistant says so. Deletions are permanent and cannot be undone through the assistant; whether a deleted record can be recovered at all depends on Actionstep's own retention, not on us.

Matter summaries are noticeably faster. A summary used to make a dozen or more requests to Actionstep one after another. It now fetches them in parallel, in three passes, producing character-for-character the same answer. Reference data — matter types, custom-data structures, billing lists — is also briefly cached for each person, so a follow-up question doesn't re-fetch everything from scratch.

Long lists and long notes stay readable. Several places that could return an unbounded amount of text — most noticeably file notes, which fetched 200 in full regardless of how many you asked for — are now properly limited and honest about what's been shortened.

Clearer guidance behind every action. The descriptions the assistant reads were rewritten and reorganised around the job you're actually doing — most noticeably across billing, time and disbursements, the easiest family to confuse — so the right action gets picked more often.

One-time reconnect to see the new actions. The new tools and the rewritten guidance appear after you reconnect the Actionstep connector once, per place you use it. Nothing else changes and there's no forced re-sign-in.

What it still cannot delete. Matters, contacts, bills, emails, workflow steps, documents and your matter-type configuration are out of reach by design. That isn't a gap to be filled later — it's the boundary.

One record per request — never in bulk. No action accepts a list of records, a filter, or a "delete all of these on this matter" shorthand, and the assistant will not loop to clear a list. The risk with an AI assistant isn't one mistaken deletion — it's a tidy-up request quietly becoming forty. This is the bound on that.

It reads the record back before it destroys anything. Every deletion starts by fetching the record and telling you exactly what it's about to remove, including which matter it belongs to. If the record isn't found, nothing is sent. You can also name the matter you believe it belongs to — if it belongs to a different one, the deletion is refused and nothing is destroyed.

Every deletion is recorded, under the right person's name. Deletions run as the person who asked for one, so Actionstep's own audit shows them rather than a shared account, and your firm's activity log records the user, time, action and record — and whether it actually succeeded. A deletion that was refused is recorded as a refusal, not as a deletion.

Further hardening of sign-in and logging. The sign-in endpoints are now rate-limited per client, a re-used refresh token now invalidates that person's whole session rather than one token, access is checked against the firm the sign-in was issued for, and request details that could contain client information are no longer written out in full to the server's logs.

A refused action is now reported as a refusal. Previously, when something failed — a record not found, an expired sign-in, an operation Actionstep declined — the failure was still handed back as though the request had worked. Failures are now marked as failures, so your assistant can tell you an action didn't happen instead of reporting one that never took place. This also means the "succeeded" column in your firm's activity log is only meaningful from this release onwards; earlier rows are reliable on who, what and when, but not on whether the call worked.

Ask who's been doing what, in plain language. Administrators can review activity simply by asking — "show me who looked up contact details last week" — and get a clear, per-person summary. It's there for principals and practice managers who want visibility over how AI is being used across the firm.

Manage calendar appointments in conversation. See what's in the diary — filtered by matter, date range, or calendar — and book new appointments, timed or all-day, optionally linked to a matter. "Book a settlement conference for the Smith matter next Thursday, 2–3pm" now simply works.

Reschedule and update without leaving the chat. Move an appointment to a new time or change its details in the same conversation. Cancelling an appointment is still done in Actionstep itself.

One-time reconnect to see the new actions. Like any change to the available actions, the new calendar tools appear after you reconnect the Actionstep connector once, per place you use it. Nothing else changes and there's no forced re-sign-in.

Every action is now recorded — who did what, and when. The server keeps a private, server-side record of every request it handles: the person, the action they used, the time, and whether it succeeded. It stores only short, privacy-safe summaries — matter or contact references and search terms — never document contents or client data. Nothing your team does changes, and the record adds no delay to everyday work.

An early warning against bulk data harvesting. If one person runs an unusually high number of contact lookups in a short window, the firm's administrators are emailed automatically. The alert flags the activity for review — it never blocks anyone and never slows normal work.

Create precedents on the matter, through the assistant. Ask for one of your firm's Actionstep templates on a matter, and the assistant fills every merge field it can from that matter's data — client names, addresses, dates, matter details — then files the finished Word document straight back onto the matter. The manual trip into Actionstep to generate a precedent is no longer needed.

See exactly what will fill — before anything is created. Ask for a preview on a matter and the assistant does a dry run: it shows the value each field would fill with, and which would be blank, without creating a thing. It's there so you can spot the gaps first.

Browse your firm's templates. List the templates available to you, and narrow the list to a particular matter or matter type.

Set up per firm. Document generation is switched on for each firm after a one-time Microsoft 365 setup. See the Document Merger Setup Guide for the steps — until it's configured, the feature simply reports that it isn't set up, and everything else keeps working as normal.

Honest about gaps. Any field the matter has no data for renders as **** — matching Actionstep's own convention — and is named in the assistant's summary, so a half-populated matter never quietly produces a document that looks complete. As always, review the draft in Actionstep before it goes to a client or court.

One-time reconnect to see the new actions. Like any change to the available actions, the three new document tools appear after you reconnect the Actionstep connector once, per place you use it. Nothing else changes and there's no forced re-sign-in.

Your work is now recorded as yours. Each person signs in to their own Actionstep account through the connector, so when you create a time entry, file note, disbursement, task or matter through your assistant, Actionstep records you as the author — not a shared account. Timesheets, audit trails and "who did this?" now reflect who really did the work.

See who you're connected as. Your assistant now tells you which account you're signed in as — for example, "Connected as jane@firm.com.au" — so you always know whose name your actions will carry.

One-time reconnect needed. Because sign-in now works per person, everyone reconnects the Actionstep connector once — remove it and add it again, then log in — for each place you use it. It's a quick, one-off step, and after it day-to-day use is smoother than before.

Stay connected across updates. After that one-time reconnect, you should no longer have to remove and re-add the connector every time we ship an update — your sign-in now survives server restarts and new releases.

A more secure sign-in. We've strengthened the whole sign-in path: a modern proof-of-identity check is now required on every connection, sign-in can only return to approved addresses, two older less-secure sign-in routes have been removed, and several places that could have exposed access tokens are now closed off.

Complete and re-organise tasks. Your assistant could previously only create tasks — now it can tick them off, hand them to someone else, move the due date, or rename them.

See — and make — workflow step changes. Ask what advancing a matter will require — which tasks must be completed first, who's missing an email address, and what documents and messages will fire — then have the step change performed.

Fill in custom data fields. Set values like key dates or property details, and add extra records — a second property, say — to matters that allow them.

Read a matter's bills. Answer "has this been billed?" and "what does the client still owe?" — with each invoice's total, paid and outstanding amounts.

Rides out Actionstep's rate limits. When Actionstep momentarily rate-limits the connection, the server now retries automatically and transparently instead of returning an error — most noticeable on matter summaries.

Matter summary money totals are now correct. On a busy matter, the fees and disbursements totals could be silently understated — only the first 50 records were added up. Totals are now summed across every record, and clearly labelled as partial in the rare case a matter exceeds 1,000 entries.

Large lists no longer drop records without saying so. Lists of tasks, documents, notes and time entries now report an honest "showing X of Y", and a bug that could lose custom fields on very large collections is fixed.

Add a task to a matter. You can now create a task on an existing matter straight from your assistant — give it the matter, a task name, a due date, and who it's assigned to, with an optional priority and description. The task appears in Actionstep immediately, ready to work.

Company contacts save correctly. Creating or renaming a company contact no longer fails with a "valid Company Name" error — company names now save properly on both create and update.

No more dropped parties. When a matter is created with two parties in the same role (such as two clients), every party is now kept. As a safeguard, if the details don't line up the matter isn't created and a clear warning is returned, rather than quietly losing anyone.

More accurate party searches. Searching for the matters a person is connected to now returns only that person's matters — previously a search could return far more than intended. Conflict screening is now precise and dependable.

Closed and historical matters included. Party searches now look across closed and past matters too, not just open ones — so a conflict check sees the complete picture.

Asking for a conflict check or party screening in plain language now reliably reaches the right search.

Open a specific file note directly. File note lists now include a reference, so you can jump straight to the full text of any note you see.

People's names instead of ID numbers. Matter fields that point to a person now show the person's name rather than an internal reference number.

Companies and individuals labelled correctly. Contact searches now show companies as companies and people as individuals, instead of labelling everything the same way.

Clearer search feedback. Combining search filters that don't work together now returns a clear explanation instead of quietly ignoring part of your request.

"View in Actionstep" links now always open the correct place in Actionstep.

File notes read cleanly in matter overviews. Note text no longer cuts off mid-word, the note count is now accurate, and a clear "…and more" pointer appears when there are additional notes to see.

Friendly names for every action. Each thing you can ask for now has a plain-language name, so the list of available actions is easy to read.

Read vs. change, at a glance. Every action now shows whether it only looks information up or can make a change — so you always know what to expect before you run it.

Your own dedicated server. Each firm now runs on its own fully independent, secure environment — your connection and your data stay separate from every other firm's.

Smoother first connection. Resolved an issue in the sign-in flow so connecting to Actionstep for the first time works reliably.

Added a health check so the service can be monitored for availability.

Secure sign-in on every connection. Added full OAuth 2.0 authentication, so only authorised users can reach your data. Every connection is verified, and any unauthorised request is automatically rejected — your Actionstep data sits safely behind a secure sign-in.