NX: Enterprise

One configuration, many venues — and room for every venue to be itself

Executive summary

Multi-location operators face the same tension everywhere: the brand needs consistency, and each location needs latitude. Configure every venue independently and the brand drifts — prices diverge, the menu reads differently in every town, and a single policy change becomes fifty pieces of work. Configure them identically and you deny the differences that are actually real: a different tax rate, a different kitchen, a different lunch crowd.

NX Enterprise resolves that tension with inheritance. Your enterprise holds one master version of each record — a menu item, an area, a discount. Every venue follows it automatically. When a venue genuinely needs something different, it overrides only the specific settings that differ and keeps following the enterprise on everything else.

The result is a system where the enterprise standard is the default rather than a suggestion, local exceptions are visible rather than hidden, and changing something once changes it everywhere it has not been deliberately overridden.

This paper describes how that model works, what it means for day-to-day operations, and how to govern it well.

Contents

1. The problem with the alternatives
2. The model: three questions
3. Inheritance in practice
4. Working at the enterprise level
5. Working at the venue level
6. Editing several venues at once
7. Availability: which venues get the record at all
8. Settings that only a venue can own
9. Making changes land at the right moment
10. Governing an enterprise well
11. Good to know
12. Glossary

1. The problem with the alternatives

Before describing what NX does, it is worth being precise about what it avoids.

Copying records to each venue is the most common approach and the most expensive. Every venue gets its own copy of every menu item. The copies start identical and diverge the moment anyone touches one. A year later nobody can say which differences were intentional. A price change becomes a project.

Forcing every venue to be identical is cheaper to run and wrong in practice. Tax varies by jurisdiction. One kitchen has a fryer and another does not. A venue in an airport does not keep the same hours as one on a high street. Denying those differences pushes staff into workarounds that are worse than the differences would have been.

Inheritance takes the useful half of each. There is exactly one master record, so a change made once is a change made everywhere. And a venue can differ — but only where it has said so, and its difference is recorded as an explicit exception rather than an accident of history.

2. The model: three questions

Every record in NX Enterprise answers three separate questions. Keeping them separate is the key to understanding the whole system.

These are genuinely independent. A record can be available at every venue while only one venue overrides its price. A record can be restricted to three venues, all of which use the enterprise values unchanged. Confusing availability with overrides is the single most common misunderstanding, so it gets its own section below.

3. Inheritance in practice

The enterprise record is the source of truth. A venue override is not a copy of it — it is a short list of exceptions.

Consider a menu item, Classic Burger, defined at the enterprise level:

The airport venue charges more. It overrides one setting:

That is the entire override. Everything else is inherited, and the word "inherited" is meant literally: those values are not stored on the venue at all. They are read from the enterprise every time.

This has a consequence worth stating plainly, because it is the whole point of the system:

When you change the enterprise value, every venue that has not overridden that setting changes with it — immediately. Rewrite the description and all fifty venues get the new description. Change the price and forty-nine venues get the new price; the airport keeps its $16.50, because it asked to.

The corollary matters just as much. An override is a standing decision to stop listening. A venue that overrode the price two years ago will not receive this year's price change. That is correct behaviour — it is what an override means — but it is why the enterprise needs visibility into who has overridden what, which is the subject of the next section.

4. Working at the enterprise level

Open any record from an enterprise context and you are editing the master. The header offers a choice between Enterprise Settings and Venue Settings; Enterprise Settings is where you set the standard.

📸 Screenshot: a record open in Enterprise Settings, with the Enterprise / Venue toggle in the header and a settings form beneath it.

The important feature of this view is not the editing — it is the reporting. Any setting that venues have diverged on carries a badge:

3 Venue Overrides

That badge is your governance tool. Before changing an enterprise value, it tells you how much of your estate will actually receive the change. A price with no badge will reach every venue. A price carrying "12 Venue Overrides" will reach considerably fewer, and those twelve venues will need handling separately if the change is meant to be universal.

Read the badges before a rollout, not after.

5. Working at the venue level

Switch to Venue Settings and choose a venue, and the same form now edits that venue's exceptions.

Settings the venue has not overridden are shown but not active. Instead of a value you have typed, you see the value being inherited — the actual enterprise value, so you can see what you are choosing to depart from before you depart from it.

📸 Screenshot: a record in Venue Settings for a single venue, showing a mix of overridden fields and inherited ones displaying the enterprise value.

To override a setting, enter a value. For most settings that is all it takes: a typed value is an override.

Some settings need to be explicit about it. For on/off switches, colours, and lists of things, an empty value is genuinely ambiguous — "off" and "not specified" look identical, and so do "no items" and "no opinion". Those settings carry an Override checkbox. Tick it and the venue takes control of that setting; leave it clear and the venue keeps following the enterprise.

To hand a setting back, clear the value — or untick the Override checkbox. The venue resumes inheriting immediately, and will pick up the current enterprise value along with every future change to it. There is no separate "reset" action to hunt for; emptying a setting is the reset.

6. Editing several venues at once

Venue Settings accepts more than one venue. Select five and you are editing all five together, which turns a repetitive job into a single decision.

The form has to describe five records at once, so it reports what it finds:

• Where the selected venues agree, you see their shared value.
• Where they disagree, you see Various. Nothing has been changed; the form is telling you the venues are not currently aligned on that setting.

Typing a value applies it to every selected venue. Leaving a Various setting alone leaves each venue's own value alone — you can align three settings across five venues without disturbing the things those venues legitimately do differently.

📸 Screenshot: Venue Settings with several venues selected, showing a "Various" tag on a setting the venues disagree on.

This is the right tool for regional work: the six venues in one state need the same tax treatment, the four venues with a drive-through need the same prompts. Select the group, make the change once.

7. Availability: which venues get the record at all

Overrides answer what values a venue uses. Availability answers a different question: should this venue have this record in the first place?

Every enterprise record carries an Available at setting.

• Leave it empty and the record is available at every venue — the normal case.
• Name specific venues and the record exists only for them.

A seasonal cocktail that only three venues serve, a discount that applies to one region, a menu item that needs a piece of equipment most kitchens do not have — all of these are availability decisions, not override decisions. The record simply does not exist for venues outside the list.

📸 Screenshot: the Available at / Unavailable at controls in the record header.

The distinction matters because the two are easy to confuse and behave very differently:

A record that a venue should not sell is an availability decision. A record a venue sells at a different price is an override. Reaching for the wrong one produces confusing results: hiding an item by blanking its settings leaves an odd empty record in place, and restricting availability to fix a price leaves other venues without the item entirely.

8. Settings that only a venue can own

A few settings have no sensible enterprise value, because they describe physical reality at one location rather than policy across the business. These appear only when you are working in Venue Settings.

The clearest example is stock. On Hand counts and the Out of Stock switch belong to a single kitchen — an enterprise-wide "out of stock" would be meaningless, because running out is a local event. The same logic applies to a venue's payment processing account and its floor plans.

When you meet one of these in the enterprise view, it will tell you it is set per venue. That is by design, not an omission.

9. Making changes land at the right moment

Configuration changes usually need to take effect at a particular time — a price rise at the start of the month, a seasonal menu on a Monday, a new tax rate the day the law changes.

Scheduled Changes lets you prepare a change now and have NX apply it later. You make the edits as normal, then schedule them for a date and time instead of saving immediately. Related changes can be grouped into a single batch so that a whole seasonal switchover lands together rather than trickling in as each person gets to their part of it.

📸 Screenshot: the Schedule dialog, showing the choice between adding to an existing batch and setting a new date and time.

Two points worth noting:

• Scheduling does not lock the record. Saving normally in the meantime applies immediately and does not cancel anything queued.
• Scheduled changes are reviewable before they run, on the Scheduled Changes page.

10. Governing an enterprise well

The mechanics are straightforward. Using them well is a matter of a few habits.

Set the standard first, at the enterprise. Every setting you establish centrally is one that new venues inherit correctly on their first day, with no onboarding step and no chance of being missed.

Treat every override as a decision with a reason. An override is a permanent opt-out of future enterprise changes. That is often exactly right — but "we changed it once and forgot" is how estates drift back into fifty independent configurations. If a venue's difference is not deliberate, it should not be an override.

Read the override badges before a rollout. They tell you, in advance, how much of the estate a change will actually reach. A setting with many overrides needs a plan for those venues, not just a new enterprise value.

Prefer availability to blanking. If a venue should not have something, say so with Available at. Do not approximate it by emptying settings.

Periodically ask whether an override should become the standard. When most venues have overridden a setting the same way, the enterprise value is the one that is wrong. Move it to the centre and clear the overrides — the estate gets simpler and future changes reach further.

Use multi-venue editing for groups that genuinely belong together. Regional tax, format-specific prompts, equipment-driven routing. It is faster and, more importantly, it keeps the group aligned.

11. Good to know

• Changing an enterprise value reaches non-overridden venues immediately. There is no publish step and no sync to wait for.
• Deleting an enterprise record removes its venue overrides too. The overrides describe exceptions to that record; without it they have nothing to modify.
• Clearing a setting at the venue is how you return it to enterprise control. There is no separate reset.
• A venue working in its own context sees the merged result — enterprise values with its own overrides applied — which is what the POS and your ordering pages use.
• Records shared across venues are protected from local deletion. A venue cannot delete or copy a record that other venues depend on; NX explains why when it declines.
• Overrides apply per setting, not per record. A venue that overrides a price still receives every future change to the name, description, routing, and everything else it has not claimed.

12. Glossary

Enterprise — the business that owns the records. The level at which standards are set.

Venue — an individual location.

Enterprise record — the master version of a record. One per enterprise.

Override — a venue's deliberate exception to one setting on an enterprise record. Everything not overridden continues to be inherited.

Inherit — to follow the enterprise value for a setting, including all future changes to it.

Available at / Unavailable at — which venues a record exists for at all. Independent of overrides.

Various — shown when several venues are selected together and they do not currently agree on a setting.

Enterprise Settings / Venue Settings — the two modes for editing a record: the master, or a venue's exceptions to it.

Scheduled Change — an edit prepared now and applied automatically at a chosen date and time.

This document describes behavior in the NX Portal. Screenshots and control labels may change as the product progresses.