Somewhere in your charity there is an email thread that decided whether a donation was claimable. There is a spreadsheet with a note in column K. And there is a colleague who remembers why last year’s claim excluded a particular fund, and who is on annual leave.
Actions replaces all three. When something in your data needs a decision — a donation that looks wrong, a declaration somebody disputes, a line in a tax claim you want re-examined — you raise an action against that exact record. It goes to us, it comes back with an answer, and the answer stays attached to the thing it concerns.
This is not a helpdesk ticket in a system that has never heard of your donor record. Actions sits inside the same platform that builds and submits your claims, on the same donation and supporter data, which is why it can tell you what changed as well as what was said.
An action is never a free-floating message. It is raised against a specific donation, a specific supporter, or a specific line in a tax claim, and it carries that context with it. Nobody has to describe which gift they mean, paste a reference into an email, or work out afterwards which claim a decision applied to.
Logged, in review, applied, resolved. Each move is recorded on the row with who made it and when, and the full event history stays there. A block stays open until somebody actually decides it — there is no tidying the queue by closing things that were never answered.
Raise a query that already exists and Actions rejects it with a link to the open one, rather than silently swallowing the duplicate. And closing an action needs a reason from your own list, so the record says why the decision went the way it did, not just that somebody clicked done.
You raise the action from the record it concerns — a donation, a supporter, or a line in a tax claim. It arrives with that context already attached, so there is nothing to explain twice and no reference number to chase.
The action moves into review and stays visible to both sides while it is being worked. You can see that it is open, what state it is in and who moved it there, without emailing anybody to ask.
The change is made against the underlying data — a correction, an exclusion, a repair, a re-declaration — and the action records that it was applied, not just that it was agreed.
The action closes with a reason recorded, and the whole history stays on the row. Months later the row still answers the question an auditor is actually asking: who decided this, when, and on what basis.
Actions is live in client portals now. It is not a roadmap item dressed up in the present tense.
In a single week, one charity’s auditor raised five real queries against live data and ran every one of them end to end — logged, reviewed, applied, resolved — with each decision recorded against the donations it concerned. Nothing waited in an inbox. Nothing depended on somebody remembering a conversation from eighteen months ago. When the next auditor asks why a donation was included, excluded or repaired, the answer is on the row, with the name and the date beside it.
Today a duplicate is rejected with a link to the open action. Next, you will see the existing open action before you can raise a copy at all — so the second person to spot a problem joins the conversation instead of starting a new one.
Actions currently attributes each state change to an account. Display names are coming, so the history reads like a record of people making decisions rather than a list of logins.
Some work needs to be tracked without being visible to the other side of the ledger. Internal-only actions are in build, so your team can use the same lifecycle for its own follow-ups.
Declarations, eligibility rules, submissions and HMRC rejects. Rejects and repairs arrive in Actions with the fix already scaffolded.
Learn moreThe canonical supporter record. Raise an action from the donor you are looking at, against the gift you are querying.
Learn moreInteractive reports over the same governed model, so the number you are querying and the number in the report are the same number.
Learn moreEvery communication with a supporter on one timeline, so the context behind a query is on the record rather than in somebody's inbox.
Learn more