AI app guides
Design a service app for multiple locations without mixing records
Decide which settings and customer records belong to a branch, and what the central owner may see.
Zocri · 2 min read · Sources checked
Decide what belongs to a location
Supabase's row-level security documentation describes database authorization that can restrict which records a user accesses. For a multi-location service app, the rule must be explicit. A booking may belong to one branch, while a customer can visit several. Opening hours and staff availability may differ by location even when service names and brand styling are shared across the business.
Create a map of shared and local information. Identify which role edits each item and whether a change applies immediately everywhere. A central price change may need a different approval process from a branch manager marking a staff member unavailable for an afternoon.
Make the chosen location visible
Show the location near actions that depend on it, such as requesting a service or assigning a job. Preserve the context when moving between list and detail pages. A hidden location filter can lead staff to create a correct-looking record for the wrong branch.
Decide what happens when someone switches locations with an unfinished form. The app might keep the draft attached to its original branch or ask for a deliberate change. Avoid silently moving the draft while leaving its staff choice or availability information tied to the previous location.
Separate access from filtering
A branch selector can make the interface convenient, but it does not establish permission. Define whether a branch employee may read other locations, whether a manager oversees several and what a central owner may change. Include both records and attachments in those rules.
Test direct links using accounts from different branches. A person should not obtain unauthorized information merely by replacing a record identifier or reopening a link someone shared. Also test a legitimate cross-location role so restrictions do not prevent the oversight the business actually requires.
Plan transfers and central reports
If a request moves to another location, record the transfer and decide who accepts responsibility. Keep the customer informed of any changed address or time. Preserve the original history so staff can explain why the request appears in a different branch's queue.
For central reporting, state whether counts reflect the original branch, current branch or completed-service branch. These can produce different totals after transfers. Reconcile sample records before trusting the dashboard. A multi-location app is useful when local work stays clear and central comparisons use consistent definitions.