Multi-location systems need local context

Keep branch context visible while sharing the records and reporting that the whole business needs.

Retail tablet workstation with additional counters visible in the background.

A shared application can help several locations work as one business, but it must preserve the context that differs between branches. Stock, opening hours, staff access and scheduling may all be local. The interface should make the current location obvious and distinguish a local task from a company-wide view. Start by deciding which information is shared and which belongs to a particular operational location.

Map shared and local records

Imagine a repair business with workshops in Adelaide, Melbourne and Brisbane. A customer record may be shared, while appointments, available technicians and parts allocations belong to a workshop. A customer who uses two workshops should not automatically require duplicate identities. List the relationships between customer, job and location. Decide whether staff can transfer work and which information travels with it. Make the destination visible before the transfer is confirmed, and provide a clear owner for jobs that are in transition between teams.

Keep the active location visible

A location selector hidden in a menu can lead to work being entered against the wrong branch. Show the active context near the task title and repeat it in consequential confirmations. Search should explain whether it covers the current branch or the whole business. Reports should label their scope and time boundaries. MDN documents explicit time-zone formatting, but the application still needs a business rule for which location governs a deadline. A central coordinator may need both the local appointment time and a clear indication of the relevant time zone.

Model access beyond a single role name

A branch manager may manage one location without having the same authority across every location. OWASP's authorisation guidance supports checking access against the relevant resource and context. Translate that into explicit rules for shared records, local work and transfers. Avoid relying only on a selected branch in the browser to enforce access. Test direct links, exports and background integrations as well. A company-wide administrator may need a broad view, but routine users should receive the scope required for their actual responsibilities.

Rehearse a cross-branch customer journey

Create a fictional customer with jobs at two locations, then transfer one job and produce a combined report. Check that the identity stays coherent while local responsibilities remain clear. Document:

  • Which records are shared and which are owned by a location.
  • How the active branch and time context appear in the interface.
  • Who can transfer work and when the receiving team becomes responsible.
  • How permissions and reports behave across local and company-wide views.

Further reading

Discuss your software project with 110s

Related Insight