Access is evaluated inside an organization boundary
The platform combines organization-scoped database access, effective permissions and a separate client-portal role. This page shows the implemented path and its review boundaries.
Content reviewed
Tenant scope and authorization solve different questions
Organization context constrains which tenant records a request may reach. Authentication and effective permissions then determine which actions the current user may perform inside that scope.
Trust topic
Four layers to inspect
Read each answer together with its implementation evidence and boundary. The page does not substitute for your own security or legal review.
01
How are organization records scoped at the database boundary?
Organization-aware data access runs inside a transaction that sets the current agency identifier. Row-level policies use that context and fail closed when it is absent.
What is implemented
The database client wrapper sets transaction-local agency context; the row-level security policy reads that context before allowing scoped rows.
Boundary
This describes implemented application and policy code. It is not a claim of external certification or an independent penetration test.
02
How does the platform decide what a staff user may do?
Requests carry authenticated user and organization context. Permission checks calculate effective capabilities from the user's role and explicit grants before protected actions proceed.
What is implemented
Authentication middleware builds the request context, while the shared permission contract defines and evaluates the allowed capability set.
Boundary
Permission quality still depends on correct role assignment and organization administration. A broad authorized role is not made narrow by the tenant boundary.
03
How is client-portal access separated from staff access?
Client users authenticate with a dedicated role and enter portal routes designed around records shared with their client relationship, rather than the internal application workspace.
What is implemented
Authentication distinguishes the client-user role; the portal router exposes client-facing operations through a separate route surface.
Boundary
The portal boundary must be reviewed per record type and sharing rule. This page does not imply that every internal record is available to clients.
04
When do permission changes take effect?
Protected requests resolve current authentication and effective permissions rather than relying only on a permission snapshot embedded when a session began.
What is implemented
Request middleware loads current context and the user-permission data path resolves explicit grants used by authorization checks.
Boundary
Exact propagation time can depend on session, cache and deployment configuration. Buyers should test their required revocation scenario during implementation.
Question to ask
Questions for an access review
Use your own role model and client-sharing scenario. Ask the same questions during a live product review.
01
Which boundary constrains the data query?
Ask where organization context is established, how absence is handled and which data families intentionally use a different scope.
02
Which current permissions authorize the action?
Review role defaults, explicit grants, administration rights and what happens immediately after a permission is removed.
03
What can this client see, and why?
Test a shared and an unshared record with an actual client role. Include attachments, related records and direct links.
Related sources and product paths
Continue with the general security overview, the privacy policy and the implemented knowledge-and-control path.
