Tenant resolution
The firm workspace is resolved through its tenant domain before tenant-scoped operating views are reached.
Firm and client boundaries
Firm boundaries start below the interface.
Audeska combines storage-layer firm isolation with role-aware workspace access, client scoping and deliberate document visibility—so the boundary is enforced at several levels, not left to navigation alone.
Firm schemaSeparate PostgreSQL namespace
User rolePartner, manager, reviewer and team scope
Client scopeAccess within authorised relationships
Document visibilityInternal by default; shared explicitly
Audeska access boundaryLayered control
Schema-isolated firmsEach firm’s operational data resides in its own PostgreSQL schema.
Role and relationship scopeAccess is evaluated through the user’s firm role and relevant client context.
Deliberate external visibilityClient portal users see their own context and explicitly shared documents.
Layered by design
No single interface check carries the whole boundary
Storage, tenant routing, membership, client scope and document state work together to narrow access to the intended firm and context.
Schema boundary
Each firm’s tenant data is stored in a separate PostgreSQL schema rather than a shared row pool alone.
Role and client scope
Membership, practice role and authorised client relationships determine what work a user may reach.
Object visibility
Document and portal states add a deliberate control over what may cross from firm workspace to client.
Storage-layer separation
One platform, distinct firm operating schemas
Audeska uses the tenant model to route each practice into its own PostgreSQL schema. The public marketing and firm locator realm remains separate from tenant operating data.
1
Firm-specific namespaceClient, engagement and practice records live inside the selected tenant schema.
2
Tenant-aware operating routesFirm workspaces are addressed through their registered tenant domain.
3
Tenant-scoped authorisationMembership and role are evaluated within the active practice context.
PostgreSQL tenant architectureConceptual view
Public schemaMarketing, firm discovery and platform public realm
PublicFirm A schemaFirm A clients, engagements, documents and operating records
IsolatedFirm B schemaFirm B clients, engagements, documents and operating records
IsolatedFirm C schemaFirm C clients, engagements, documents and operating records
IsolatedVisibility follows purpose
Internal work stays internal until a separate client-facing action
Role scope controls the firm workspace. Client relationship scope and explicit sharing narrow the portal further.
Firm workspace
Practice roles and internal control
- Partner, manager, associate and reviewer responsibilities
- Internal tasks, blockers, notes and review decisions
- Working papers and evidence under review
- Firm-wide views appropriate to authorised roles
Client portal
Client relationship scope
- Only the portal user’s client context
- Appropriate engagements and record requests
- Own uploaded records and response state
- Only documents explicitly shared by the firm
Security as operating discipline
The architecture supports the behaviour the practice needs
Technical boundaries and visible control states help teams make safer day-to-day decisions about access, review and release.
Firm admin
Control membership
Manage who belongs in the practice workspace and which role they hold.
Team member
Work within scope
Reach the client and engagement context appropriate to the user’s responsibilities.
Reviewer
Keep review internal
Record notes and decisions without making them client-visible by implication.
Client user
See only own context
Access the portal relationship and the information the firm has explicitly made available.
Review the boundary, not just the screen
See how firm isolation, roles and document visibility work together
We will walk through the tenant architecture and the day-to-day controls that govern access and sharing.
Request a security walkthroughReturn to the connected platform story.
Explore the full Audeska platform