Feature

Decide what each person may do

Access is granted from a catalogue of 43 named capabilities rather than a handful of tiers. A volunteer entering donations, a treasurer issuing receipts and an auditor reading reports each get exactly what their job needs.

How does access control work here?

Nothing is permitted unless it has been granted. A person is given a role, and the Member role is then configured permission by permission for that individual.

The rule is enforced on the server on every request, not by hiding menu items. A page somebody may not open refuses to open it, whatever the interface happened to show.

The roles that can be assigned

Three, and one of them is the configurable one that most people are given.

Organisation Owner
Billing, legal/profile data, users and roles, all configuration and records.
Report Viewer
Read and export approved reports only.
Member
Access is set per person by an organisation owner or administrator. New members start with the dashboard and nothing else.

What can be granted separately

The catalogue is deliberately fine-grained, because the useful distinctions are narrow ones.

  • Reading a receipt and issuing one are different capabilities, as are submitting, approving, voiding, downloading, printing and sending.
  • Reading billing and managing it are different. Somebody can see what the trust is on without being able to change it.
  • Managing a signature and deciding who may print it are different. The second is deliberately not implied by the ability to issue — a constraint its own subject can widen is decoration.
  • Reports are split by kind. General reports, donor reports and financial-year reports — which include the two government preparation views — are separate grants, as is the ability to export.
  • Support is not gated at all. Raising a support request needs an account and nothing else; the person most likely to be stuck is the one holding the fewest permissions.

The audit trail

Append-only, and enforced by the database rather than by the application alone.

  • Entries cannot be edited or deleted — not through the application, and not by anything else reaching the same tables.
  • Recent organisation activity is on the dashboard, for those holding the audit capability.
  • Each member’s own entries are on their record, which needs both the team capability and the audit one.
  • A receipt carries its own timeline — created, submitted, approved, issued, voided, generated, sent, downloaded, printed — so a single receipt can be accounted for without reading the whole log.

Frequently asked questions

Can team members have different levels of access?

Yes. Access is expressed as 43 named permissions, and the Member role is configured one person at a time from 38 of them.

Somebody can be given the ability to record donations without the ability to issue them, to read reports without seeing donor records, or to manage the receipt design without touching billing.

What does a new team member start with?

The dashboard, and nothing else.

Not zero, because a member with nothing at all signs in to an empty shell and a refusal and cannot tell that from a broken account — and not more, because each panel on the dashboard is gated on the permission behind it, so opening it discloses nothing that has not been separately granted.

How are colleagues added?

By email invitation from the team screen. The invitation carries the role, and the person sets their own password when they accept it.

Inviting somebody requires both the invite capability and the ability to grant roles, so a person cannot hand out access wider than their own by routing it through an invitation.

Is there a record of what people did?

Yes. Actions are written to an append-only audit log, enforced at the database rather than only in application code, so an entry cannot be altered or removed afterwards.

Recent organisation activity appears on the dashboard for those holding the audit capability, and each team member’s own entries appear on their record.

Can one organisation see another organisation’s data?

No. Every record belongs to the organisation that entered it, and every query is confined to the organisation of the person making the request.

The organisation is taken from the verified session and from nowhere a request can influence.

Bring your team in

Register your organisation, invite colleagues by email, and give each of them exactly the access their job needs.