Platform Architecture Overview

This page describes the architectural patterns underlying SAVHN at a level useful for administrators evaluating the platform and developers building integrations. It focuses on patterns, not implementation internals.

Multi-tenant organization model

SAVHN is built around a single core concept: the organization (tenant). Every record in every module — a CRM deal, an HRMS employee, a Finance invoice, a Ticket — belongs to exactly one organization. Tenant isolation is enforced structurally: the authenticated identity's organization is derived from its token, not passed as a client-supplied parameter, so there is no code path where a request can accidentally (or maliciously) address another tenant's data by guessing an ID.

This has a few practical consequences:

• Configuration is per-org. Two organizations running SAVHN can have entirely different module sets enabled, different roles, different custom fields, and different Industry Cloud templates active — the underlying platform is the same, the configuration surface is not.
• Scale is per-tenant, not global. Reports, dashboards, and search are always scoped to the requesting organization; there's no concept of a cross-tenant query in normal product usage.
• Superadmin operations are a separate layer. Platform-operator functions (support diagnostics, tenant provisioning, plan management) sit behind a distinct /api/superadmin surface and identity type, deliberately separated from the org-level API a customer's own tokens can reach.

One identity across every module

A defining product decision in SAVHN is that there is exactly one login and one identity per user across the entire platform, not a separate account per module. A user authenticates once and that single identity carries:

• Their role and permission set (see Role Management & Permissions), which determines what they see across every module.
• A single profile, notification preference set, and activity history that Timeline, Chat, Meetings, and every other module read from and write to.
• Continuity between modules — for example, a person mentioned in a CRM deal, assigned an HRMS record, and added to a Project task is the same identity object referenced from three different modules, not three loosely linked records.

This is what allows features like Manager Copilot and Business Brain to operate cross-module: they aren't stitching together separate identity systems, they're querying one identity and permission graph that every module already respects.

Real-time computed status vs. stale batch data

A common pattern in SAVHN is preferring real-time computed status over pre-computed batch fields wherever the underlying data changes frequently and the cost of computing on read is acceptable:

• A Project's "at risk" status, a Ticket's SLA remaining time, and an Invoice's "overdue" state are computed from current data at the time of the request (or updated reactively as inputs change), not written by a nightly batch job.
• This avoids the classic staleness problem where a dashboard shows a status that was true six hours ago but has since changed — a task marked complete should immediately stop counting against a project's overdue total, not wait for the next batch run.
• Where genuine aggregation cost makes real-time computation impractical (e.g. org-wide workforce trend lines spanning years of HRMS history in Workforce Intelligence), SAVHN uses materialized/cached aggregates refreshed on a schedule or on relevant write events — but this is the exception applied deliberately, not the default posture, and such views are labeled with their last-refreshed time so users know what they're looking at.

The practical guidance for anyone building against the API: don't assume a field is real-time just because it looks computed — check whether the specific resource documents a refresh cadence, and prefer webhooks over polling for anything time-sensitive (see Building Integrations with SAVHN).

Frontend architecture pattern

SAVHN's web application is built as a modern React-based single-page application using a file-system routed, server-and-client-component hybrid framework (an App Router pattern), which enables:

• Server-rendered initial page loads for performance, with client-side interactivity layered on top for the dynamic parts of each module (list views, real-time chat, live dashboards).
• Route-level code organization that mirrors the module structure described elsewhere in this documentation — each module is a self-contained route tree with its own layout, list/detail views, and settings screens.
• Shared UI primitives (permission-aware navigation, the global search bar, the AI Assistant panel) rendered at the application shell level so they behave consistently regardless of which module route is active.

Backend and data architecture pattern

The backend follows conventional patterns for a relational, multi-tenant SaaS platform:

• A relational database (PostgreSQL-class) is the system of record, accessed through a type-safe ORM layer that maps each module's domain model to tables scoped by organization.
• API routes are organized by domain, mirroring the /api/{domain} structure in the API Reference — each domain owns its own data model, validation, and permission checks, rather than a single monolithic data-access layer shared indiscriminately across modules.
• Cross-module features (Business Brain, Revenue Intelligence, Manager Copilot) read across multiple domain models but still respect the same per-request permission and tenant scoping as any other endpoint — there's no privileged internal bypass that skips RBAC just because a feature is cross-cutting.

How Industry Clouds fit architecturally

An Industry Cloud is not a separate codebase per industry. It is a configuration layer — a curated bundle of module enablement, default roles, custom fields, and workflow templates for a specific vertical (e.g. Construction, Healthcare, Legal Services) — applied on top of the same core modules every organization shares. This is why Industry Cloud-specific API endpoints (see API Reference) largely reuse core domain resources rather than introducing parallel data models.

How this shapes day-to-day platform behavior

These architectural choices are not merely internal detail — they explain product behavior admins and developers encounter directly:

• Why disabling a module doesn't delete its data. Because the underlying relational model doesn't tie a module's existence to its data's existence, disabling a module is a navigation and permission change, not a data lifecycle event.
• Why a permission change takes effect immediately, everywhere. Because there is one identity and one permission graph, a role change made in the Admin Console is reflected the next time that user's token is checked — there's no per-module permission cache to separately invalidate.
• Why cross-module features respect your existing access. Business Brain answering a question that spans CRM and Finance data still only surfaces what the asking user's role would let them see if they queried each module directly — the cross-module layer doesn't have a standing bypass.
• Why API rate limits are per-organization, not per-module. Because tenancy is the primary scoping boundary, quota and rate-limit accounting is naturally organization-scoped rather than needing separate budgets per API domain.

Summary of key patterns

Pattern	What it means in practice
Multi-tenant by organization	Every record scoped to one org; isolation enforced structurally, not just by permission checks
One identity, all modules	Single login, single permission graph, consistent profile across the platform
Real-time computed status	Status fields reflect current state on read, not a stale batch snapshot, except where explicitly cached
App Router-based frontend	Route structure mirrors module structure; hybrid server/client rendering
Relational + ORM backend	Domain-scoped API routes over a shared relational database, respecting RBAC uniformly
Industry Clouds as configuration	Vertical bundles of core modules, not separate codebases

Understanding these patterns is useful context for the rest of this documentation — particularly the Security & Compliance Overview, which builds directly on the tenant isolation and identity model described here.