Settings — Access & Permissioning

Settings ▸ Access & Permissioning is a read-only reference that answers one question: who is allowed to do what — with particular care around client trust money.

It is the operational companion to Access Levels, which is where you actually grant someone an access level or an additional-access switch. This page shows what those grants let a person do.

Why this page can be trusted

Every row is served from the platform’s authority registry, which records, for each action, the specific server-side check it was derived from. An automated test reads those checks on every build and fails if a rule shown here has stopped matching the code — in both directions:

if a restriction described here is removed from the server, the build fails;
if a restriction is added to an action this page calls open, the build also fails.

So a rule cannot change without this page changing in the same commit. This matters: a permissions page that quietly disagrees with the software is worse than no page at all, because it will be relied on during an audit.

The three gates

Label	Meaning
Restricted	Only the listed people can perform the action. The server re-checks on every request — a hidden button is never the only protection.
Any team member	There is no permission check. Anyone signed in can perform it. Some are deliberate; the row says which.
Needs review	Current behaviour is shown, but the rule is inconsistent with its stated intent or has not been signed off. Not settled policy.

The four sources of authority

Access level — exactly one per person: Owner, Admin, Manager or General. Higher levels include everything below.
Additional access — a per-person switch layered on top: Bookkeeping Management, HR Management, Compliance Management. Each exists so a specialist gets the authority for their job without being made an Admin.
Matter-level authority — the Matter Responsible is elevated for a small set of actions, on their matter only.
Trust Transfer Approver — a per-person designation for signing trust transfers. Independent of access level; a Manager or General user can hold it.

Settings that vary the rules

These are shown near the top of the page with their live values and a link to where each is changed. Changing them is Owner-only, even though granting a person authority is Owner or Admin.

Setting	Effect when set
Signature required at or above	Below this amount a trust transfer posts immediately with no signature. Leave blank to require a signature on every transfer.
Second signature required at or above	At or above this amount two different eligible signers are required. Leave blank to never require a second signature.
Matter Responsible may sign their own matter’s transfers	Lets the Matter Responsible sign without holding the Trust Transfer Approver designation. Off by default.
The person who requests a transfer may not sign it	Bars the requester from being signer or second signer. Off by default.
Matter Responsible may clear a screening hit on their matter	Allows a matter-scoped sanctions override without Compliance Management. Off by default.
Allow a trust balance to go negative	Enables the Owner/Admin override, which still requires a written reason. Off by default.
Days a cross-client transfer holds funds	How long funds stay held awaiting a client signature before the request is voided and the funds released.

Reading the trust section

Trust is the section to read in full, because the protections are not all of the same kind.

Recording a trust entry, transferring funds between two matters, and transferring between two trust bank accounts are not individually permission-gated today — any signed-in team member can perform them. What constrains them is business rules rather than roles: a matter-to-matter transfer is refused unless both matters share the same primary client, and a transfer to a different client requires that client’s signature before any money moves.

The strong controls sit around the edges:

Held funds cannot be spent through by anyone, including an Owner. Money promised to another client under a pending consent must have that consent voided openly before the funds are available again.
A negative trust balance requires an Owner or Admin, an organization-level opt-in, and a written reason.
Destroying trust history requires two different Admins — the one who approves cannot be the one who requested.
Voiding a trust transfer or a consent is restricted to the person who created it, an Owner or Admin, a Bookkeeping Manager, or the Matter Responsible for the matter the money came from. Allowing the creator to withdraw their own request is a deliberate exception: a void is a retraction, not an approval.

Sources & authorities

The trust rules above are built to the Law Society of Ontario’s By-Law 9 (Financial Transactions and Records), the accepted primary trust standard for this platform per [DEC-trust-001]. Record-keeping and trust-transfer requirements are set out in By-Law 9 — see the official consolidated text at lso.ca and on CanLII.

Who can see this page

Owner and Admin. The underlying data is refused by the server to anyone else, so a Manager or General user following a direct link will see an error rather than a partial table.

Troubleshooting

Symptom	Cause	What to do
”Couldn’t load the access rules”	The view is Owner/Admin only	Check your access level under Settings ▸ Access Levels.
A threshold shows Not set	The value is blank	Blank is meaningful — read the sentence under the label; it explains what blank does for that setting.
A rule is marked Needs review	The behaviour is unresolved or inconsistent	Read the note on the row. Treat it as current behaviour, not as policy, and raise it before relying on it.
The table scrolls sideways	The matrix is wider than the viewport	Scroll within the table. No column is ever hidden — narrow screens scroll rather than drop information.

Settings ▸ Access Levels — grant access levels and additional access
Settings ▸ Permissions & Access Rights — the long-form explanation of why each gate exists
Settings ▸ Audit Log — every gated action is recorded