Multi-branch merchants: staff roles, branch visibility and point permissions

Why multi-branch merchants need their own model

A merchant with more than one branch cannot be modelled as a single shop with a single login. Offers apply at some branches and not others, staff work at one location, and a branch may be ready to open in the app weeks before another. If the app treats the whole business as one unit, the owner ends up sharing a password with every cashier and shoppers see offers at branches that do not honour them.

The fix is to separate four things that small apps often blur together: the business, its branches, the people who work there and what each person may do. Once those are separate records, most multi-branch requirements become simple settings rather than special cases.

T-CODE, the offers and loyalty app FLUIDS designed and built, takes this approach. A merchant sets up a store profile and adds branches, showing or hiding each one as it is ready. Its merchant role model includes an owner and staff, staff branch assignments, and separate permissions for granting and redeeming loyalty points. Staff can have a branch assignment and counter access without receiving the owner's full management role.

The store, branch and staff data model

A clean multi-branch model needs only a handful of entities. Each one answers a question the app will be asked every day:

• Merchant application: who applied, and has the platform approved them? In T-CODE, approval comes before a shop is created.
• Store: the business as shoppers know it, with its name, category, contact details and profile.
• Branch: a physical location with coordinates, contact details and a visibility flag. Offers, menu items and staff attach here.
• Membership: a link between a person and the store, with a role (owner or staff) and, for staff, a branch assignment.
• Permissions: specific actions a staff member may perform, such as confirming codes, granting points or redeeming points.

Attaching data to the branch rather than the store pays off quickly. In T-CODE, offers are published for a branch, and menu items can be specific to a branch, which matters when two locations sell different things. A point-based cart is prepared for a shop branch; tying the cart to a branch means the counter that confirms the sale can be the one that hands over the order.

Owner and staff roles: a permissions table

The simplest working model is one owner role with full control and a staff role whose abilities are switched on individually and limited to the assigned branch. The table below is a recommended starting point, not T-CODE's exact configuration; it builds on the separation T-CODE makes between granting and redeeming points:

Some businesses will want a middle role, such as a branch manager who can edit offers for one branch. Add it only when a real merchant needs it; every extra role multiplies the cases you must test. Whatever the matrix, show staff only the screens they can use, so a cashier never sees a publish button that will fail.

Branch visibility: showing or hiding each branch

Each branch should have its own visibility switch, because branches are rarely all ready at once. A new location may be set up in the app before it opens, a branch may close for renovation, or the owner may want to test the setup on a trial branch first. T-CODE lets merchants add branches and show or hide each one as it is ready.

Hiding a branch should have predictable effects:

• Discovery: the branch disappears from the map, lists and search for shoppers immediately.
• Offers: offers limited to that branch stop being reservable while it is hidden.
• Open reservations: follow a stated rule, either honoured until expiry or cancelled with a notice to the shopper.
• History: past redemptions, point grants and statements for the branch stay intact for the owner.
• Staff: assigned staff keep their accounts, so the branch can reopen without re-inviting everyone.

Hiding is not deleting. A deleted branch takes its history with it and breaks the merchant's reports; a hidden branch keeps its records and can come back with one switch.

Why granting and redeeming points are separate permissions

Granting and redeeming points are separated for the same reason that businesses separate who records a sale from who approves a refund: one person should not control both ends of a value flow without oversight. If any cashier can both add points and spend them, a cashier can add points to a friend's wallet and redeem them for free items the same afternoon.

Separation alone is not enough; it works best with a few supporting rules:

1. Link grants to receipts. Every grant carries the receipt details, and the same receipt cannot earn twice.
2. Block self-service. Staff cannot grant points to their own customer wallet.
3. Record the actor. Every grant and redemption stores the staff member and branch.
4. Review statements. Owners read merchant statements and transaction views by branch and by staff member.
5. Keep counter logs. Point-of-sale logs show what was confirmed, by whom and when.

T-CODE includes several of these pieces: receipt-linked point grants, and merchant point statements and transaction views. The commercial side of points, including why they should stay a loyalty reward rather than money, is covered in building a loyalty points app. Service businesses face the same staff questions, as our clinic loyalty programme guide explains.

Implementing branch permissions safely

Permissions protect a business only when the server enforces them. Hiding a button in the app is good design but not security; anyone with a modified app or direct API access can call the action behind it. Every request that changes data should check three things on the server: who is asking, what role and permissions they hold, and whether the branch involved is one they are assigned to.

A few practices keep this manageable as merchants grow:

• One permission list. Define each permission once and reuse it in the app, the server and the tests.
• Branch-scoped queries. Staff queries return only their branch's codes, carts and transactions by default.
• Immediate revocation. When someone leaves, removing their membership must end their access at once, including on a phone that stays signed in.
• A test matrix. Automate a test for every cell in the permissions table, so a later change cannot quietly widen access.

If your business runs several branches and wants offers, loyalty and staff controls in one product, see the T-CODE case study, how the merchant offers dashboard presents branch numbers, and our custom software and marketplace platform services. FLUIDS agrees scope, price and timeline in a written proposal before development, and you own the source code.