Step-by-step instructions
A manager can create a reusable role, name it in every enabled language, save permission switches, and then assign that position to employees.
Use the interactive screenshot walkthrough first. Switch steps with the step dots, then read what to fill and why it matters.
Fields on this screen
Positions list
How to fill: Start from the list and check whether the role already exists.
Why: Duplicate roles make staff permissions hard to audit.
Add
How to fill: Click Add only when a new staff role is needed.
Why: The new draft must be named, translated, permissioned, and saved.
Management
How to fill: Enable it only for roles that should control or oversee company workflows.
Why: This is broad access and should not be given to ordinary operational staff.
Sales
How to fill: Enable it for cashiers, sellers, and managers who create or review orders.
Why: Without it, the employee may not see the sales/order interface they need.
Hall administration
How to fill: Enable it for floor managers, hosts, waiters, or anyone managing tables and dine-in service.
Why: Hall access affects dine-in operations and table workflows.
Courier
How to fill: Enable it only for delivery staff or courier coordinators.
Why: Courier access exposes delivery execution tasks.
Storage
How to fill: Enable it for warehouse, receiving, stock, or manager roles.
Why: Stock movements and inventory screens should be protected from unrelated roles.
Production / Kitchen
How to fill: Enable it for kitchen, workshop, or production staff.
Why: This role will need preparation queues and production context.
Self-service kiosk / Screen
How to fill: Enable it for terminal, kiosk, or screen operators.
Why: It controls access to screen-facing workflows.
Menu
How to fill: Enable it only for staff allowed to edit menu or catalog-related data.
Why: Menu changes affect products, prices, customer screens, and orders.
Supplier
How to fill: Enable it for procurement or purchasing roles only.
Why: Supplier access can affect vendor, supply, and purchasing data.
Show in customer interface
How to fill: Enable it only when the role should be visible to customers.
Why: Internal roles such as manager or warehouse worker should normally stay hidden.
Position name
How to fill: Enter a short role name in the active language.
Why: Employees and managers must recognize the role quickly.
Name translations
How to fill: Expand the name field and fill every enabled language.
Why: Multilingual companies need role names that match the selected interface language.
Save
How to fill: Save after permissions and translations are checked.
Why: Only saved positions can be assigned reliably to employees.
Common mistakes
- Creating a new position without checking whether the role already exists.
- Leaving every permission enabled for a role that should only do one job.
- Forgetting translations when the company has several interface languages enabled.
- Showing an internal role in the customer interface by mistake.
- Assuming payroll fields are visible in the current form; they are stored technical fields and must be verified before automation uses them.
AI Agent Field Reference for implementation
This block is intentionally below the human instructions. It explains storage names and downstream dependencies for automation, support, and future AI agents.
| Field | Stored as | Purpose | Why it matters |
|---|---|---|---|
| Position ID | positions.id | Unique identifier for the role. | Employees and permission checks need a stable role reference. |
| Company | positions.Company | Company workspace that owns the position. | Prevents roles from one workspace appearing in another company. |
| Position name | positions.name | Multilingual role name stored as language/text objects. | Staff lists, employee forms, reports, and AI explanations need the readable role name. |
| Management | positions.management | Allows access to management-level screens. | Use it only for owners, admins, or managers who should control configuration and oversight workflows. |
| Sales | positions.sales | Allows access to sales and order-taking workflows. | Cashiers and managers need it; warehouse-only or courier-only roles usually do not. |
| Hall administration | positions.hall_administration | Allows hall, table, and dine-in administration. | Needed for hosts, waiters, floor managers, and table-service roles. |
| Courier | positions.courier | Allows courier and delivery execution workflows. | Use it only for staff who deliver orders or manage courier tasks. |
| Storage | positions.storage | Allows storage, stock, receiving, inventory, and warehouse workflows. | Warehouse and manager roles need it; customer-facing roles may not. |
| Production / Kitchen | positions.production | Allows kitchen, production, workshop, or preparation workflows. | Kitchen and production staff need it to see work queues and preparation context. |
| Self-service kiosk / Screen | positions.screen | Allows screen or kiosk-related interfaces. | Useful for terminal, kiosk, display, or self-service operations. |
| Menu | positions.menu | Allows menu/catalog configuration access. | Only staff responsible for product/menu changes should receive it. |
| Supplier | positions.supplier | Allows supplier or procurement-related workflows. | Procurement access can affect purchasing and vendor data, so keep it scoped. |
| Show in customer interface | PositionStruct.client / UI switch | Controls whether this position can be exposed to customer-facing flows. | Use only for roles customers should see, such as specialist or service provider roles; verify backend support before automating. |
| Save | positions row update | Writes the role and permissions. | Unsaved permissions cannot be assigned reliably to employees. |
| Search | positions list filter | Finds existing roles in the list. | Searching first avoids duplicate roles with different permissions. |
| Columns | positions list columns | Changes visible list columns. | Managers can audit role data without opening every row. |
| Import | positions list import | Imports role data when supported. | Useful for migrating many roles, but imported permissions must be checked carefully. |
| Download | positions list download | Exports role rows. | Useful for audit, backup, and review before major permission changes. |
| Report | positions list report | Opens or creates report output for roles. | Helps review access configuration across the company. |
positions list print | Prints visible role information. | Useful for setup review or offline audit. | |
| Hourly pay | positions.hour | Stored hourly pay context. | Useful for payroll and profitability agents even though it is not visible in the current form. |
| Daily pay | positions.day | Stored daily pay context. | Supports payroll rules and cost reporting when used by the business. |
| Monthly pay | positions.month | Stored monthly salary context. | Lets future payroll logic connect staff cost to role. |
| Inside order percent | positions.procent_inside | Commission percent for dine-in or inside orders. | Agents must know which order channel the commission applies to. |
| Pickup order percent | positions.procent_pickup | Commission percent for pickup orders. | Keeps pickup compensation separate from dine-in and delivery. |
| Delivery order percent | positions.procent_delivery | Commission percent for delivery orders. | Helps explain delivery-related compensation. |
| Personal sales | positions.personal_sell | Personal sales commission or target value. | Useful for staff performance and payroll explanation. |
| All sales | positions.sell_all | Team or total-sales commission context. | Separates shared sales performance from personal sales. |
| Inside order fee | positions.order_inside | Stored amount per inside order. | Supports per-order compensation models. |
| Pickup order fee | positions.order_pickup | Stored amount per pickup order. | Keeps pickup order compensation explicit. |
| Delivery order fee | positions.order_delivery | Stored amount per delivery order. | Keeps delivery order compensation explicit. |
| Overtime hours | positions.over_hours | Threshold or context for overtime hours. | Future payroll agents need this to explain overtime calculations. |
| Overtime percent | positions.over_procent | Overtime multiplier or percent. | Payroll explanations must distinguish base pay from overtime. |
| Created at | positions.created_at | Creation timestamp. | Useful for audit and setup troubleshooting. |
| Updated at | positions.updated_at | Last update timestamp. | Agents should check whether permission data is fresh before explaining access. |
Related guides
Use these guides to connect this section to adjacent SABSUS workflows.