Kitchen Staff Permissions: Who Should See What
Giving your whole team the keys to everything is easy — and it is usually a mistake. Your recipe costings, margins and pricing are commercially sensitive, and a single accidental edit to a live recipe can ripple through your labels and orders. Good team access control means each person can see and change exactly what their role requires, and nothing more. This guide explains why kitchen staff permissions matter, how to map roles to access, and how FoodCore's per-user None / View / Edit permissions make it practical.
Why access control matters in a kitchen team
In a small food business it is tempting to treat every login the same. Everyone is trusted, everyone mucks in, so everyone gets full access. But access control is not about distrust — it is about reducing avoidable risk and protecting the parts of your business that shouldn't be casually editable. There are three reasons it matters.
Accountability. When each team member has a defined level of access, you know who was able to change what. If a recipe cost is altered or a menu is changed, the set of people who could have done it is limited to those with edit rights. That clarity is the foundation of accountability in any team.
Protecting costings and pricing. Recipe costings, gross margins and selling prices are commercially sensitive. A junior chef needs to follow the spec for a dish, but does not necessarily need to see what it costs you to make or what margin you take. Keeping that information restricted to managers and owners protects it — whether the concern is casual conversation, a departing employee, or simply keeping focus on the food rather than the finances.
Preventing accidental edits. The most common problem in shared systems isn't malice — it's the accidental change. Someone opens a recipe to check a quantity, nudges a field, and saves without realising. If that recipe drives your allergen data and labels, the accidental edit has real consequences. Limiting edit rights to the right people removes most of that risk.
Mapping kitchen roles to access
Access should follow responsibility, not seniority for its own sake. The starting point is to think about what each role actually does day to day, then decide which features they need to change (Edit), which they only need to see (View), and which they don't need at all (None). Here is how the common kitchen roles typically map.
Head chef
The head chef owns the food. They usually need Edit access across recipes, menus and ingredients so they can develop dishes, adjust specs and manage the menu. In many small businesses they will also see costings, because they are responsible for keeping dishes profitable. The head chef is the role most likely to have broad Edit access.
Chef / line chef
A chef needs to follow and maintain recipes but rarely needs to change ingredient costs. A common, sensible setup is full recipe access with read-only ingredients — they can see exactly what goes into a dish and update method, but the underlying ingredient costs and supplier detail stay locked. This protects your costing data while giving the chef everything they need to cook to spec.
Kitchen porter / junior
A kitchen porter or junior team member usually only needs to see information — prep lists, recipes, production schedules — not change it. View access across the relevant features lets them work from the system without any risk of altering it. There is no reason to expose costings or editing controls to a role that doesn't need them.
Manager
A front-of-house or general manager often needs Edit access to costings, orders and reporting, but not necessarily to recipe development. Their access is almost the mirror image of the junior chef: strong on the commercial and operational side, lighter on the kitchen-craft side. This is exactly why per-feature control matters — a single "manager" template rarely fits.
These are starting points, not rules — the value of per-feature permissions is that you can adjust any cell to fit the actual person in the role. To see how this connects to the rest of your team's day-to-day tools, the FoodCore kitchen management software page shows recipes, orders, production and users in one place.
None / View / Edit: per-feature permissions in FoodCore
FoodCore lets you give each team member None, View or Edit access per feature, set from Users → Customise. Rather than assigning a fixed job title with a bundled set of rights, you decide feature by feature what each person can do:
- None — the feature is hidden entirely for that user. If a kitchen porter has None on ingredients, they simply don't see it.
- View — read-only. The user can see the information but cannot change it. Ideal for a chef who needs to reference ingredient specs without editing costs.
- Edit — full access to view and change. Reserved for the people responsible for that feature.
Because this is set per feature, a single person can have Edit on recipes but View on ingredients — the classic "chef with full recipe access but read-only ingredients" setup. Their access reflects exactly what their role requires, rather than an all-or-nothing switch that forces you to over-grant just to make one feature work.
What read-only mode actually looks like
A common weakness in software permissions is the "fake" read-only — where a user can open a form, type into it, hit save, and only then get an error. That is frustrating and it undermines trust in the system. FoodCore's read-only access is genuine: pages viewed with View permission grey out the forms and hide the editing buttons instead of failing at save.
In practice, that means a team member on View access sees the information cleanly, immediately understands they are looking rather than editing, and never loses work to a blocked save. It also removes the accidental-click risk — there is no live "delete" or "save" button waiting to be pressed by someone who wasn't meant to change anything.
Protecting costings and pricing specifically
For most food businesses, the single most important thing to lock down is commercial data — ingredient costs, recipe margins and selling prices. The approach is straightforward: set the cost-bearing features to View or None for staff who don't need them. A chef can have Edit on recipes so they maintain method and ingredients, while their access to ingredient costs is set to View or None so margins and pricing stay confidential. Managers and owners keep Edit where they genuinely need to manage the numbers.
Because FoodCore applies permissions per feature, you don't have to choose between giving a chef the recipe access they need and exposing the costs you'd rather keep private. You can expose the operational detail and restrict the commercial detail on the same account.
Onboarding new staff safely
Access control earns its keep most clearly when someone new joins. The safe pattern is simple: start a new team member with the minimum access their role needs, and widen it as they take on responsibility and earn trust.
- Give a new chef View access across most features so they can learn the system without any risk of changing something.
- Once they are trusted with recipe maintenance, move recipes to Edit while keeping ingredient costs on View.
- Keep costings, pricing and orders restricted until the role genuinely requires them.
- Review each person's access periodically, and tighten it immediately when someone changes role or leaves.
Because read-only pages grey out forms and hide editing buttons, a new starter on View access can explore the whole system safely — a genuinely useful way to train someone without a supervisor hovering over every click. Set all of it from Users → Customise, adjusting each person individually.
Kitchen staff permissions: frequently asked questions
Why does access control matter in a kitchen team?
Access control matters for three reasons: accountability, protecting commercially sensitive information, and preventing accidental edits. When each team member has a clearly defined level of access, you know who can change what — which supports accountability. Sensitive data such as recipe costings, margins and pricing can be kept away from staff who don't need it. And limiting edit rights to the people responsible for a feature prevents a well-meaning team member from accidentally changing a recipe, an ingredient cost or a menu they were only meant to look at.
What kitchen roles need different levels of access?
Typical kitchen roles map to different access needs. A head chef usually needs Edit access across recipes, menus and ingredients. A chef might have full recipe access but read-only ingredients so they can follow specs without changing costs. A kitchen porter or junior may only need View access to prep lists and recipes. A manager often needs Edit access to costings and orders but not necessarily to recipe development. In FoodCore you set None, View or Edit access per feature for each user, so you can match access to the role rather than using fixed job templates.
What do None, View and Edit permissions mean in FoodCore?
FoodCore lets you give each team member None, View or Edit access per feature, set from Users then Customise per feature. None hides the feature entirely for that user. View gives read-only access — they can see the information but not change it. Edit gives full access to view and change. Because permissions are set per feature, one person can have Edit on recipes but View on ingredients, so their access reflects exactly what their role requires rather than an all-or-nothing switch.
What does read-only mode actually look like for staff?
Read-only access in FoodCore genuinely looks read-only. Pages viewed with View permission grey out the forms and hide the editing buttons, rather than letting someone fill in a form and then failing at save. That means a team member with View access sees the information cleanly, understands they are looking rather than editing, and never loses work to a blocked save. It also removes the temptation and the accidental-click risk that comes with showing edit controls to someone who isn't meant to use them.
How do I protect recipe costings and pricing from staff?
Set the relevant features to View or None for staff who don't need cost visibility. For example, a chef can have Edit access to recipes so they can maintain method and ingredients, while their access to ingredient costs is set to View or None so margins and pricing stay confidential. Because FoodCore applies permissions per feature from Users then Customise, you can expose the operational detail a role needs while keeping the commercial detail restricted to managers and owners.
How should I onboard a new kitchen staff member safely?
Start new team members with the minimum access their role needs and widen it as they take on responsibility. Give a new chef View access across most features so they can learn the system without risk of changing anything, then move recipes to Edit once they are trusted with recipe maintenance. Because read-only pages in FoodCore grey out forms and hide editing buttons, a new starter on View access can explore safely. Set all of this from Users then Customise per feature, adjusting each person individually.
Does access control replace management responsibility?
No. Permissions are a control that supports good management — they reduce the risk of accidental edits and keep sensitive data restricted — but they do not replace training, supervision or your legal responsibilities as a food business. FoodCore assists with access control by letting you set None, View or Edit per feature, but you remain responsible for deciding who should have what access and for the food-safety and business decisions your team makes. The software enforces the boundaries you set; it does not set them for you.
How much does FoodCore cost and does it include permissions?
FoodCore starts from £19/month on the Essentials plan and £55/month on the Core plan, which adds full kitchen management and order tracking. Per-user feature permissions let you set None, View or Edit access per feature for each team member. There is a 7-day free trial with no card required, so you can add your team, set their permissions and see how read-only mode behaves before committing.
Further resources
FoodCore is kitchen management software built for small UK food businesses. We handle recipe costing, Natasha's Law labels, allergen matrices, order tracking and per-user team permissions.
Start free trial →