Multi-Branch ERP Data Boundaries: Scope Every Record and Action Adding a branch dropdown does not make an ERP multi-branch. The application must define whi...
Multi-Branch ERP Data Boundaries: Scope Every Record and Action
Adding a branch dropdown does not make an ERP multi-branch. The application must define which records belong to one branch, which are shared, and who can move information across boundaries. Those rules should be written before queries, exports, and approvals are built. Organizational and legal requirements vary, so a domain owner must approve the boundary model.
Model ownership explicitly
Give branch-owned records an unambiguous branch identifier. For shared reference data, such as a central product catalog, distinguish global records from branch overrides. An employee may have memberships in more than one branch with different permissions. Avoid storing a single branch_id on the user if transfers and temporary assignments are real workflows.
Define what happens to historical records when a branch is renamed, merged, or closed. A transaction should retain its original branch context for audit and reporting even if the employee later moves elsewhere. Cross-branch transfers need two-sided events or a documented ownership change, not an invisible update.
Enforce scope at every boundary
Apply branch authorization in detail routes, search, aggregates, bulk actions, downloads, queued jobs, and APIs. A list filter is not enough if a user can guess an ID and open another branch's record. Server-side policies should check both the user's permission and the record's branch. Test administrators and service accounts separately; they are common routes around normal scoping.
Database row-level security may provide defense in depth for suitable architectures, but it does not replace application-level business authorization. When using PostgreSQL policies, verify both read and write behavior, including WITH CHECK for new row values. If the project uses a different database, use equivalent application constraints and automated cross-branch tests.
Reporting and operations
A head-office report may legitimately aggregate branches. Label its scope clearly and use permissions that are distinct from branch-local reports. Avoid exposing small-cell personal data through an aggregate. Record who changed a branch assignment and why. Backups and restore drills should account for shared tables and the risk of overwriting another branch's newer data.
Test a branch transfer, a shared supplier, a global price update, and a mistaken cross-branch URL. The security model is correct only if the system stays consistent through these ordinary changes. For implementation, see our web development service.
References