Role Permissions and Data Security Settings for Catering Scenarios

Written By Natalia Povrozniak (Administrator)

Updated at July 13th, 2026

Table of Contents

Data Security permissions Operational vs. Non-Operational Permissions Role Permissions

Catering in IBSS relies on a combination of Data Security settings and Role Permissions to control what users can see, create, edit, and manage. This article explains the permissions required for common catering scenarios, including order creation, configuring catering, template management, approvals, cost code assignment, and operational administration. By assigning the appropriate permissions to roles or individual users, administrators can ensure that end users, catering teams, and managers have the appropriate level of access while maintaining security and operational control.

Data Security permissions

Data Security permissions in the IBSS platform determine exactly which records a user can see and modify. For catering operations, system access relies on object-level CRUD permissions scaled from 0 to 3, allowing organisations to precisely separate standard employees from operational management:

0 = None: The user cannot view or interact with this data asset at all.
1 = Basic: The user can view existing data records, but only if they are the creator or owner of that record.
2 = Local: The user can view and access data records created by anyone sharing the same organisational role as them.
3 = Deep: The user has full master control to create, read, update, or delete records belonging to anyone across the entire organisation.

Operational vs. Non-Operational Permissions

To browse menus, view available items, and select options, all users interacting with the catering module require a baseline access configuration. Beyond this foundational visibility, permissions split dynamically based on corporate responsibility:

Non-Operational End Users (Bookers): Typically granted Level 1 (Basic) or Level 2 (Local) access strictly on CateringOrders and CostCodes. This allows them to create, view, and manage their own orders attach cost codes, while the backend configurations remain protected.
Operational Users (Admins / Kitchen / Catering Managers): Granted Level 3 (Deep) master access across all data models. This ensures operational and kitchen teams can view, edit, override, and fulfil orders for any space or employee system-wide, as well as structurally configure underlying menus, restrictions, and other parameters.

Access Goal & Operational Impact	Required Permission	Operational CRUD	Non-Operational CRUD
Create a basic catering order Lets a user attach, update, view, or cancel catering requests on their specific room booking.	CateringOrders (DATAMODEL)	Full CRUD (Can view and alter any user's order at any time).	Restricted CRUD (Can only create, edit, or delete their own orders before the cut-off).
Set up catering templates in OneLens Lets a user build and manage reusable templates for recurring space hospitality arrangements.	CateringTemplates (DATAMODEL) ONELENS.OperationalServices. Catering	Full CRUD required to design and iterate reusable menu packages.	❌Block. But must have Read capabilities.
Manage catering orders across the entire organisation Grants administrative oversight over all orders system-wide, breaking the boundary of individual space bookings.	CateringOrders (DATAMODEL) ONELENS.OperationalServices. Catering	Full CRUD required for central kitchen fulfilment, tracking, and manual overrides.	❌Block
Link catering templates to global booking policies Allows a user to anchor specific automated templates directly into space booking policies.	BookingPolicies (DATAMODEL)	Full CRUD needed by IT/Platform Admins to tie automated food rules to physical workspaces.	❌Block
View and assign cost codes for financial tracking Allows a user to manage cost codes and cross-reference them against specific catering expenses.	• CostCodes (DATAMODEL) • API.CostCodes.V2 • API.Catering.AssignCostCode	Read-Only (Can select assigned codes for their order).	Read-Only (Can select assigned codes for their order).

Role Permissions

While Data Security models control fundamental access to records, Role Permissions control the specific actions a user can undertake within the platform. These permissions are assigned directly to user via the roles they are assigned and enable specific system behaviours, ranging from basic multi-ordering capabilities for standard employees to administrative overrides and operational tools for operational users.

Access Goal & Operational Impact	Required Permission	Operational CRUD	Non-Operational CRUD
Create multiple catering orders simultaneously Lets a user place more than one catering order at a time (e.g., adding a manually created afternoon refresh after a morning automated beverage tray).	API.Catering.MultipleOrders	Should be granted if multi-ordering is authorised for non-operational users.	Granted if multi-ordering is authorised for their profile.
General catering access Gives access create catering orders	• API.Catering.V2	Must be granted if non-operational users are provided access.	Granted, if user should be able to make catering orders.
Set up general catering configurations (Global Ops) Gives access to configure the backend logistics: menus, items, suppliers, restrictions, and core fulfilment rules.	•ONELENS360.OperationalServices.Catering • CRUD for: CateringOrderPolicies, CateringMenus, CateringMenuItems, CateringRestrictions, CateringSuppliers, CateringOrders	Must be given permission and full CRUD to be able to configure and maintain catering information.	❌Block (No access). ⚠️But must have Read capabilities to the Data.
Set up catering templates in OneLens Lets a user build and manage reusable templates for recurring space hospitality arrangements.	• ONELENS.OperationalServices. Catering • CateringTemplates (DATAMODEL)	Full CRUD required to design and iterate reusable menu packages.	❌Block. But must have Read capabilities.
Manage catering orders across the entire organisation Grants administrative oversight over all orders system-wide, breaking the boundary of individual space bookings.	• CateringOrders (DATAMODEL) • ONELENS.OperationalServices. Catering	Full CRUD required for central kitchen fulfilment, tracking, and manual overrides.	❌Block
Approve catering orders Allows a user to authorize pending catering orders before they lock and move to the kitchen queue.	API.Catering.Approve	Assigned specifically to Catering Managers to process orders under strict approval workflows.	❌Block
Receive automated alerts for new catering orders Designates a user as the focal point for specific spaces, routing system and email notifications when orders drop.	Assigned as Catering Manager inside the space-associated Booking Policies.	Assigned to local kitchen or facilities teams responsible for those specific rooms.	❌N/A
View and assign cost codes for financial tracking Allows a user to manage cost codes and cross-reference them against specific catering expenses.	• CostCodes (DATAMODEL) • API.CostCodes.V2 • API.Catering.AssignCostCode	Read-Only (Can select assigned codes for their order).	Read-Only (Can select assigned codes for their order).
Bypass kitchen cut-off times (Emergency Exceptions) Allows privileged roles to force an order addition, update, or cancellation past the operational deadline.	API.Catering.IgnoreCutOff	Granted to select supervisor roles to handle emergency executive meeting requests.	❌Block (System will reject edits past deadline).
Export or import catering menu items Enables bulk loading or archiving of menu items using system spreadsheets.	API.CateringMenuItems.Export/Import	Executable tool for Operational Managers maintaining menus.	❌Absolute Block.
Download catering reports Grants clear access to aggregate data files for business analytics, metrics tracking, and accounting.	ONELENS360.CateringReports.Download	Granted to analysts, kitchen managers, and workspace administrators.	❌Absolute Block.

Data Security permissions

Operational vs. Non-Operational Permissions

Role Permissions

Related Articles