Per-franchisee permissions with global visibility.

You define roles per tier and attach a set of permissions to each, then assign people and outlets to those roles. The matrix on this page shows the shape of it: franchisor, regional manager and franchisee down one axis, and areas of the business — menu management, pricing, staff administration — across the other, with each cell describing what that role may do in that area. In practice you make those cells as granular as you need: full edit, view-only, propose-but-not-publish, no access. Multi-outlet owners are the case worth thinking about, and the sensible pattern is inheritance — an owner holding several outlets gets a role that applies consistently across all of them rather than being wired up outlet by outlet, so that when you change what that tier can do, it changes everywhere at once. A regional manager role sits above the individual outlet and below head office, with visibility across a cluster and a deliberately narrower set of edit rights. Here is the important framing, and it is the point of this answer rather than a footnote: this is access control, and access control supports your franchise governance — it does not replace it. The matrix decides what a person can do inside Vertex. It does not decide what they are contractually permitted to do, what your franchise agreement obliges them to do, or what happens when someone does something they were allowed to click but not allowed to do. Those live in your franchise agreements and your legal governance, and the software should be configured to mirror them, not mistaken for them. Set the permissions to match the contract; keep the contract as the thing that actually governs. And review the mapping when the agreement changes, because a permission that quietly outlives the clause it was meant to enforce is worse than none.

That is your decision, and the honest answer is that the software makes either arrangement possible — the interesting part is where you draw the line and how far the line actually reaches. Because pricing sits in the permission matrix as its own area, you can lock it centrally, delegate it entirely to the outlet, or do the common middle thing: set a central framework and let outlets move within it. Regional pricing rules are workable too — a cluster of outlets in one market priced differently from another — configured at the regional tier rather than left to each site. So a network can run fully controlled prices, fully local prices, or bands and guardrails with local discretion inside them, and you choose which per area and per tier. The distinction to hold onto is between enforcement in software and enforcement in law, because they are not the same thing and this page can make them look identical. What Vertex enforces is what happens inside Vertex: if you lock a price, a franchisee without the permission cannot change it in the system. What Vertex does not do is govern the legal and commercial side of pricing between you and your franchisees — what you are permitted to mandate, what has to be left to the independent business that each franchisee is, and where competition or franchising law constrains how prices are set across a network. Those are real questions with real limits, and they belong with your franchise agreement and your legal counsel, not with a toggle. Use the software to make the arrangement you have chosen easy to run and hard to breach by accident; do not let the existence of a lock stand in for having thought through whether you are entitled to set it.

The audit surfaces on this page record what happened across the network so there is an account of it afterwards — the kind of thing you reach for when a franchisee asks who changed a price, or when a regional manager wants to know why an outlet's menu drifted from the master. Sensibly configured, that means permission changes (who was granted or removed what, and when) and store-level actions that matter for accountability, each carrying who did it and at what time. That is genuinely useful, and it is worth being precise about what it is: a log is a record of events, not a guarantee that the right events happened. It tells you a price was changed and by whom; it does not tell you the change was permitted, correct, or compliant with anything. Reading a full log as proof of a well-run network is a mistake — an empty log can mean nothing went wrong or that nothing was captured. The other thing on this page that deserves care is the compliance score. Treat it as exactly what it is: an internal health indicator, computed from criteria you define, to help you see at a glance where attention is needed. It is not an official rating, not a regulatory measure, not a certification, and a high number is not a defence to anyone. Please do not put it in front of a regulator, a franchisee or a court as evidence of compliance, and do not let a green score persuade anyone that a duty has been discharged. Configure the logs to capture what you would actually want to answer for later, decide who can see and export them, and know how long they are kept — and ask sales in writing what is logged by default, whether the log can be altered or deleted, and what retention controls you get, because a record you can quietly edit is not the record you thought you had.

Through the two surfaces this page gives brand governance: a central menu library and a brand asset hub, both owned at head office and both able to push updates outward. The idea is that the master version of a menu — items, structure, the pricing framework attached to it — and the master brand assets live in one place under central control, and when head office changes them the change propagates to the outlets rather than each site maintaining its own copy that slowly drifts. On this page the destinations named for those updates are the customer-facing boards, the POS and the apps, so a menu change made centrally is meant to reach the screen a customer reads, the till a member of staff rings up on, and the app an order is placed in. Combined with the permission matrix, this is how a network stays on-brand: outlets that do not hold menu-edit rights consume the central version rather than editing it, and the exceptions you do want — a locally available item, a market-specific price band — are the ones you deliberately delegate. One honest qualification, because the design implies a cleaner picture than physics allows. An update reaches an outlet when that outlet is online to receive it. A site that is offline, mid-update, or running on a screen that has not checked in gets the new version when it next connects, not at the instant you publish it — so treat propagation as reliable but not simultaneous, and expect a window during a rollout where different outlets are briefly on different versions. That matters most for anything time-sensitive, like a price change tied to a start date. Ask sales how a publish behaves for an outlet that is offline at the moment you push, whether you can see which outlets have taken an update and which have not, and whether you can schedule a change to go live rather than firing it the moment you click — because knowing the estate is genuinely consistent is worth more than assuming it.

No — and this is the answer to be most explicit about, because everything else on the page pushes gently the other way. A permission matrix, a compliance score, an audit log and a central command centre together create an impression of a network that is under control and therefore in the clear, and that impression is not something the software can stand behind. What these tools genuinely do is help you enforce standards you have already decided on, and keep records of what happened. That is valuable. It is also categorically different from being compliant. Franchise law governs the relationship between you and your franchisees and constrains what you may require of independent businesses. Labour law governs how the people in each outlet are hired, scheduled, paid and treated — and much of that is the franchisee's responsibility as the employer, which is itself a distinction with legal weight. Data law governs the personal information moving through the system, from staff records to anything customer-facing, with obligations about lawful basis, retention, access and security. None of these bodies of law is satisfied by a setting inside Vertex, and none is measured by a score the product computes. The compliance score is an internal health indicator you define; it is not a legal verdict, and treating it as one would be a serious mistake in front of anyone who matters. So: configure the software to mirror the standards and agreements you have, use the logs to keep an honest account, and treat the whole thing as an aid to running a controlled network — not as a substitute for legal advice. Whether your network actually complies with franchise, labour and data law in your jurisdictions is a question for your own franchise and legal counsel, and it is one worth asking before you rely on any of these tools, not after something has gone wrong.