Back to features
Feature deep dive

Multi-Tenancy

Separate organizations, isolated data

Run each organization on its own database with complete data isolation, then use branches and roles inside that organization when further separation is needed.

Ofisync dashboard preview for Multi-Tenancy
ofisync.app / multi-tenancy

Tenant console

Organization isolated

Dedicated organization database
Nairobi branch scoped
Management role sees all branches

Live business context

Run each organization on its own database with complete data isolation, then use branches and roles inside that organization when further separation is needed.

Database
Branches
Roles

Why it matters

Each organization gets its own protected data boundary.

Multi-Tenancy in Ofisync is built around strong separation. Each organization can operate from its own database, keeping records completely isolated, while branches inside the organization can add another layer of structure and access control.

OrganizationsHolding groupsMulti-branch businessesOperations leadersSystem administrators

Keep each organization's data fully separated from every other organization.

Let branches operate independently where structure or sensitivity requires it.

Use roles to control who can see organization-wide or branch-specific information.

Guided workflow

From setup to daily execution.

1

Create the organization space

Set up an organization with its own database so users, clients, files, billing records and other data stay isolated from other organizations.

2

Add branches when needed

Define branches inside the organization when different offices, teams or operating units need separate working areas.

3

Scope access with roles

Use roles and access rules to decide who can work across the organization and who should only see branch-specific records.

Tenant structure fit

Built around dedicated databases, branches and role-scoped access.

A group may manage several organizations on Ofisync, but each organization should have its own database and should not share operational data with the others. Inside one organization, branches such as Nairobi, Mombasa or a specialist department may also need separate visibility depending on roles and responsibilities.

Separate organizations should not share the same operational database or expose records to each other.
Branch teams may need their own working area without losing the ability for authorized managers to oversee multiple branches.
Role-based access must respect both organization-level and branch-level boundaries.
Sensitive records become risky when organization and branch scope are treated as simple labels instead of real access boundaries.
User story

How Multi-Tenancy works in practice.

1

Scenario 1

The organization starts with its own database

Multi-Tenancy begins at the organization level. Each organization can have its own database, which keeps its users, records, files, billing data and operational activity completely separate from every other organization.

2

Scenario 2

Isolation is not just a label

Because organization data is separated at the database level, one organization's records are not mixed with another organization's records. This creates a clear boundary for security, privacy and operational control.

3

Scenario 3

Branches add internal structure

Inside an organization, branches can be created for offices, departments, regions or operational units. A branch can act as a further boundary where records need to be scoped more tightly.

4

Scenario 4

Branch isolation is used where it makes sense

Not every organization needs strict branch separation. Where the business does need it, branch scope can help keep users, clients, projects, files or billing records visible only to the right part of the organization.

5

Scenario 5

Roles decide how far a user can see

A user may be limited to one branch, allowed to work across selected branches or given organization-wide visibility. Those boundaries are controlled through roles and access rules.

6

Scenario 6

Managers can have broader oversight without exposing everything to everyone

Branch users can stay focused on their own records while authorized managers or administrators can view wider organization activity when their role allows it.

7

Scenario 7

All connected modules respect the tenant boundary

Clients, projects, files, billing records, documents, users, workflows and notifications can operate within the organization and branch boundaries defined by the tenant setup.

8

Scenario 8

The structure can grow with the organization

As the organization opens new branches or changes how teams work, admins can adjust branch structures and roles without weakening the database-level isolation between organizations.

Tenant scenarios

Where isolation keeps organizations and branches controlled.

Tenant scenario 1

Dedicated organization database

Each organization can operate from its own database, keeping clients, projects, files, users, billing records and other data completely isolated from other organizations.

Tenant scenario 2

Branch-level separation

Branches can be defined inside an organization so different offices, teams or units can have separated records where the business needs that extra boundary.

Tenant scenario 3

Role-scoped visibility

Roles can determine whether a user works only within a branch, across selected branches or across the whole organization.

Each organization can have its own database for complete tenant isolation.
Branches can provide further separation inside the organization where necessary.
Roles and access rules can control whether users see organization-wide data or branch-specific records.
Tenant isolation applies across operational modules, including users, clients, projects, files, documents and billing records.
Branch structures are optional and can be used only where the organization needs internal separation.

Inside tenancy settings

A workspace for organization and branch isolation.

The tenancy workspace keeps organizations, dedicated databases, branch structures, role boundaries and access rules connected so each organization can remain fully isolated while still supporting internal branch-level separation.

Organization admins

Dedicated organization database, users, branches, roles and tenant-wide configuration

Branch teams

Branch-scoped clients, projects, files, billing records and day-to-day work

Managers

Organization-wide or selected-branch visibility based on assigned roles

Tenant records

What stays separated and scoped

Organizations with dedicated databases and complete data boundaries
Branches inside each organization where additional separation is required
Users, roles and access rules that define organization-wide or branch-scoped visibility
Clients, projects, files, documents, billing records and workflows inside the tenant boundary
Administrative changes to organization, branch and role structure

Tenant movement

Actions Ofisync can prepare from tenancy settings

Provision organization workspaces with their own isolated database boundary
Apply branch scope to records where branch-level separation is configured
Enforce role-based visibility across organization and branch boundaries
Keep connected module records inside the correct tenant and branch context
Reflect branch or role changes in the access available to affected users

Tenant view

Organization boundary

Review the organization workspace, dedicated database boundary, users, branches and core tenant configuration.

Tenant view

Branch scope

See which branches exist inside the organization and which records or users are scoped to each branch.

Tenant view

Role visibility

Check whether users can see one branch, selected branches or organization-wide records based on their assigned roles.

Ready to see it live?

Walk through Multi-Tenancy with an Ofisync specialist.

We will map the demo around your business workflow, show the connected modules and help you identify the fastest path to rollout.

Request Demo