Cibuscibus.
Platform controls for restaurant groups

Manage restaurant locations, access and reporting from one login.

Keep per-restaurant menus and settings explicit, limit authorised users to assigned restaurant scope, and review cross-location reporting and team management from the Cibus group workspace.

Discuss group controlsFor multi-location operators
Group dashboard
Borough & Vine · all sites
Illustrative
Borough & Vine · Borough
BV-LDN
Staff on: 14Open
Borough & Vine · Shoreditch
BV-SHO
Staff on: 11Open
Borough & Vine · Islington
BV-ISL
Staff on: 6Prep
Menu rollout
Winter menu · pending per-site confirmation
2 of 3 sites confirmed
1group view

Configured sites appear in one group operating view.

1menu source

Push menu and price changes from one place.

1role model

Scoped, capability-aware access per site.

1change context

Supported group actions record who and when.

Control gaps

Where group governance breaks down

Unclear configuration inheritance
Teams cannot tell whether an item, price or availability rule comes from the group or the location.
Overrides without governance
A necessary local change becomes a second master record with no clear owner or review path.
Access scoped too broadly
Venue managers either lack the tools they need or can see and change more locations than their role requires.
Reports built from different definitions
Group comparisons lose meaning when locations classify orders, shifts and payment activity differently.
Channels ignore local constraints
A group change can conflict with local opening hours, fulfilment rules, consent state or item availability.
Configuration model

From implicit rules to explicit scope

Per-site stacks
  • Configuration ownership is implicit
  • Local changes create parallel masters
  • Permissions are copied venue by venue
  • Reports use inconsistent dimensions
  • Channel rules drift from site operations
With Cibus
  • Configured restaurants managed from one login
  • Per-restaurant menus and settings remain explicit
  • Access follows assigned restaurant scope and capabilities
  • Authorised cross-location records use common report definitions
  • Customer-channel requirements remain visible per restaurant
Control workflow

How group configuration moves into service

  1. 01Model
    Confirm the authorised restaurant scope
    Record which restaurants the operator manages and the operating settings each location needs.
  2. 02Govern
    Keep restaurant configuration explicit
    Manage each restaurant's menu and settings in the group workspace; document any approved shared-template behaviour.
  3. 03Authorise
    Grant capabilities at the required scope
    Match assigned restaurant access and capabilities to the work each role is expected to perform.
  4. 04Operate
    Connected surfaces read the configured scope
    POS, KDS, payments and Storefront use the relevant restaurant configuration and documented local differences.
  5. 05Review
    Compare records using common definitions
    Move from group view to a location record without losing the reporting context.
  6. 06Trace
    Review supported administrative activity
    Use available actor, time and scope context when investigating configured menu, role and price actions.
Platform capabilities

Controls for a governed restaurant group

•
Per-restaurant menu and settings management
Manage each configured restaurant's menu and operating settings from the group workspace; confirm any shared-template or override model during discovery.
•
Comparable group reporting
Review configured service, sales and shift records across locations using the same reporting definitions.
•
Location-aware permission scope
Limit users through assigned restaurant scope and supported capabilities. Confirm any cluster or subgroup hierarchy during discovery.
•
Location-aware customer channels
Keep the menu, availability and fulfilment requirements for each configured Storefront ordering route explicit.
•
Audience and campaign scope
Prepare Reach activity only for authorised, consent-eligible records in the approved restaurant scope.
•
Partner portfolio boundaries
Give authorised partners scoped access to assigned restaurants without exposing the wider group or unrelated tenants.
Governance

Scoped access and tenant isolation

✓
Supported change records across sites
Configured menu, role and price actions record actor and time where that activity event is implemented.
✓
Scoped data controls
Configured restaurant and group scope is enforced through database and application access controls.
✓
Scoped access by role
Authorised users are limited by assigned restaurant scope and capabilities.
Example control flow

A group change with location context

  1. Mon 09:00
    Operations prepares menu changes for selected restaurants
    The team reviews restaurant scope and documented local requirements before applying changes.
  2. Mon 11:00
    One restaurant records an authorised local setting
    The price or availability difference remains visible in that restaurant's configuration.
  3. Tue 14:00
    An authorised operator reviews assigned locations
    Restaurant scope and capabilities limit the records and actions available in the group workspace.
  4. Wed 10:00
    The group report uses common definitions
    The operator can move from the aggregate view into a location record to understand a difference.
  5. Fri
    Supported change context is reviewed
    Authorised users inspect the available actor, time and scope details for the configured action.
One group

Not a separate stack per restaurant. One operating layer across configured sites.

Menus, roles, reporting and governance use group and location scope, with supported action records and tenant isolation.

Connected platform

What this connects to

Multi-Location solution
The buyer view of how multi-site operators run on Cibus.
Solution
Sales Agent Portal
For partner-managed groups: scoped portfolios, commissions and onboarding.
Partner
Security & compliance
Roles, scoped access, tenant isolation and supported activity records.
Platform
FAQ

Restaurant group control questions

How do group defaults and location overrides work?

Each configured restaurant can retain its own menu and settings in the group workspace. Shared-template and per-item override behaviour is confirmed against the group's requirements during discovery.

Map your group hierarchy, controls and reporting requirements.

See how Cibus connects service, kitchen operations, payments, reporting, customer engagement and delivery into one restaurant operating system.

Discuss group controlsFor multi-location operators