Owner, Editor, Viewer: How Rexfin's Permission Model Actually Works
Three roles, server-enforced everywhere, with deactivation instead of silent deletion. Here is how access control works on Rexfin.
By The Rexfin team
Permission models in small SaaS tools tend to fall into one of two bad shapes: everyone can do everything because the team is small, or the tool bolts on an enterprise-grade RBAC system nobody on a three-person finance team asked for. Rexfin picked a narrower middle: three roles, each with a clearly different job, enforced on the server every time, not just hidden from the menu.
Three roles, not a permission matrix
An owner can invite teammates, change anyone’s role, and deactivate members: the only role that can. An editor can upload documents, review them, run scenarios, and generate exports. A viewer can see dashboards, statements, and ask questions, but cannot upload or change anything. That is deliberately close to what most finance teams actually need: someone who runs the workspace, people who do the work, and people who consume the output: a controller, an analyst, and a board member reading the pack someone else built, roughly speaking.
One rule sits underneath all three: a workspace can never end up with zero owners. If the last remaining owner tries to demote themselves or gets deactivated by someone else, the system blocks it. That sounds obvious until you consider the race condition it prevents: two owners deactivating each other at nearly the same moment could otherwise leave a workspace with nobody in charge of it. Rexfin closes that at the transaction level, not with a warning dialog that a fast click can outrun.
Deactivation, not deletion
Removing someone from a workspace on Rexfin is a soft action, not a hard delete. Deactivating a member does three things atomically: marks them inactive, revokes every session they currently hold, and writes one record of who did it and when. The person is logged out immediately, not “eventually,” not “the next time their token expires,” because sessions are checked against the database on every protected request, not just verified by a signed cookie at the edge. A deactivated account cannot log back in, and a password-reset link sent to it does not work either.
What does not happen is a quiet cascade delete. Comments, scenarios, and audit entries a deactivated person authored stay exactly where they were, still attributed to them, with the display simply noting they’ve been removed from the team, so history stays intact and nobody has to explain a gap in the record. A pending invite that has not been accepted yet can be revoked outright. One that has already been accepted cannot be revoked as if it never happened; the system tells you plainly to deactivate the member instead, because pretending an active account was never invited is a different and worse kind of dishonesty in an audit trail.
Every change is logged, and cross-workspace probing gets nowhere
Every role change and every deactivation writes a row to the workspace’s own audit log: who did it, to whom, and what changed. That log is the record you’d hand an auditor asking “who had access to this data and when,” not a reconstruction from memory.
Access checks happen on the server for every mutation, and they are scoped to the caller’s own workspace before anything else runs. Try to act on a resource from a workspace you don’t belong to, and you get a plain 404, not a 403: the system doesn’t even confirm the resource exists rather than just denying you access to it, which matters because a 403 quietly tells a prober “yes, this exists, you’re just not allowed” while a 404 tells them nothing at all.
Where this sits in the bigger picture
None of this replaces enterprise SSO or a full RBAC hierarchy: that is a deliberate scope choice for the size of team Rexfin serves today, not an oversight. For how this fits alongside the rest of the platform’s controls, see the security architecture overview, and for what a new teammate actually sees on day one under each role, read the first week walkthrough. Everything above is also part of what Rexfin shows a prospective customer’s security team directly, more on that at the Trust Center, or browse the full pillar hub.
Part of Inside the Rexfin Platform: How the Trust Machinery Works