PPR editing for the current month closes on day
The day of the month from which the current month is closed for edits. "Not set" — the month stays open until its end.
ProSchedule · User Manual
How the system is configured and how to use it every day. The manual is split into blocks: "Admin" — the reference data and rules of the whole organisation, "Overview" — the settings of a specific store, "Employee schedule" and "Manager schedule" — the daily work with the schedules, "Shift" — the day's clock-ins and clock-outs, "Time sheet" — fact hours and their approval, "PPR" — the stores' team makeup, employee statuses and certifications; blocks about reports will follow. For every screen and parameter it describes: what it is, how it works and what it affects.
Five minutes for the big picture: what ProSchedule is, what the system consists of and how this manual's blocks map to its parts.
ProSchedule helps manage shift work in restaurants: building employee and manager schedules (including automatically), tracking actually worked time, measuring planning accuracy and cost of labor. All of it rests on reference data and rules that are configured once and apply to the whole organisation (the "Admin" block), and on the settings of specific stores (the "Overview" block).
The manager web app and the employee's web cabinet open on the same sign-in page: the logo and a globe button for the language (Русский, English, עברית, O'zbekcha) on top, the form in the middle. The language can be picked before signing in and is remembered in this browser; in Hebrew the page lays out right to left, while addresses and codes stay left to right.
Signing in with a code. Enter your work email in the Email field and press Send code. A one-time code arrives by email, and the form switches to the Enter the code step showing the address it went to; the Edit link goes back to the email. The code is checked as soon as the last digit is in (or with the Verify button). If it is wrong, Invalid code appears under the slots and you can type it again. A two-minute countdown runs under the slots; when it ends, OTP expired and a Resend code link appear. Codes are sent by email only — there is no sign-in by phone number.
Telegram, Apple and Google. Under the form, after the or line, are buttons to sign in with Telegram, Apple and Google: icons with the tooltips Sign in with Telegram, Sign in with Apple and Sign in with Google (when there is only one way, it is a wide button with that label). A button appears only if your administrator enabled that way on your server, so the set of buttons can differ between servers. The service only confirms who you are; the server then looks for your employee card: for Google and Apple the confirmed email address must match the e-mail on the card exactly, for Telegram the username must match the login. These buttons never create accounts.
If sign-in does not go through, the reason is shown above the form:
Password sign-in is in the employee's web cabinet. The Sign in with password link above the email field switches the form to the Email, phone or employee ID and Password fields; the Sign in with a code link switches back. The Forgot password? link emails a link for a new password — the same as in the mobile app.
The system is built as a planning pipeline. Reference data and standards set the rules: structure — where people work; team and roles — who and with which permissions; deployment and ideal structure — how many people are needed at a given sales volume; shift types — which shifts managers work; general settings — by which rules everything is calculated. The daily processes — schedules, time tracking and reports — run on these rules.
The manual consists of blocks. The "Admin" block follows the order of the section's tabs — from "Team members" to the parameter-by-parameter walkthrough of the "Settings" tab. The "Overview" block describes the settings of a specific store. The "Employee schedule" and "Manager schedule" blocks — the daily work with the weekly and monthly schedules, "Shift" and "Time sheet" — fact hours, "PPR" — the stores' team makeup. The "Dashboards" block will follow. For each parameter you will find:
Value limits in the cards (min/max/step) match the field constraints in the interface. Screenshots are reproduced schematically: the layout and labels match the real screen, the data is sample data.
Note
The interface is available in four languages (Russian, English, Hebrew, Uzbek). This manual uses the English labels — exactly the ones you see on screen with the English interface language.
On the right of every page header, between the Admin gear and the avatar, sits the Notifications bell. The red dot on it is the number of unread notifications (more than 99 shows as "99+"). Pressing it opens the panel straight on the Unread tab; there are three tabs, each with its own count:
A notification row shows the type icon (with a dot while unread), the type name, the details (store, week, employee names), how long ago it arrived and, when there is somewhere to go, a View button that opens the related schedule or PPR page. The check mark at the end of the row is Mark as read; only unread rows have it. The two buttons in the panel header act on everything at once: Mark all as read (disabled when there is nothing unread) and Archive read, which moves every read notification from the inbox to the Archive tab (disabled while the inbox holds no read notification). An empty tab says No notifications yet.
Which notifications arrive, and to whom:
| Notification | When it arrives | To whom |
|---|---|---|
| Employee schedule submitted | A weekly schedule was submitted for approval (see schedule statuses). | Everyone who can approve it: the Can approve schedule right and the store within their scope (the store itself or a node above it). |
| Employee schedule approved Employee schedule returned to draft | The schedule was approved or returned to "Draft". | Whoever submitted it. |
| Employees without a role after integration Employees without a structure node after integration New job titles not linked to a role | After an employee import from the HR system (see "Integration") left gaps in the data. While a gap remains, the reminder repeats at most once a day. | Roles with the Is admin right. |
| Planned action due date approaching Planned action is due today Status key date approaching Status key date is today | On the days set in the PPR setting Remind in advance, days (by default 7 days before and on the day itself). The reminder on the day itself arrives if the setting's list contains 0. | The store's employees with the Can edit the PPR right; for a planned action's due date — also the action's author and its assignee. |
| Month PPR approved Month PPR approval cancelled | The store's PPR month was approved at the next level, or an approval was withdrawn (see "PPR month"). | The store's PPR editors and every approval level above the one the month is now at. Whoever pressed the button gets no notification. |
| An employee certification is expiring An employee certification has expired | On the days set in Remind about the expiry in advance, days (by default 30 and 7 days before and on the day itself) and on the day after it ends. In both modes of the "Position and role access approach". | The PPR editors of the employee's main store. |
A notification is addressed to a person, not a position: every recipient has their own "read" mark and their own archive. Recipient lists are built at the moment of the event from the current roles and structure; which roles are notified about fact shifts is set in the role's "Notification parameters" dialog.
The archive is permanent
A notification cannot be moved back from the archive to the inbox, but nothing is lost: the Archive tab shows it with the same text and the same View button. Only read notifications get archived — mark the unread ones as read first.
The first button on the right of the header switches the appearance: the moon turns on Dark theme, the sun brings back Light theme (the button's tooltip says the same). The choice is remembered in this device's browser — on another computer or phone the theme is chosen separately; until it has been chosen, the page is light. Status colors in the dark theme are the same as in the light one, only softer and lighter so they stay readable on the dark background.
On a phone or a narrow screen (a tablet, half a monitor):
When there is nothing to show, a grey card with an explanation stands where the table would be — no header row of an empty table above it. There are two cases:
A link to a deleted or non-existent schedule opens the Schedule not found card with a Go to Overview button.
Block
The global reference data and rules of the whole organisation — the eight tabs of the "Admin" section. The block's chapters follow the tab order.
Who sees the section, how it is laid out and how it differs from the rest of the system's screens.
The section is visible only to users whose role has the Is admin permission enabled (configured on the "Roles" tab, see the chapter on roles). Such users see the Admin item in the main menu; the section's direct path is /admin.
Inside, the section is laid out as a vertical tab menu on the left and a working area on the right. On small screens the menu collapses into a dropdown at the top. The system remembers the last opened tab and brings you back to it on your next visit.
UI settings
Change the look and feel of the app.
Changes apply immediately
Most screens of the section have no separate "Save" button: change a value — and the system already works the new way. Treat the section as a "control panel": precise values here save hours of manual schedule fixes.
The list of all employees of the organisation and the team member card: personal data, role, place in the structure, personal scheduling limits and salary rate history.
The tab heading on screen is Team members, with the description "A list of all the employees in your structure showing their Name, Email, Structure path and Role" below it. Each row of the list is one employee; clicking a name opens their card.
Team members 1
A list of all the employees in your structure showing their Name, Email, Structure path and Role.
Important
Deletion — both from the "⋮" menu and from the card — asks for confirmation ("Are you sure?"). It is available only for manually added employees, and only to users with the "Can add new employees" permission; employees from the integration are protected from deletion.
The card opens by clicking an employee (heading Team member profile) or via the "Add team member" button (heading Add team member). Changes are applied with the Save button — one of the few admin screens with an explicit save.
| Field | What it is | Rules and impact |
|---|---|---|
| Tab. No. | Employee ID number (internal employee identifier) | Always read-only. Generated automatically for manually added employees. |
| Additional ID | An alternative identifier — for example, a card number or an ID on a biometric terminal | Must be unique ("ID already taken by another employee"). Clock-in/out events are matched to the employee by it. |
| Name | The employee's display name | Required. Shown in all schedules and reports. |
| Login | Login for signing in to the app | Unique; spaces are automatically replaced with "_". An empty login is allowed — then signing in by login is impossible. |
| Email for sign-in and notifications | Format and uniqueness are validated ("Email already taken by another user"). | |
| Phone | Phone for signing in with a code | Format is validated; uniqueness is not checked. |
| Hire date | Date of hire | Shifts before the hire date are marked red in the time sheet and excluded from totals. |
| Date of birth | Date of birth | The system uses it to detect underage employees: if the age is below the threshold from settings, a green hint "Underage employee limits" appears under the field and the special restrictions kick in (chapter 08). |
| Role | The employee's role in the system | Defines permissions and participation in schedules. Only a user with the "Can change team member roles" permission can change it. For employees from integration the role list is limited to roles mapped to their job title. In the "By certifications" mode the list leaves out the roles bound to a certification the employee does not hold; the current role stays, marked "Not certified". |
| Job title | Job title from the HR system (read-only) | Comes from integration; determines which roles can be assigned and may force the "On training" status on (see chapter 04). |
The primary unit is picked in a field with search across structure nodes; the selected path is shown as a chain of blue chips. "Custom structure" is a list of additional units the employee also belongs to (for example, to give a supervisor access to several regions); these links are not overwritten by integration and are added with the "Add" button.
Personal scheduling limits (visible when editing an existing employee). If a personal value is not set, the general one from the "Settings" tab applies:
The employee's personal rate for cost-of-labor calculations, with a change history. An entry is added with the Add rate entry button: the Effective since date, the Rate value and the Monthly rate (salary ÷ month hours norm) checkbox. For each date the latest entry dated "no later" than it applies. If "Snap 'since date' to the 1st of the month" is enabled in settings, the date of a new entry automatically becomes the 1st. If there is no personal rate, the role rate applies, then the default rate (see Cost of labour calculation).
When Employee integration is on ("Settings" tab → "Integration"), employee data comes from an external HR system. So that manual edits do not conflict with synchronisation, some card fields are locked. Each "Is it possible to change…" toggle in the integration settings unlocks its field; its value is then not overwritten by synchronisation:
| Card field | Unlocked by the setting |
|---|---|
| Name | "Is it possible to change employee name" |
| Login | "Is it possible to change employee login" |
| "Is it possible to change employee email" | |
| Phone | "Is it possible to change employee phone" |
| Structure (primary unit) | "Manually set primary structure node" |
| Min/max shift duration, restricted days | "Is it possible to change employee shift timing parameters" |
| Max weekly hours | "Is it possible to edit max weekly hours" |
| Hire date, Date of birth | Always locked for employees from integration |
| Additional ID, Custom structure, "Days when scheduling preferences should not be considered" | Never locked |
How deletion works
Deleting an employee is "soft": the row disappears from lists and reports, but the shift history is kept, and the login/email can be reused. If an employee with the same ID number comes in from integration again, the record is restored automatically. That is exactly why employees managed by integration cannot be deleted manually — synchronisation would bring them back. Dismissed employees can be seen in the Time sheet with the "Show dismissed employees" filter.
Where the other employee flags are
The "On training", "NSO", "Can work at night", "All positions", "Employee rating", "Available for shifts in other branches" flags, hiding an employee, and the positions they are trained for are configured not here but on the Overview → Team parameters page of the selected store. The "Team member profile" card there is the same one.
The organisation's tree structure: nodes (regions, divisions — any levels) and stores. This is where the structure is created and reshaped; access scopes, reports and team lists depend on it.
The tree has two kinds of elements. A node (blue circle with an arrow) is a structural unit of any level: a region, a city, a division. Nodes expand on click and can contain nested nodes and stores. A store (grey circle with a shop icon) is an end point: it never has nested elements. On the right of each row is the employee count of that unit. The expanded/collapsed state of the tree is remembered.
Structure
Structure tree of your organisation including all Structure nodes and Stores.
Structure and integration
If the structure is loaded from an external system, only manually created nodes can be deleted. Manual moves are stored separately from the "integration" parent and survive re-synchronisation: a node you dragged stays where you put it.
Where the store parameters are
Opening hours, concept, email, shift parameters and terminal sign-in credentials are configured not here but in the "Store Card" on the "Overview" page of the selected store (the "Open / close period", "Store concept", "Shifts", "Store login credentials" blocks). Access to them is governed by the "Open / close hours" and "Shift timing parameters" role permissions.
Data access by structure
The "Structure" tab itself shows the administrator the whole tree. But on all other pages (reports, dashboards, PPR) the user's visibility scope is defined by the unit in their card: their nodes, all their descendants and one level up. Only users whose unit is the organisation root see the full tree.
Roles are both access rights and the "participant types" of schedules. Each employee is assigned one role; it determines what the person sees and can do in the system, which schedules they take part in and at which rate their labor is costed.
The screen is a table of roles with instant saving (there is no separate "Save" button). In each row, left to right: the role's color mark, name, the "Role rating" range, and four action icons: job titles (briefcase), access parameters (gear), notification parameters (bell), delete (trash); the ▲/▼ arrows change the order of roles in lists. The Add role button creates a role named "New role" — rename it right away.
Roles
Create and configure parameters of different roles for your employees.
The built-in "Admin" role
The role with code 0 is a system one: it cannot be renamed, and its "Is admin" flag cannot be turned off. This is how the system guarantees admin access is never lost. Employees without a role are treated as administrators permission-wise — assign a role to every employee.
The gear in a role row opens the "Access parameters — ‹role name›" dialog. Every checkbox saves immediately. The groups, top to bottom:
| Checkbox | What it does |
|---|---|
| Used in linear employees schedule | Employees of this role can be placed on positions in the weekly schedule. The role appears in the add-to-schedule lists and "Team parameters". |
| Used in managers schedule | Employees of this role can be given shifts in the monthly manager schedule; the role appears in shift type settings. Hours of such a role go into the "manager" part of cost of labor. In PPR, employees of this role count as managers: the role gets a column in the "Ideal structure" section and in the report. |
| Checkbox | What it does |
|---|---|
| Consider lunch breaks | Lunch breaks per the "break ladder" from settings are deducted from the worked hours of this role's employees. |
| Consider special shift hours calculations | Special rules are applied to the role's hours: overtime, night and holiday hours. |
| Checkbox | What it does |
|---|---|
| Can edit schedule | Creating, changing and deleting weekly employee schedules. |
| Can approve schedule | Approving employee schedules and returning them to "Draft". |
| Can approve manager schedule | The same for the monthly manager schedule. |
| Can return schedule to draft | Returning the employee schedule from "Submited"/"Approved" to "Draft". Automatically on and locked if the role can approve the schedule. |
| Can return manager schedule to draft | The same for the manager schedule. |
| Can add new employees | The "Add team member" button and deletion of manually added employees. |
| Can change team member roles | The "Role" field in the employee card becomes editable. |
| Shift timing parameters | Changing the store's shift parameters (in the "Store Card"). |
| Can generate revenue forecast | The button for automatic sales forecast calculation based on history. |
| Can edit revenue | Manually changing the forecast — even one loaded through integration, except locked days — and the period and store in the analysis settings. |
| Open / close hours | Changing the store's opening hours in the "Store Card". |
| Is admin | Access to the "Admin" section — that is, to everything described in this manual. |
| Checkbox | What it does |
|---|---|
| Can edit actual shifts | Adding and editing fact (worked) shifts on the "Day shifts" screen. |
| Can approve employees fact shifts | Approving employee fact shifts that exceeded the plan (see "Max difference of fact shift vs scheduled" in settings). |
| Can approve managers fact shifts | The same for managers. |
| Parameter | What it does |
|---|---|
| Can edit the PPR | Filling in HR statuses, comments and planned actions, granting and revoking certifications on the store PPR page (see "Store PPR"). Such employees receive the PPR reminders. |
| PPR approval level | "No", "Level 1", "Level 2" or "Level 3" — the level at which the role approves the PPR month. Each higher level removes the option to cancel the approval at the levels below it (see "PPR month"). |
| Can train employees | Employees of this role count as instructors: their shift covers training shifts on the same position. The switch is active only when the "By certifications" mode is selected in the PPR settings and "On an untrained position only with an instructor" is turned on. |
Role rate — the hourly cost for employees of the role who have no personal rate: enter a number and pick the /hr or /mo unit (a monthly salary is automatically converted to an hourly rate by the month's hours norm). The "Clear" button removes the role rate — then the "Default hourly sale rate" from settings applies.
Time sheet approval level — "No", "Level 1", "Level 2" or "Level 3". The time sheet is approved level by level, bottom up: each next level closes editing on the previous ones. A role can approve the time sheet only at its own level; a rejection at an upper level removes the approvals of the lower ones.
The bell in a role row. Four checkboxes define which notifications the role's employees receive: "Notify about employee shifts" and "Notify about manager shifts" (in-app notifications about fact shifts that need approval) and their email variants "Notify by email…". Notifications go only to users of roles with the checkbox enabled. Where these and all other notifications are read — see "Notifications: the bell in the header".
The briefcase in a role row opens the "Role ‹name› — job titles" dialog. It links job titles from the HR system (for example, "Grade 3 Cook") to ProSchedule roles:
Before deleting a role
The system will not let you delete a role while it is assigned to at least one employee — move people to another role first, then delete. The built-in "Admin" role cannot be deleted.
The staffing-need standard: the store's working positions and "ladders" — how many people a position needs at which sales volume. Deployment is what the system uses to calculate recommendations, schedule accuracy and the hours budget.
A position is a workplace in the schedule: "Cashier", "Kitchen", "Delivery assembly". Each position has a ladder of "sales volume → employee count" steps. For every half-hour slot of the day the system takes that slot's revenue forecast, finds the highest step whose threshold is reached — and gets the recommended number of people on the position. The sum across all positions is the "recommendation" the actually staffed schedule is compared against (that is how accuracy is computed). Ladder steps are stored sorted ascending by threshold.
Threshold order
On save the system automatically sorts the steps ascending by threshold, and a field that breaks the order is highlighted red while you type. The recommendation is always computed from a correctly ordered ladder.
The gear opens the "Settings — ‹position name›" dialog. All changes are saved immediately.
The deployment is versioned. The active version (marked "Active") is the one the admin section is editing right now and all calculations read: auto-scheduling, dashboards, budget. Selecting another version in the list activates it instantly; the previous one is kept as a snapshot you can return to. The active version cannot be deleted — activate another one first.
Analyse actual schedules is a way to build the deployment "from real life": pick a year and a week, drag finished store schedules into the "Selected" column (or simply click or tap a schedule — it moves to the other column, which is handier on a phone) and press "Analyse". The system reconstructs the ladders from how people were actually staffed in those schedules and saves the result as a new active version (thresholds are fitted to the peak simultaneous headcount at the corresponding demand). The previous version remains — the operation is fully reversible. Positions that were never filled in the selected schedules are zeroed out; "budget" positions are skipped by the analysis.
Tip
Keep a "reference" version with a meaningful name (for example, "Baseline 2026") and experiment in copies: "+" creates a copy of the current version, and you can return to the reference with a single pick in the list.
Team makeup norms, the HR status and certification catalogs, and the rules of the PPR report (the report itself is described in the "PPR" block).
The tab has four sections: Ideal structure, HR statuses, Certifications and PPR settings. The "Certifications" section is always open. In the "Simple" mode certifications restrict nothing: they feed the PPR statistics and the expiry reminders — a banner above the table points this out. The system remembers the last opened section.
The store team standard: how many managers and what team mix a store needs depending on sales and working hours. Every concept from "Settings → Store concepts" gets its own table of tiers here — concepts appear automatically, and the Concept filter leaves just one on the page. A table row is "Tier N"; the columns are:
| Tier | Monthly sales from | Open hours a day from | Branches | Manager | Crew member | Instructor | Trainee |
| Tier 1 🔒 | 0 | 0 | 5 3 | 1 | 70 % | 10 % | 20 % |
| Tier 2 | 8 000 000 | 12 | 6 | 2 | 65 % | 20 % | 15 % |
| Tier 3 🗑 | 15 000 000 | 16 | 3 | 3 | 60 % | 30 % | 10 % |
How a store falls into a tier. The store must clear both thresholds; of the matching tiers, the one with the higher sales threshold is taken, and on a tie — the one with the higher hours threshold. Sales are the average monthly total of the store's sales forecast; hours are the widest opening window of the store, or 12 if no opening hours are set. The first tier starts from zero; its thresholds cannot be changed. Tiers are shown in ascending order of sales. Everything saves automatically; there is no "Save" button.
When there is no norm
A share is a minimum. 0 % is a norm too: there is no minimum, any number is fine, and in PPR such a role is always met. "No team-mix target set" appears only when no tier fits the store: its concept has no ideal structure, the store has no concept, or no tier fits its sales and working hours.
The catalog of statuses a manager assigns to employees on the store PPR page. Add the standard set creates five ready-made statuses — NEW "Newcomer", TRAINING "In training", PROMOTION "Promotion candidate", LEAVE "Long absence" and RISK "At risk of leaving"; they can be renamed. Add status creates your own. The status fields:
| Field | What it means |
|---|---|
| Code | Latin letters, digits, "_" and "-". Cannot be changed after creation. |
| Name · Description · Colour | How the status looks in tables and tooltips. |
| Applies to · Roles | "All", "Managers" or "Employees". If no roles are selected, the status is available to every role of the chosen scope. A role that no longer fits is marked ⚠ — remove it. |
| Carries over to the next months | The status stays on the employee until it is removed or replaced by another. Without the checkbox the status is valid only in the month where it was set. |
| Key date | The status gets a date (for example, the end of the probation period), and the bell will remind about it. |
| Order | The status's place in lists. Rows can be dragged when the table is sorted by the "Order" column. |
A status that is already assigned to employees cannot be deleted. Turn off its Active switch instead: the history is kept, and the status no longer appears in the picker.
The catalog of confirmed skills. Above the table there are two sub-tabs: Positions — certifications that admit to deployment positions, and Roles — certifications that open roles. A certification gives access either to positions or to roles — never to both at once. The fields of the Add certification dialog:
A role with no active certification bound to it is available to everyone by job title, as before. The "No certification required" checkbox is set in the position's settings: anyone can be placed on such positions.
Quick start — the ⋮ menu. On the "Positions" sub-tab: Create from the positions creates a never-expiring certification for every position that requires a certification and grants nothing to anybody; Grant from the current positions grants every employee the certifications of their priority positions from the card. On the "Roles" sub-tab: Grant from the current roles grants every employee the certifications that open their current role, dated today — it is handy to do this before switching to the "By certifications" mode, so that nobody loses access to their role. Running it again duplicates nothing.
Bulk granting — "Grant…" in the row menu. This is a one-time grant. The Roles and Stores filters narrow down the group of people (the employee's main store is what counts); without filters everyone qualifies. The dialog calculates right away: "Match the conditions" = "Already have it" + "Not applicable" + "Will be granted". Grant (N) grants the certificate dated today only to those who do not have it yet. It is not a standing rule: new employees will not get the certificate on their own — repeat the grant when needed.
Archive and deletion. Archive — the certification can no longer be granted, and it disappears from the pickers and from the store matrix; those who already hold it keep the admission. Show archive shows the archived ones, Restore brings a certification back into use. Delete (for an archived one — Delete permanently) is final: every granted certificate is revoked, and the dialog shows in advance how many there are. If you only need to stop granting it, archive the certification instead. A certificate already granted can always be renewed, even if its scope was narrowed later.
Automatic granting in the "Simple" mode. When an employee's role changes — manually or on a load from integration — the system itself grants them the certifications that open the new role. The certifications of the previous role stay.
All values save immediately.
The day of the month from which the current month is closed for edits. "Not set" — the month stays open until its end.
Until which day of the next month the previous month can be edited. 0 — the month closes as soon as it ends. Earlier months are always closed.
How many days before an action's due date and before a status key date the reminder arrives; 0 — on the day itself.
"Simple" (the default) — the role is assigned by job title, "All positions" is set by a switch in the card, "On training" — by a flag; certifications are collected for statistics only. "By certifications" — positions that require a certification and roles bound to a certification are available only with a valid certification, and the "On training" status of employees (not managers) is set by certifications. The comparison is in the table below.
Grant the certifications before turning on "By certifications"
When "By certifications" is selected, the cards of all employees (not managers) are brought in line with the certifications: without a valid certification — "On training", with one — a regular employee, and the NSO flag is cleared. If there are no certifications yet, the whole team ends up in training. First create the certifications and grant them ("Grant from the current positions" and "Grant from the current roles").
A trainee's shift must be covered by an instructor's shift on the same position. Otherwise the schedule shows the "Training shift without an instructor" warning, and the week cannot be submitted for approval. Instructors are employees of roles that have "Can train employees" turned on (the role's "Access parameters" dialog).
From the first reminder on, the certification counts as expiring.
| Status | "Simple" | "By certifications" |
|---|---|---|
| Instructor | — | A role with "Can train employees" while "On an untrained position only with an instructor" is turned on |
| Universal | The "All positions" switch in the card | None: an employee works only on the positions they hold a certification for |
| Trainee | The "On training" flag in the card, or the employee has no employee card (except managers) | An employee (not a manager) without a single valid certification, except NSO; a manager — by the flag in the card |
| Which roles can be assigned | The ones mapped to the job title | The ones mapped to the job title; if a certification is bound to the role — only with a valid certification for it |
| Who can be placed on a position | Anyone | On a position with "No certification required" — anyone; on the others — an employee with a certification for that position, everyone else only as a trainee |
Managers and expired certifications
A manager (a role with "Used in managers schedule") never becomes a trainee automatically — only through the "On training" flag in the card. An expired certification gives nothing: neither admission to a position nor a role.
Shift templates for the monthly manager schedule: four default day-part shifts and any number of additional "routines" with their own repetition schedule.
The manager schedule is built not from positions but from shift types. The screen (heading "Shift parameters") is split into two blocks:
In each type's row: a color mark (a 12-color palette — the shift is painted with this color in the schedule), the name and the settings gear. Changes are saved instantly.
Shift parameters
Setup special parameters for this shift.
The gear opens the "Settings — ‹name›" dialog. The fields by section:
The "Availability parameters" section:
The "Shift parameters" section:
The "Repetition parameters" section (additional shifts only) — when the shift is required:
Why a shift is "not visible" in the schedule
A shift type appears in the manager schedule cell's dropdown only when both conditions are met: the store's concept is checked in the type's "Store concepts", and the manager's role is checked in the type's "Roles". A new shift is created named "New shift type" with empty lists — a row with unfilled roles or concepts is marked with a warning icon and does not appear in the schedule. And the store must have a concept set in its "Store Card".
"The organization production calendar: weekends, public holidays and shortened working days. The monthly hours norm is calculated from it." The calendar is kept month by month and is shared by the whole organization. It answers a single question: which days of the month count as working — and therefore feed the manager schedule hours norm and the employees' monthly hard hours limit — and which do not.
Two lists — Year and Month — pick the month being edited. The year list offers the previous, current and next year: the previous one to correct the norm of a closed period, the next one to enter holidays ahead of time.
The grid mirrors the calendar month and starts on the weekday set in "UI settings". Clicking a day cycles its type: Workday → Weekend → Holiday → Shortened day → back to working. Weekend and Holiday do not count toward the hours norm; a Shortened day stays a working day but trims the norm. Holidays and shortened days can carry a Day name — it is there for people reading the calendar, nothing else. Transferred days work the same way: switch a transferred Saturday to Workday and the Monday taken off to Weekend. The holiday or shortened-day name is shown inside the cell itself, and a legend of the four colours sits under the grid. Today is marked with a coloured circle around its number.
How many hours a pre-holiday day takes off the monthly norm. The day stays a working day and is still counted by the Working days chip — only the hours are subtracted. Switching a day to shortened seeds 1 hour; zero returns it to an ordinary working day. The monthly total is shown by the Monthly norm reduction, h chip.
Unlike the parameters on the "Settings" tab, this calendar is not saved on change: a month is stored as a unit, so edits live in a draft until Save is pressed. While unsaved edits exist a marker appears next to the counters. Reset month deletes the stored month entirely — after that the month is computed from Saturdays and Sundays again. Until a month has been saved once, the grid shows the automatic calendar with a note that the month is not configured yet. With an external calendar connected both buttons belong to the "Fallback calendar" block (below) — the external month itself is read-only.
Appears when the organization is connected to an external production calendar. At the top the page shows the External calendar block — the month from the external source, read-only, with the note "The data comes from an external production calendar and is read-only. Below you can fill in a fallback calendar — it applies when the external calendar is unavailable". Under it — Fallback calendar: the usual editable grid with the same day types, "Norm reduction, h" and the Save and Reset month buttons, captioned "Used when the external calendar is unavailable. If a month is not filled in here, Saturday and Sunday are days off". Fill it in ahead — for the months when an outage of the external calendar would cost the most. The "Every restaurant closed" marks are set in the upper block and are shared by both.
The source is chosen in order: the external production calendar (if connected and it returned data for the month) → the fallback calendar saved on this page → Saturdays and Sundays. While the external calendar responds, it drives the norm, and the "External calendar" block shows exactly it. If for some month the external source returned nothing (unavailable, an error, an empty response), the warning "The external calendar is unavailable right now — the fallback calendar applies" appears in the upper block, and the hours norm — both the manager schedule and the monthly hard limit — is computed from the fallback month; if that is not saved either — from Saturdays and Sundays. Without an external calendar the page has a single editable month, and that is the one in force.
Hover a day and click the padlock in its corner — the day is marked Every restaurant closed. It saves on the click; there is no separate Save for it. Clicking again lifts it.
This is not a fifth day type but a separate mark on top of one: a public holiday is usually a trading day, and an ordinary working day can be shut for a refit. Closing a day therefore does not change the hours norm — staff are still owed their month.
No restaurant needs shifts on such a day: both the manager and the employee schedule show it closed, the auto-scheduler skips it, and it takes no part in the accuracy calculation, neither for better nor for worse. A restaurant manager cannot lift the mark — it is an organisation-wide decision.
The mark lives apart from the calendar itself, so it stays available even when the weekends come from an external production calendar and the page is otherwise read-only. "Reset month" does not touch it either.
The general rules of the system: language and the first day of the week, auto-scheduling constraints, breaks, time and attendance, cost of labor, underage protections, the concept and channel reference lists, integrations. One screen — eight sections; each is described below parameter by parameter.
Saving
All parameters of this tab are saved the moment they change and apply to the whole organisation. Personal values (in the employee card) and store values (in the "Store Card") take priority over the general ones — this is noted in the descriptions.
The "Change the look and feel of the app" section — two parameters.
The default interface language for the whole organisation. After the change the page reloads, and the new language immediately applies to all users who have no personal language choice (a personal choice in the profile always beats the general one). Hebrew automatically enables the mirrored right-to-left layout.
Which day the planning week starts on. The parameter shifts the seven-day "window" of weekly schedules: schedule columns, weekly totals and dashboards are built from the selected day. The week number stays standard (ISO) — only the dates that fall into the week change.
The "Based on that settings we will auto-schedule your shifts" section. This is where the constraint rules live: the auto-scheduler picks shifts so as to cover the deployment recommendation without breaking any of these rules. Most rules also apply to manual editing — violations are highlighted with alerts in the editor.
The quality threshold of the weekly schedule. Accuracy is how well the staffed shifts cover the deployment recommendation (100% = every half-hour has exactly as many people as recommended). The schedule can be approved only when the accuracy of every still-editable day is not below the threshold; the same threshold is shown as the goal on the schedule cards of the "Overview" page.
The same threshold for the monthly manager schedule: approval is available when the schedule's accuracy is not below the threshold and the schedule has no critical errors (for example, uncovered required shifts).
Shift-length bounds for auto-scheduling: demand fragments shorter than the minimum are merged or dropped by the scheduler, longer than the maximum — split into two shifts. Personal values from the employee card replace the general ones, and the underage limits — both. The maximum becomes a hard ceiling of fact hours per day with the "Hard daily hours limit" checkbox.
"How many times a single shift may switch positions (0 = single-position shifts only)". At 0 every shift stays entirely on one position; the higher the value, the more freely the scheduler "moves" a person between positions within a shift, covering ragged demand with fewer people.
How many hours before opening and after closing the store may be staffed — the time for preparation and cleaning. Extends the planning grid beyond the customer-facing hours. The same hours set the bound for trimming early clock-ins (see "Trim fact shift start to store opening"). The value can be overridden per store in the "Store Card".
The default weekly hours ceiling per employee. The auto-scheduler will not exceed it, and exceeding it in a manual edit raises the "Weekly hours limit exceeded" alert. A personal value in the employee card takes priority; underage employees have their own limit. The managers' monthly norm is derived from this same value: (limit ÷ 5) × the number of working days in the month. With the "Hard weekly hours limit" checkbox on this is no longer an alert but a ban: hours above the limit are neither recorded nor planned (see "Time and Attendance").
The maximum of consecutive working days. The scheduler will not assign a shift that would push an unbroken run of working days over the limit; in the manager schedule a violation is flagged as a day error.
The minimum length of a days-off block: a started days-off streak is completed in full — the auto-scheduler will not assign a shift to an employee whose current days-off streak is still shorter than the minimum. A value of 1 disables the rule.
Guaranteed rest: an employee's next shift can start no earlier than the given number of hours after the end of the previous one (shifts that ended the previous night included).
The bounds of the "night window" (the window crosses midnight). It controls three things at once: 1) employees without the "Can work at night" flag cannot be placed into night slots (nor can underage employees if night work is forbidden for them); 2) hours inside the window count as "night" hours in hours reports; 3) the "Night hours salary multiply ratio (%)" is applied to night hours in cost-of-labor calculations.
How many days back the schedule stays editable. A day is open for edits while its date is later than "today minus the depth": at 0 only future days are editable (from tomorrow), at 1 — starting today, and so on. Closed days are also excluded from the accuracy check on approval — you will not have to fix the past to pass the threshold. The same boundary locks the days of the sales forecast.
The target team rating of a shift. In the schedule editor's "Day analysis" the average rating of the staffed employees (morning/day/evening/night and total) turns green when the goal is reached and orange below it. The same goal colors the chips of the "Team rating" row in the monthly manager schedule grid (a goal met exactly already counts as met). An employee's rating is set in "Team parameters", the allowed range — by the "Role rating".
The finishing touch of auto-scheduling: with "1 h" the starts of all automatically created shifts are shifted back to a whole hour (the duration is kept — the shift moves as a whole). Shifts pinned manually with the "lock" are untouched. "30 min" effectively changes nothing — the scheduler already works on a half-hour grid. Round starts are more convenient for employees, but may slightly lower accuracy.
A block inside the auto-scheduling section. Its core is the "break ladder" ("Break duration in minutes depending on shift duration"): a table of up to 5 rungs "shift hours → break minutes". For a shift, the highest reached rung is taken, and its minutes are deducted from paid hours — in schedules, the time sheet, reports and the employee cabinet (for roles with "Consider lunch breaks" enabled).
The single source of break duration in the whole system. The example from the mockup: a 7-hour shift reaches the "6" rung, so the break is 30 minutes and paid hours are 6.5. The "−"/"+" buttons remove and add rungs. It affects hours totals everywhere, regardless of whether "Placed lunch breaks" is on.
Enables a visible break block inside the shift: auto-scheduling places breaks across shifts on its own (trying not to strip the peak slots), and in the editor the block can be dragged with the mouse. Paid hours do not change — placement only decides when the break happens. When off, the blocks are neither shown nor placed.
When on, slots covered by a placed break are deducted from the "staffed" side of the comparison with the recommendation: an employee at lunch does not count as working — which is fairer for accuracy, position diffs and peak-hours coverage. When off, breaks are visible but the calculations ignore them. With "Placed lunch breaks" off the parameter is dimmed, its value is kept until placement is re-enabled.
"Hours an employee must work from the start of the shift before the break can begin" — keeps auto-placement from putting the lunch into the first hour of a shift.
A safeguard against data loss: removes the ability to delete schedules (both employee and manager ones) from the "Overview" page — even in the "Draft" status. The ban does not live on the button alone: the server refuses the deletion and answers Schedule deletion is disabled in the general settings. The same server check closes the deletion of a schedule outside the draft — Only Draft schedules can be deleted; deleting also requires the schedule editing permission.
The "Configure time and attendance parameters" section governs the life of fact shifts — from the mark on the terminal to the row in the time sheet. Every clock-in/out mark goes through a processing pipeline; the parameters below are its knobs.
The tolerance by which actually worked time may exceed the scheduled time and still be approved automatically. If, when the shift is closed, the excess is above the tolerance, the "extra" part of the shift gets the "Awaiting approval" status: a user with the "Can approve … fact shifts" permission must manually approve or reject it, giving a reason. An empty value disables the control — everything is approved automatically. When the day's schedule is split into consecutive periods (say, "Cook" 20:00–03:00 and "Night cleaning" 03:00–05:00) and a single clock-in / clock-out pair covers the whole stretch, the plan is their combined length — nine hours in that example, not seven. Periods separated by a gap in the schedule (say, 09:00–13:00 and 17:00–21:00) stay separate shifts, each compared against its own time.
How many minutes before the scheduled start an employee may clock in and still have that time approved automatically. If the employee arrived even earlier, on shift close-out the shift is cropped to the "scheduled start minus tolerance" bound, and the full clocked time lands on top with the "Awaiting approval" status — the manager can accept it in full or keep the cropped variant, just as with an excess over the "Max difference". Applies only to shifts tied to a schedule.
The mirror tolerance for leaving: how many minutes after the scheduled end an employee may clock out with automatic approval. The overrun is cropped to "scheduled end plus tolerance", while the full time awaits the manager's decision. For a shift split into consecutive periods the bound is the end of the last of them. Both minute tolerances work together with the "Max difference" — the stricter of the bounds applies.
For stores with night shifts and biometric terminals. A clock-in mark earlier than this time is recorded on the previous day as the continuation of a night shift (for example, with the boundary at 02:00 a clock-in at 01:30 lands in yesterday's shift). Clock-out marks are unaffected — a night shift's clock-out already belongs to its start day.
Rounds clock-in and clock-out times to the nearest step (by the usual rounding rules): with a 15-minute step a clock-in at 08:07 becomes 08:00, and 08:08 — 08:15. "No" keeps minute precision. Applied to all mark sources: the terminal, integration and manual edits.
The precision of the daily paid-hours total in employee hours reports — handy for matching the payroll system's format (for example, 2 decimal places). Empty — show the calculation result as is.
The "period closing" date: after this day of the current month, the previous month's fact shifts are locked against edits. For example, at value 5 accounting can run payroll from the 6th, knowing the previous month will no longer change.
An intermediate closing within the month: shifts of the current month dated earlier than the given day are locked as soon as that day arrives. Used with advance payroll runs for the first half of the month.
Allows clocking shifts by hand: start a shift, finish a shift, and add a shift for someone who is not in that day's schedule. When off, a shift cannot be started or finished manually whether or not it is in the schedule: on the "Day shifts" screen and on a person's card the clock-in, clock-out and "Add shift" controls go inactive, and the server rejects such requests.
Editing of actual shifts is not affected: clock-in and clock-out times, approving and rejecting edits, deleting a shift and ⚡ "set the times from the schedule" stay available as usual. Clock events coming from the integration (a terminal) are not affected either — they are not manual entries.
One qualification about ⚡: with the setting off, only the shifts already clocked in through biometry are set by the schedule. No shift is created for anyone who did not clock in — otherwise one press would produce a whole day of attendance entered by hand. The confirmation dialog says so.
When on, shifts of employees with the "On training" status do not count as "working hands" in the comparison with the recommendation: accuracy, the staffed-vs-recommended chips and peak-hours coverage ignore training shifts. Turn it off if your trainees are a full-fledged workforce.
Decides whether the prep and cleanup hours — the hours outside the open-to-guests window — stay in the denominator of SPMH, TPLH and IPLH. On by default: the metrics read exactly as they always have. Turn it off to measure revenue per OPEN hour only — opening and closing then leave the divisor, and SPMH/TPLH/IPLH read higher. On the plan side the hours outside the window are counted by the clock, just as on the fact side: a 14:00–23:00 shift in a store that closes at 22:00 has 1 hour outside.
The setting is about that window only. Hours on deployment positions marked "Does not impact SPMH/TPLH" and on "Based on weekly revenue" positions are left out of the denominator either way — they are non-productive by definition. Trainee and NSO hours are excluded by a separate setting, "Training and NSO hours do not impact SPMH / TPLH / IPLH". The "Non-productive hours" row is not affected by the toggle: it still shows what was staffed outside the open-to-guests window.
When on, the hours of "On training" trainees' shifts and of NSO shifts are left out of the denominator of SPMH, TPLH and IPLH — in plan and in fact alike: in the schedule editor, on the dashboards and in the mobile app. Off by default: the metrics read as they always have. Turn it on to see the yield of the experienced crew — trainees then no longer dilute SPMH.
On the plan side, training shifts and NSO shifts are excluded; the NSO status is fixed on the shift, and an older shift without that mark takes the current flag from the card. On the fact side, the shifts of employees whose card currently says "On training", and NSO shifts.
The hour rows ("Hours", "Non-cust. hours", "NSO hours"), labour cost, accuracy and the ideal deployment are not affected by the toggle. Hours excluded for several reasons at once — say, a trainee on a "Does not impact SPMH/TPLH" position — are subtracted once.
A clock-in earlier than "the opening hour minus the working hours before opening" is automatically moved to that bound, and an explanatory comment is added to the shift's edit history. This way an early "tag-along" arrival does not turn into extra paid hours. Around-the-clock days are not trimmed.
The mirror of the previous parameter for leaving: a clock-out later than "the closing hour plus the working hours after closing" is automatically moved back to that bound, with an explanatory comment in the shift's edit history. This is a hard crop — the "tail" past the bound does not even become an approval request. Also applies to manual edits of the clock-out time; around-the-clock days are not trimmed.
Turns the employee's maximum shift duration into a hard ceiling of fact hours per day. The value comes down the chain: the underage limit → "Max shift duration" in the employee card → the general "Max shift duration (hours)". How exactly the limit fires — in the rule "How the hard limits work".
The same for the week — starting on the first day of the week from "UI settings" — by "Max working hours per week": the personal value in the employee card takes priority, the underage limit beats both. In the schedule the week is computed like the month: fact hours up to the last fact shift plus planned hours after it.
There is no separate number for the month: the limit is the same monthly norm the manager schedule shows: (weekly limit ÷ 5) × the number of working days of the month by the "Weekends and holidays" calendar, minus 8 hours for every working day of the employee's absence (vacation, sick leave, other) and minus the reductions of pre-holiday days. If the employee's weekly limit is 0 ("no limit"), they have no monthly limit either.
The three checkboxes are independent: enable any set. All three count paid hours, as in the time sheet: the time between clock-in and clock-out minus the break by the "Break duration in minutes depending on shift duration" ladder — for roles with break accounting enabled; the others count "clock-in to clock-out" hours. One person's hours add up across all stores.
Fact shifts. When a clock-out mark (or a manual edit, an approval, "Reset to schedueled") takes the window's total past the limit, the shift is cut exactly to the remainder: one record with the cut time is written, and the history of changes gets a comment with the reason and the real clock-out time. This is a hard cut, like "Trim fact shift end after store closing": the "tail" does not even reach an approval request, and it cannot be approved later. If the limit is already used up at the start of the shift, the clock-in is recorded as usual, and at clock-out the shift is fixed with zero hours: one approved record with identical clock-in and clock-out times, a red cross and the hint "Shift started after the limit was reached — recorded with zero hours" with the window name ("Daily hours limit reached", "Weekly hours limit reached", "Monthly hours norm reached"). A cut shift is marked with scissors and the hint "Shift cut at the hard hours limit". The "before the hire date" and "within an absence period" rules are stronger than the limit — such shifts are still rejected. More in the chapter on the "Shift" page.
Schedule. A shift that would push the employee's hours for the day, week or month over the limit cannot be placed — neither with the mouse, nor with an exact time, nor by auto-scheduling, nor in the manager schedule (see the editor chapters). Shortening a shift that is already there is always allowed. For the week and the month the system adds up the fact hours through the last fact shift and the planned hours after it; shifts in other stores and in the manager schedule count too.
What does not change retroactively. Enabling a checkbox does not recompute already recorded shifts and does not cut plans already in place: they only stop hours being added above the limit. If the limit was lowered or the calendar changed, the old shifts stay as they are.
While the system is writing an employee's hours, another edit of the same person has to wait a second or two; if the wait drags on, you will see "The employee's hours are being updated, try again in a few seconds" — just repeat the action.
Preset wordings ("Stayed late at manager's request", "Stocktake"…) that are offered as the comment in the manual fact-shift approval dialog. Rows are added with the "Add reason" button and edited in place. An empty list — free-form comment only. Decision statistics are visible in the "Corrections" report.
When on, the schedule print button already works in the "Draft" status. When off, printing is available only after approval: the team is guaranteed to see the final version.
When on, an employee's personal cabinet (web and mobile app) shows planned shifts only from an approved schedule. Upcoming shifts from a schedule in the "Draft" or "Submited" status are hidden; past days stay visible once the schedule has been approved, so returning a week to draft for a fix never erases shifts already worked from the cabinet. The employee schedule and the manager schedule are checked separately. Actual (clocked) shifts are always visible. On by default; turn it off to let employees see the plan before approval. Such days show "Awaiting approval" in the cabinet.
Behavior on a repeated clock-in mark from the external time-tracking system when the shift is already open: on — the start time is rewritten with the new mark (the previous one is kept in the history); off — the first mark stands, repeats are ignored.
The same for clock-out marks: if the shift is already closed, a repeated clock-out either updates the end time (on) or is ignored (off). Useful when an employee clocked out by mistake and kept working.
The "Default hourly sale rate, average labor tax ratio, and how since-date is normalized for new history entries" section. These parameters feed the "Cost of labor" (COL) report and all monetary metrics of the dashboards. The rate of a specific hour is chosen via the chain: the employee's personal rate → the role rate → the default rate (see the diagram in chapter 04).
"Used in cost calculations when no team-member or role-level rate is configured" — a fallback value so that hours without a rate do not drop out of cost of labor. If it is empty too, such hours are costed at zero.
Taxes and overhead applied on top of the hourly rate: at 20% every hour costs the company the rate × 1.2. Empty — no uplift.
The rate multiplier for hours inside the night window (see "Night shift start / end time") in all cost-of-labor calculations: "150 = night hours cost 1.5×".
When on, every new entry in an employee's "Salary rate history" is saved dated the 1st of its month — rates change in whole months, without "broken" periods inside a month. Existing entries are not changed.
"Restrictions applied to employees younger than the age threshold (derived from date of birth). When set, these take priority over the regular settings". The age is determined from the "Date of birth" field of the employee card — as of the current date, so on the day of majority the restrictions lift themselves.
Employees younger than this age count as underage: their names are highlighted green in team lists and the schedule, and the "Underage employee limits" hint appears in the card. Employees without a date of birth are not counted as underage.
"When off, underage employees can never be scheduled at night and their personal 'can work at night' toggle is forced off" — the personal setting cannot bypass the ban.
Special limits for underage employees. A value set here replaces both the general and the employee's personal value — even if the personal limit is softer. An empty field means "no special limit, the regular rules apply". With the hard limits enabled these same values restrict underage employees both in fact and in the manager schedule.
Weekdays on which underage employees cannot be scheduled. These days are added to the employee's personal restricted days (a union, not a replacement); a violation is highlighted with a "day blocked" alert.
"Configure different store concepts wich you have in your portfolio" — the reference list of formats: a classic restaurant, a food court, a mall unit and so on. Each entry is a pair: Store concept (name) and Store concept code (number); rows are added with the "Add store concept" button and removed with the trash icon.
The concept is the key by which a store gets its standards. It is used in four places:
Careful with deletion
Deleting a concept does not clean up references to it: positions and shift types stay linked to a nonexistent code, and stores of that concept lose their recommendations and shift types. Move the stores and standards to another concept first.
"Configure where customers can place their orders": dine-in, delivery, drive-thru, aggregators. The format is the same — a name and a code; the channel with code 0 is the base one and cannot be deleted.
Channels work in tandem with revenue and the deployment:
"Configure your integration endpoints". The section joins two directions: synchronising employees from the HR system and loading sales (history and forecast) from the POS/analytics system.
Enables the mode where employees are managed by an external HR system. Cards that came from integration are locked against manual editing and deletion (the detailed lock table is in chapter 02); manually added employees are left alone by integration. While the switch is off, all the "Is it possible to change…" toggles below are inactive.
Point exceptions from the lock: Name, Email, Login, Phone, Primary structure node, Shift timing parameters (min/max duration and restricted days) and Max weekly hours. An enabled toggle makes the field editable in the card, and — as its description puts it — "if yes it not updates with API integration": the manual value is protected from being overwritten by synchronisation.
Two pairs of fields: the "Sales history endpoint URL" + access token, and the "Forecast endpoint URL" + token. ProSchedule calls these addresses itself, requesting data by store and period and passing the token in the request header. Sales history provides the hourly revenue shares by channel (the basis of recommendations and the auto-forecast); the forecast — the planned revenue by day. The Verify button next to the field makes a test request: a green "Verified" — the connection works, a red error — the problem text is shown under the field. The eye button shows/hides the token.
Data formats and the description of all APIs are in the ProSchedule API documentation (the "Learn more about integrations" link at the bottom of the section).
Block
The settings of a specific store on the "Overview" page: the store card, team parameters and the sales forecast. Pick a store in the page header — all three windows apply to it.
Everything the previous chapters configured for the whole organisation is refined here for a specific store: working hours and shift parameters, the team roster and its flags, the sales forecast — the fuel for recommendations and auto-scheduling.
Open the Overview page and pick a store in the list — three buttons appear in the header: Store (the "Store Card"), Team ("Team parameters", with the employee count on a badge) and Revenue (the sales forecast). Below is how each of the three windows works.
The Store button opens the "Store Card" window. Its header has four fields: Store name and Store ID (read-only: the name comes from the structure, the ID is the location's system key), Email and Store concept. Changes to the header and the "Open / close period" tab are applied with the Save button; the "Shifts" tab saves instantly on every change.
The concept is the key field
The concept determines which deployment positions, manager shift types and ideal structure card apply to the store. A store without a concept will see no positions in the employees' "Positions" and no shift types in the manager schedule.
Available to users with the Open / close hours permission. Three blocks:
"Closed" does not remember the previous hours
If you switch "Closed" back off, the day gets the default hours 10:00–22:00 — the previous values have to be entered again. Closed days do not block schedule approval though: they are excluded from the accuracy calculation.
Available with the Shift timing parameters permission — "Setup special timing parameters for each shift type". For every manager shift type of this concept you can override Shift start and Shift duration for this specific store (the second cascade level from chapter 07). A block without an override is shown semi-transparent — it inherits the shift type's values; the first change to either of the two fields creates an override for both at once. Saves instantly.
The orange Store login credentials button in the card header — "Credential to login to your store in ProSchedule Time Attendance application": the organisation ID, Store login and Password. The password is generated with the refresh button and is shown only once — generating it again invalidates the old one. Access to the window is granted by a separate service permission of the role.
Store Card
🛡 Store login credentials 4The Team button opens a full-screen table of the store's employees (the roles that take part in the employee schedule or the manager schedule). There is no "Save" button here — every change is applied immediately. On top — a search (by name, "System employee ID" or "Additional ID") and the Add team member button (the "Can add new employees" permission); it opens the same card as in the admin (chapter 02) but without the "Structure" block — the employee is attached to the current store.
The table columns and what they do:
| Column | What it configures |
|---|---|
| Name | Clicking the name opens the employee card. Next to it — the Vacations/sick leaves button (vacation and sick-leave periods; the employee is not scheduled on those days). Hovering the avatar reveals an "eye" — hide/show the employee. The name color is the status: green — underage, orange — on training, purple — NSO, light blue — regular. |
| Role | Change the role right in the row (the "Can change team member roles" permission). For integration-synced employees the list is limited to the roles of their job title; a "training only" role switches the training status on automatically. In the "By certifications" mode, roles bound to a certification are available only with a valid certification; a current role without one stays, marked "Not certified". |
| Employee rating ★ | 0–10 in steps of 0.5. The ratings of the staffed employees make up the day's and the shift's "Team rating" (the goal is set in settings). |
| Available for shifts in other branches ⇄ | Allows "borrowing" the employee: without the flag they cannot be added to another store's schedule. |
| On training 🎓 | A three-state switch: No / On training (orange) / NSO (purple — "New store opening trainee"). The statuses are mutually exclusive. Trainees are not placed by the auto-scheduler; their hours are marked as training and counted separately in the cost of labor (NSO — as its own COL NSO line). In PPR, an employee without an employee card also counts as a trainee. In the "By certifications" mode employees (not managers) have no choice: without a valid certification — only "On training" or "NSO", with one — "—" with a hint. Managers choose as before; a manager becomes a trainee only through this flag. |
| Can work at night 🌙 | Allows placing the employee inside the night window (its bounds — in the general settings). For underage employees the global night-work ban overrides the personal flag. |
| All positions 💼 | The employee fits any position — the auto-scheduler is not limited by their position list. Only for roles used in the employee schedule. The column is visible only in the "Simple" mode: in the "By certifications" mode there are no universal employees. |
| Positions | Up to three positions by priority (#1–#3) from the concept's positions and position groups. The auto-scheduler staffs #1 first, then #2 and #3. In the "By certifications" mode the offered positions are those the employee holds a certification for or that do not require one; a group — if all of its positions are open. A position already chosen stays, marked "Not certified". |
A hidden employee
The "eye" on the avatar hides the employee: the row is dimmed, auto-scheduling ignores them, and they disappear from the pickers in the schedules. The history and the card are kept — hiding is reversible and handy for long absences without a dismissal.
After changing roles — re-sync the manager schedule
An already created monthly manager schedule does not pick up roster changes by itself: press Update store team in the schedule header (available in the "Draft" status) — new managers are added, departed ones removed, and the hour norms refreshed.
The Revenue button opens the store's revenue forecast by month. On top — the month picker (the next month by default), below — a table by day: Day, Sales, Transactions, Menu items (optional) and the computed AGC (average check = sales ÷ transactions). Weekend rows are highlighted orange; the month totals are at the bottom. Changes are applied with the Save button; editing the fields requires the Can edit revenue permission — including for data loaded by the integration.
The tools in the window header:
No forecast — no recommendations
A day without a forecast gets no deployment recommendations at all: auto-scheduling does not know how many people are needed, accuracy is not computed, and the schedule is built "blind". Fill in the forecast before creating the schedule — manually, by generation or via the integration.
| Day | Sales | Transactions | Menu items | AGC |
| 1 Tue 🔒 3 | 450 000 | 1 200 | — | 375 |
| 5 Sat 2 | 690 000 | 1 750 | — | 394 |
The forecast cannot be changed for days the plan is already working on:
The lock applies everywhere: to manual entry, to auto-generation and to integration uploads. That way the plan the schedule was approved against — and that SPMH, TPLH, COL and accuracy are calculated from — does not change after the fact.
In the Revenue window such rows are read-only. A lock sits next to the day number, and its tooltip gives the reason: "Outside the schedule editing depth" or "The employee schedule for this week is approved. Return it to draft to change the forecast". Above the table there is one line: "Days outside the schedule editing depth and weeks with an approved employee schedule are locked". If the week is approved while the window is open, saving shows "The forecast can't be changed for days outside the schedule editing depth or for weeks whose employee schedule is approved"; the locked days go back to their saved figures and the edits on the other days stay — press Save again. The manager mobile app works the same way.
Forecast and integration
A forecast loaded via the API looks and behaves like a regular one: a user with the editing permission can adjust it, and the next integration upload will overwrite the open days of the month. The integration does not change locked days, and days the month does not have (for example, April 31) are not stored. Agree on what the source of truth is: either the integration or manual upkeep.
Block
The weekly schedule of the line staff — from the first created week to the printout: the editor with the day grid, preferences, auto-scheduling, analysis and approval.
Where the weekly schedules live, how a new week is created and how the "Draft → Submited → Approved" lifecycle works.
The schedules of the selected store are listed on the Overview page — under the header there are two tabs: Linear employees (weekly schedules) and Managers (monthly schedules — the next block is devoted to them). The last seven weeks are shown by default; the Show last field sets the list length — from 1 to 99 weeks, so the history can be extended as well as shortened.
The Add new schedule button (the "Can edit schedule" permission) creates the week that follows the most recent existing one. An arbitrary week — a past one, or a future one further ahead — is opened from the editor: pick it in the week selector, and if there is no schedule there yet, a "No schedule" placeholder appears with a create button.
If you are building a schedule for the first time, the route is short: create the week → enter the preferences → run auto-scheduling → finish the days by hand → submit and approve. Each step has its own chapter, and the whole route is assembled in the "Build a week from scratch" walkthrough.
The editor header: switching the store and the week, day tabs, the toolbar, the week summary and printing.
At the top — the store and week selectors (switching the store opens the same week of its schedule), below — eight tabs: seven days (from the "first day of week" date in the settings) and Week. There is no separate "Save" button: every action is saved immediately, and it is backed by Undo / Redo — up to five history steps per day.
The icon's colour says what the button will do. The amber bolt ⚡ is automatic generation, as everywhere else in the product (the revenue forecast generator, setting the fact from the schedule): one press rewrites what you had placed. Blue opens the windows that feed the schedule and works on the roster. Red throws work away. The three lifecycle buttons wear the colour of the status they move the schedule to — the same colours as the status chips on "Overview": Draft ✎, Submited ✈, Approved ✓. Print, Undo and Redo change no status and stay grey.
| # | Button | What it does |
|---|---|---|
| 1 | Scheduling insights | Appears after auto-scheduling: a list of the scheduler's hints for the selected day (critical ones — with a red dot). The hints live until the page is reloaded. |
| 2 | Auto schedule | On a day tab it completes the selected day, on the "Week" tab — the whole week (see the auto-scheduling chapter). |
| 3 | Show/hide employee's schedule preferences | Highlights on the lines the hours outside an employee's preference (pale empty cells; pink — if a shift landed on an "undesired" time). Display only. |
| 4 | Add only employees with schedule preferences | Adds to the selected day empty lines for everyone who left a working preference — no time is set. Those already added are not touched. |
| 5 | Clean up schedule | Deletes all the lines of the selected day — including locked ones. The action is reversible via "Undo". |
| 6 | Delete empty schedule lines | Removes from the selected day the lines without a single shift. |
| 7 | Schedule preferences | A full-screen table of the team's preferences for the week: "Day Off" or a "from … to …" window for every day. Changes are saved immediately; "Apply" refreshes the grid. |
| 8 | Show hourly sales distribution settings | The day's "Transactions distribution" chart: the people recommendation and the hourly transactions curve, broken down by order channels. The same dialog picks the store and the period the hourly distribution is computed from — see "Analysing sales by store and period". |
| 9 | On a day tab — "Portrait/Landscape"; on the "Week" — "Week summary" (in the summary's current sorting) and "By day schedule" (the ⋮ icon — portrait, ⋯ — landscape). Available per the print rule from the settings. | |
| 10 | Undo ↶ / Redo ↷ | Up to five history steps per day; the "Week" tab keeps no history. |
| 11 | Send for approval ✈ | Active once the accuracy of every open day that can still be edited has reached the minimum; days outside the editing depth are not checked. The button's tooltip names the days holding it shut. After submission its place is taken by "Approve" ✓ and "Return to draft" ✎ (the "Can approve schedule" and "Can return schedule to draft" permissions). |
| 12 | The "Week" tab | The "employees × days" summary — see below. The day-level tools (2–6, 8) are hidden on it or work across the whole week. |
By default the hourly distribution is computed from this store's own sales history over the five weeks before the schedule's week. The "Transactions distribution" dialog can change that: pick a store and a period, then press "Analyse" (the download icon next to the calendar).
From then on the whole week — the chart, the hourly recommendation, the accuracy and the peak hours — is computed from the chosen store's curve over the chosen period. The source currently in force is shown under the filters; "Reset to default" (the arrow) returns the calculation to this store's own five weeks.
The period must cover between 7 and 366 days — anything shorter than a week would leave some weekday with no data at all. While the period is outside those bounds the analysis button stays disabled.
Only the pointer to the store and the period is stored, not the numbers themselves: upload sales for the same period later and the schedule picks them up without re-running the analysis. Permissions are the same as for editing the schedule.
An "employees × days" table: the cells hold shifts like "Cas: 09:00 – 18:00" (underlined with the position color; the leave time is shown per the half-hour convention), the last column holds the Total of hours for the week, the day headers — a people counter. Two sortings — alphabetical and by positions (in groups); the chosen sorting also sets the format of the "Week summary" printout. A red "Vacation" cell is an absence period. Preferences are visible under the shifts: clicking a working preference places it as a shift on the employee's main position. The "i" button opens Schedule statistics — the weekly KPI tiles and two charts: "Team rating/Accuracy" by day and "Positions split" ("Need for position" from the recommendation against "Availability in the team" by trained staff).
If nobody is on the store team or on this week's shifts, the table is replaced by the No team members yet card.
The main working screen: a half-hour grid from 06:00 to 10:30 of the next day, positions with deviation indicators and employee lines where shifts are drawn with the mouse.
Grey (hard) hour locks: a forbidden weekday or an absence period; the night window for those who may not work at night; half-hours already taken by this person on another position, in the manager schedule or by yesterday's shift "tail" — adjacent shifts may not touch each other. Pale cells are the soft "outside the preference" mark (with the preference display enabled); a shift over such a cell is highlighted pink but not forbidden.
A red name — the line has a conflict: a shift on a blocked day or an absence period, night hours without the night-work permission, or the personal weekly hour limit exceeded (the "Weekly hours limit exceeded" hint also shows the limit itself). Hover the name to see the reason.
Hard hours limits (the checkboxes in "Time and Attendance"). A shift does not stretch past the employee's remaining hours: the bar simply stops growing. In the "Shift parameters" window, on an overrun, a red line "Available under the limit: … h" appears under the fields and Save is disabled. The day's remainder is visible in the hint on the hours total next to the name. It is computed from the fact hours through the last fact shift and the planned hours after it — across all stores and the manager schedule. Shortening a shift is always allowed. If an edit still reached the server with an overrun (for example, the hours changed in parallel), it is cancelled with the message "The shift exceeds the employee's daily hours limit" ("…weekly hours limit", "…monthly hours norm"); an "Undo" step of the history that would bring back hours above the limit is not executed either: "Cannot undo: the restored shifts would exceed the hours limit".
A cell will not draw? Check in order
1 — the status: drawing works in the draft only. 2 — the day is within the editing depth. 3 — the cell is not grey (the locks above). 4 — the person is not on vacation and the weekday is not forbidden for them. 5 — the adjacent half-hour is not taken by their own shift on another position or in the manager schedule. 6 — the person still has hours under the hard limit: the "Available under the limit" hint in the shift parameters. If the whole line disappeared — the employee may have been hidden in the team or dropped out during a sync.
The "+" button at the end of every position opens the Add employee to position window. By default it shows the store team: the "Name", "Positions", "Schedule preferences", "Hours" columns for the week; the Only not added and Only for current position switches narrow the list. The search above the list matches the name, the "System employee ID" or the "Additional ID", both for the store team and when searching other stores. Those already standing on another position today are marked "Already in schedule", yet can be added — a shift may be split between positions. Turning off From current store, you search other stores: only an employee with the "Available for shifts in other branches" flag can be borrowed (without it — a red ban).
Add employee to position
In the "By certifications" mode
If the "By certifications" approach is selected in the "PPR settings" section, the window shows each person's admission to the position: "Confirmed", "No certification needed" or "In training". The Confirmed only switch hides those who are not admitted. The shift rows get the warnings "No certification for the position", "The certification has expired" and — with the "On an untrained position only with an instructor" setting turned on — "Training shift without an instructor"; with the last one the week cannot be submitted for approval. Auto-scheduling does not place people on positions they are not admitted to.
The panel above the grid: the day's "Revenue", SPMH/TPLH (forecast against deployment), "Hours" (placed / recommendation), "Non-cust. hours" (a pair as well: placed / by the ideal deployment — the hours outside the open-to-guests window, that is the preparation and cleaning), "Training" (in orange — trainee hours), "Accuracy" (green once the minimum is reached), "Pick hours security" and "Team rating" by day parts (morning/day/evening/night against the "Team score goal"). On the right — the day chart: the "Team" fill (people per hour) and the "Transactions" line from the sales history.
How the scheduler fills a day, what it will never touch and how the employees' preferences take part in the placement.
All the limiters are described in the auto-scheduling settings: shift length, the hour and consecutive-day limits, rest between shifts, the night window, positions and universal workers, the underage rules. Hidden employees, trainees, absentees and those busy in other stores are not placed. After the run the "Scheduling insights" button appears with hints — for example, who was missing and why. The scheduler respects the hard hours limits too: whoever has less remainder than a minimum shift is not placed on the day, saved default shifts that do not fit the remainder are skipped, and if after the placement someone's hours still went over the limit — it shortens the shifts it placed itself. Both cases land in "Scheduling insights": "Shifts shortened by the hard hours limit (…)" and "Hard hours limit (…): … — the hours left are less than a minimum shift, so auto-schedule did not place them". Auto-scheduling now always applies the underage restrictions rather than only highlighting them in the grid.
Three preference tools — do not confuse them:
Employees leave their preferences in their own cabinet; the days on which preferences are ignored are set in the employee card.
The scheduler computes the week without locking it and saves the result in one go. If someone changed a day of the week in the meantime, the save is cancelled with the message "The schedule changed during auto-fill — run it again" — just start it again.
Default shifts
The bookmark button on a line saves its time as this employee's "default shift" for that weekday and position. On every auto-scheduling run such shifts are placed first and with a lock. Only hiding the employee or their absence cancels a default shift; drawing anew over the bookmark removes it.
The route for a new manager — from an empty week to an approved schedule:
The "Send for approval" button is inactive?
Then at least one open day's accuracy is below the minimum from the settings. Hover over ✈ — the tooltip names those days. Find each by the red "Accuracy" in the day analysis and close the missing half-hours — the weekly average does not count, every day is checked on its own. The store's closed days are skipped. So are days you can no longer edit under the "Schedule history editing depth in days" setting: if no shift there can be changed, such a day does not hold the week back — only the days you can still do something about are checked.
ProSchedule has a mobile app — ProSchedule — for iOS and Android: the mobile version of the whole platform. It has two modes: the employee's personal account (hours, shifts and preferences, as in the web cabinet) and manager mode (store overview, the day's shifts, the dashboard and settings, as in the manager web app). A two-position switch in the top bar, opposite the avatar, moves between them: the briefcase icon is Manager, the person icon is Personal account (these are also the names assistive technologies announce; the switch itself is Mode). The floating tab bar at the bottom shows only the current mode's tabs. The chosen mode is remembered on the device: the next launch opens in the same mode.
The personal account has three tabs and the profile:
Manager mode. Not everyone sees the mode switch. Users with a separate administrator account always do; team members signing in with their own employee card only if their role is not limited to the line-staff schedule — the role either takes no part in the employee schedule or takes part in the manager schedule. It is the same rule the manager web app applies at sign-in. Stores and structure nodes appear within the scope assigned to the account. The Admin tab exists only for roles flagged as administrator. Manager mode has four tabs:
The store card on the phone. The Store Card button on the Store overview tab opens the same window as in the web app, and it is just as editable. The window's header carries the store's name, and right below it the switch between two tabs: Working hours and Shifts. At the very bottom of the window, under the tab's content, sit the Email field (an invalid address disables Save) and Store concept, a list of concepts with Not specified to clear it.
Working hours holds the Preparation and cleaning block — Working hours before opening (−6 to 6, step 0.5) and Working hours after closing (0–12), each entered in a sheet with stepper arrows where Clear returns the field to "—", i.e. to inheriting the general settings. Next comes the Open / close period block: one row per weekday, and the row shows the day's name, its guest hours (Closed on a closed day, Round the clock on a 24-hour one) and a red switch that closes and opens the day. Opening a day with that switch gives it 10:00–22:00, exactly as in the web version. Tapping a row opens that day's window: the Closed and Round the clock switches ("Technically 24 hours working (only manager and technical staff needed)") and the Since / Till hours (a 30-minute wheel; opening no earlier than 06:00, a closing time past midnight marked with ⁺¹). Save in that window carries the day back into the card, and Cancel closes it unchanged. The Shifts tab lists the manager shift types of the store's concept: the shift name in its own colour, Shift start and Shift duration, plus a Reset to default row on the ones that are overridden. Changes on this tab are saved immediately; everything else in the card is committed by Save at the bottom of the window (Cancel closes it without writing).
The shield button in the card's header opens Store login credentials: the organisation id, the Store login and the Password. The values are masked with dots and the eye icon reveals them; the Reset button next to the password issues a new one after a confirmation dialog, and the old password stops working at once. What is available depends on the role's permissions: without Open / close hours the Working hours tab is read-only, without Shift timing parameters so is the Shifts tab, and the credentials button is inactive without Can see store credentials. For read-only accounts every control is disabled and the Save button is not shown.
The team on the phone. The Team button opens the store's team list with a Search.. field (by name, "System employee ID" or "Additional ID"): every row shows the initials in the role's colour, the name, the role and, when there is one, a single training tag — On training or NSO; hidden team members stay in the list, dimmed, with a crossed-out-eye icon. The number next to the list's Team heading is the same one the button that opened it carries. When nothing matches the search — No employees found. Tapping a row opens that person's card with the same parameters as a row of the web table, each saved the moment it is changed: Role (needs the Can change team member roles permission; for employees from an integration the list is limited to the roles of their job title), Employee rating (0–10, step 0.5), Show (turning it off hides the person from schedules), the training status — No, On training or NSO (a "training only" role rules out No), the Available for shifts in other branches, Can work at night and All positions switches, three Positions by priority (1, 2, 3 — the concept's positions and position groups; one already chosen in another row is not offered again) and the Vacations/sick leaves row. That row opens the list of periods: each has a type (Vacation, Sick Leave or Other), a Period (a calendar with a range selection) and Delete with a confirmation, and Add absence period creates a new one. For a hidden team member every parameter except Show is disabled — the absence periods can still be read, but not changed. In the "By certifications" mode the same rules apply as in the web version: the role and position lists hold only what certifications open (the current value is marked "Not certified"), "On training" or "NSO" can be chosen only for employees without a certification, and there is no "All positions" switch. Adding and deleting team members, and the rest of the web employee card (contacts, salary, saved schedules), stay in the web version.
The store for the Store overview and Shift tabs is picked once — with the button showing the store icon and its name in the top bar (the list is titled Store). The list holds only the stores available to the account; the choice is shared by both tabs and remembered separately for each company server. With a single store available the button is inactive. Whatever the phone does not offer is done in the web version: such screens end with the hint Editing is available in the web version.
Notifications in the app. The Notifications bell sits in the top bar of every tab, opposite the avatar; the red dot on it is the number of unread notifications. It opens the Notifications screen with an All / Unread / Archive switch — the same three lists and the same notifications as the web app's bell. The screen opens on Unread. Tapping an unread row marks it read; the check mark in the top bar is Mark all as read (shown while there is something unread); the Archive read button at the foot of the inbox moves the read ones to the Archive. Pull the list down to refresh. An empty list says No notifications yet.
Signing in works the same as in the web cabinet: a one-time code sent to e-mail (the Send code button) or a password (the Sign in button) — e-mail, phone, login or employee ID plus the personal password. The Forgot password? link doesn't change the password right away: it e-mails a link that works for 30 minutes. Open it and press Send new password — the new password arrives at the same address, and the current one keeps working until then. The screen says Check your email even if the login doesn't exist or the account has no e-mail, so a stranger can't tell whether an account exists. An account gets at most three links an hour.
Google, Apple and Telegram sign-in. Below the sign-in form there are Sign in with Telegram and Sign in with Google buttons, and on iPhone the system "Sign in with Apple" button. A button appears only if your administrator enabled that method on your server, so the set can differ from one server to another. The app verifies the sign-in with Google, Apple or Telegram itself, and the server then matches the result against your employee card: the e-mail address (for Google and Apple) or the Telegram username has to be the one on the card — otherwise you get "No employee card matches this account" and an administrator has to add it. On iPhone these buttons only appear alongside "Sign in with Apple": if your administrator has not enabled Apple on your server the whole block is hidden and code and password sign-in remain. Apple's "Hide My Email" will not work: it hands over a throwaway address that is not on the card. If you later revoke ProSchedule's "Sign in with Apple" access in the iPhone settings (or delete the Apple Account itself), the server is notified and the link between that Apple Account and your employee card is removed — the card itself, your shifts and your hours are untouched, and signing in with Apple again simply asks for your consent afresh.
Company server. Every company runs its own ProSchedule server, and the app is connected to one of them at a time. A single card sits at the bottom of the sign-in screen at all times. Until your own company is connected it reads Add server and the app talks to the default ProSchedule server, so you can sign in straight away. Once connected, that same card shows the company's name and its server address, and the bin icon on it disconnects the server (the confirmation offers Delete), returning the screen to its original state. Connecting a different company simply replaces the current one; either way the sign-in data for the previous server is deleted with it. The current server's address is shown at the bottom of the Profile page. Changing server is only possible from the sign-in screen: sign out first.
The Add server screen opens on a single field — Company name. Enter the name your administrator gave you and the app looks up your company's server address for you in the shared directory. If your company isn't listed yet, the I have a server address link opens a Server address field (for example https://schedule.mycompany.com), and I have a company name switches back. Connect checks the address before saving it, so an address with no ProSchedule server behind it is reported straight away. There is no name to invent: it comes from the shared directory, or from the server itself if the company isn't listed there.
Signing in happens per server: each keeps its own session, valid for up to 30 days. Switching to another server, or removing one, erases the stored sign-in for the previous server — the device keeps no access to a company you no longer work with. Signing out or dismissal from the company also revokes access.
Interface languages — Russian, English, Hebrew (right-to-left) and Uzbek: the app follows the language set in the cabinet profile, and it can be changed on the Profile page.
Block
The monthly schedule of managers: a "managers × days of month" grid, shift types from the "Admin" block, hour norms and its own approval cycle.
How the manager schedule differs from the weekly schedule, how it is created and which conditions unlock the approval.
Manager schedules live on the "Overview" in the Managers tab — a month card with the status and the tiles: "Hours" (against the ideal), "Over norm hours summ", "Under norm hours summ" and "Accuracy". The Add new schedule button creates the month that follows the most recent one. In the editor the month is picked with a selector (existing months), the store — with a search; the schedule team automatically receives the employees of the roles with the "Used in managers schedule" flag. There is no "Save" button — changes apply immediately, backed by "Undo"/"Redo".
| # | Button | What it does |
|---|---|---|
| 1 | Statistics | A popover with the month summary: "Hours" against the ideal, "Over norm hours summ", "Under norm hours summ", "Accuracy" against the managers' minimum. |
| 2 | Auto schedule | Completes the month's empty cells (see the order in the grid chapter). It only adds — the existing cells stay. |
| 3 | Clean up schedule | Removes the month's shifts and days off; the "Vacation" marks from the absence periods remain. Reversible via "Undo". |
| 4 | Add team member | Borrow a manager from another store — a network-wide search (by name, "System employee ID" or "Additional ID"); only those with the "Available for shifts in other branches" flag can be added. |
| 5 | Update store team | Re-syncs the lineup after staffing changes: adds the new, removes the departed without shifts, recalculates the norms. The grid does not do this by itself. |
| 6 | Schedule preferences | The team's preferences table for the month: "Day Off" or the desired shift type per day. |
| 7 | Use employee preferences in auto-scheduling | An eye / a crossed-out eye — a flag stored on the schedule itself: on, the next ⚡ run starts the placement from the preferences; off, it ignores them. It changes nothing in the grid (preferences are never shown there); switchable in the draft only. |
| 8 | Print month schedule | Available after approval; a month PDF with two tables and an "Hours" column — red on overwork. |
| 9 | Undo ↶ / Redo ↷ | Up to five history steps. |
| 10 | Send for approval ✈ | Active with accuracy ≥ the managers' minimum and zero critical conflicts. After submission — "Approve" ✓ and "Return to draft" ✎ (the manager schedule permissions). |
A manager's hour norm for the month
(the personal weekly hour limit ÷ 5) × the number of working days in the month − 8 hours for every working day of absence − the pre-holiday shortenings. Example: a 40 h/week limit and 22 working days → 8 × 22 = 176 h; minus a vacation covering 2 working days (−16) and one pre-holiday day (−1) → the norm is 159 h. Weekends and holidays come from the working-days calendar — the external one when it is connected, otherwise the month entered under the "Weekends and holidays" tab; either way, moved working Saturdays count as working. With no calendar for the month, Saturdays and Sundays are the days off. HR can also override the norm for a specific month. Borrowed managers are not part of this store's norms and "Over/Under norm hours".
Rows — managers, columns — the days of the month. In a cell you pick a shift type or a day-off mark; hours are counted against the norm.
The cell dropdown: "..." (clear), Day Off, Sick Leave and the shift types available to the store by concept and by the manager's role (see the shift types chapter). A shift and a day off displace each other; a yellow column background is the store's closed day. With the hard hours limits enabled the list shows "Available under the limit: … h" for that day and disables the shift types that do not fit the remainder (the remainder counts the manager's hours across all stores, including shifts in the employee schedule). The same line is in the custom time window ⚙ — there it turns red when the entered duration exceeds the remainder. An attempt to place the extra anyway is cancelled with the message "The shift exceeds the employee's daily hours limit" (weekly, monthly norm), and "Undo" will not restore a shift above the limit: "Cannot undo: the restored shifts would exceed the hours limit".
A closed day. When the store does not open on some day, mark it: click the day header and choose Mark the day as closed. The column takes the yellow background and a lock instead of the status icon, shifts can no longer be set on that day, and the shifts and days off already standing on it are removed. The point: a closed day is not counted as a hole in the schedule — it takes no part in the month's accuracy at all, which is averaged over the days the schedule actually asks something of. A closed day cannot spoil the month, and is not counted as a good day either. The managers' hours norm does not change either: it comes from the production calendar (see the weekends and holidays chapter), not from how many days the store is open. To bring the day back, choose Reopen the day — the shifts are not restored, they have to be set again (or press Undo right away). Days can only be marked in the "Draft" status and with the right to edit schedules.
A weekday the store never opens does not need marking: the schedule takes the opening hours from the store card (see the store card chapter). When a weekday has no working hours set there, no ordinary shifts are required on it — the day is not counted as a hole. Routines tied to that weekday (stock-takes, month-end closings) are still required and still placed automatically: shut doors do not cancel the work in the back. If such a routine is left unplaced it tells on accuracy exactly as it would on a trading day; a day nothing is asked of stays out of the calculation. Shifts can be set on such a day too.
In the grid such a day looks closed: a yellow column and a padlock instead of the status icon. The Mark the day as closed item is not offered for it, though — the day is closed by the store card and cannot be reopened from here; change the opening hours on the card instead. And if a routine for that day is left unplaced, the padlock gives way to the usual orange warning icon: shut doors are no reason to hide an outstanding stock-take.
Shift start
10:00 ▾Shift duration
9 h ▾Month auto-scheduling ⚡ completes the empty cells: first the preferences (if the "Use employee preferences in auto-scheduling" flag is on), then the additional routine shifts by their repeat calendar (the priority role goes first), then the day-part default shifts — honoring the day-part sequence (no morning shift after an evening/night one), the type's "Maximum number of shifts in a row", the limits on working-day series and day-off blocks, the hour norms and the shifts in other stores. Whoever is furthest below the yearly balance gets a shift first. The scheduler only adds: "Clean up schedule" before the run gives a blank slate. It respects the hard hours limits: a shift that does not fit the manager's remainder is not placed.
After staffing changes
The grid does not pick up role and lineup changes by itself: press "Update store team" (in the draft). New managers will appear, the departed without shifts will disappear, the norms and ratings will be recalculated; the undo history starts over.
A schedule with no managers shows the No managers in the schedule card instead of the grid; in a draft it has an Update store team button. Managers can be added one by one with Add team member in the schedule header.
The route from an empty month to an approved schedule:
Days beyond the editing depth
Past days beyond the "Schedule history editing depth in days" are locked: the cells do not change, the row-clearing cross leaves them alone, and the month's accuracy is computed over the editable days only. Plan back-dated corrections in advance.
Block
The store's actual day: who clocked in and out, when, and with which status. This is where fact shifts are opened, closed, edited and approved.
The Shift page in the top menu shows one day of one store: the day's KPIs and the list of people with their schedule and clock-in/out marks. The same screen exists as the "Shift" tab of the mobile app, but shifts are edited here only.
The header holds Store (search by name), the date with a back-to-today button (the calendar starts on the first day of the week from "UI settings") and a search over the list: by name, "System employee ID" or "Additional ID". The chosen store is remembered.
KPI tiles: Revenue — the day's fact / forecast and the deviation from the forecast up to the current hour; SPMH and TPLH — fact / plan; Hours — the day's fact / planned hours (red once fact is already above plan); Compliance — the share of marks that matched the schedule: green above 90 %, orange above 70 %, red below. Under the tiles — Data on with the time of calculation.
Three buttons sit above the list. Add shift opens a person who is not in that day's schedule: search over the store team, and with the From current store checkbox off — over other stores; the button is available only with "Shifts can be clocked manually" enabled — the same checkbox turns the clock-in and clock-out controls in the rows on and off. ⚡ sets clock-in and clock-out by the schedule for everyone at once — after the question "Are you sure to set clock in/out time by scheduled shifts for all employees?". With "Shifts can be clocked manually" off the dialog says so separately: only the shifts already clocked in through biometry are set by the schedule, and no shift is created for anyone who did not clock in. Print exports a PDF of the list exactly as shown: same search, sorting and groups.
The list is split into Managers, Employees and No schedule. Columns: Name, Clock in/out, Schedule, Shift break (only with "Placed lunch breaks" enabled), Position, Hours. Clicking the "Name" or "Schedule" header sorts; the choice is remembered.
Edits are available when the role may edit actual shifts, the day is not beyond "Editing of shifts … closes on date" and the time sheet for that day is not yet approved (see the time sheet chapter). Otherwise the whole page is read-only.
The badge on the clock-out button sums up all the person's fact shifts of the day: a green check — all approved (Approved); an orange question mark — there is an edit with the status Awaiting approval; red — there is a Not approved (rejected) edit or a shift that is not counted: "Shift is before the hire date and is not counted", "Shift falls within an absence period (vacation/sick leave)" or "Shift started after the limit was reached — recorded with zero hours". A red badge with a check inside — the edit was rejected and the previously approved time applies: that is what the buttons show.
Start and finish a shift. While there is no clock-in mark, clicking "…" asks: "The shift opens at its scheduled start time. You can edit the clock-in afterwards." — with the Start shift button. While there is no clock-out mark — Finish shift: "Clock-in and clock-out of every shift this person has today will be set to the schedule. If the schedule is approved, the records are approved right away." Both buttons set the time by the schedule, not "now"; a person without a schedule has neither — their time is entered in the edit window.
Schedule — the "from – to" periods from the employee schedule or the manager schedule; a red prohibition sign — no schedule for the day. Position — a coloured dot and the position name; for managers — the shift type.
Clicking a time opens the "‹Name› — clock in/out" window. It has a row per fact shift of the day: the Clock In, Shift break (read-only — computed from the break ladder) and Clock Out fields. A time beyond the allowance from the settings will not save: "Clock out time is more than max hours before shift start" / "Clock out time is more than max hours after shift end" — see "Max allowed time before shift start" and "…after shift end". Two buttons sit at the right of a row: ↻ Reset to schedueled (clock-in and clock-out are set to the plan) and 🗑 Delete — the shift goes to the archive: it leaves the totals, but its history stays visible, dimmed. The Add shift button opens a second shift of the same day once the previous one is closed. Save writes only the changed times; such an edit enters the history with the status Awaiting approval.
History of changes — the table under the fields: Initator, Clock in/out, Comments, Time of change, Status. The top row is the one in force; below it — the whole history in a dimmed colour. Biometry and terminal marks are signed "Integration"; automatic trims (before opening, after the store closes, by the limits) are explained right in the comment.
Approval. The top record with the status "Awaiting approval" has two buttons: ✓ Approve — opens a window with the Select a reason field (ready-made wordings from the "Fact shift approval reasons" setting) and a comment — and ✕ reject with a mandatory comment. Who may approve employee shifts and who manager shifts is set by the role permissions (see "Access parameters"); for a person without a schedule either permission is enough. A rejected edit is not deleted: the last approved time becomes the one in force, and the day's badge turns red until a manager sorts it out. Statuses in the column: Approved, Awaiting approval, Not approved, Archived.
What gets approved on its own
Integration marks against an approved schedule are approved automatically while they stay within the "Max difference of fact shift vs scheduled" and "Max allowed time before shift start / after shift end" allowances; anything beyond the allowance stays awaiting approval. Against an unapproved schedule every mark waits for a manager.
With the "Hard daily hours limit / Hard weekly hours limit / Hard monthly hours limit (norm)" checkboxes on (see the rule in the settings) two marks appear on the page.
Manual time edits, "Reset to schedueled" and ⚡ go through the limit as well: time beyond the remainder is cut on save with an explanation in the comment. Hours can be freed only by archiving another shift of the same window. When several reasons apply to a day at once, the hint names the main one: before the hire date → absence period → hard limit.
The Print button exports the PDF "‹Store› Shifts_‹date›": a header with the store and date, the KPI tiles with deviations and the same Managers, Employees, No schedule groups in the current sorting and with the current search. Statuses are printed as glyphs: ✓ — Approved, ? — Awaiting approval, ✕ — Not approved, ○ — a clock-in without a clock-out; deviations from the schedule — signed. Shifts before the hire date, within an absence period and zeroed by the limit are marked with footnotes under the table, the ones cut by the limit — with an asterisk next to the hours. Colours in the PDF are hints only: black-and-white printing loses nothing.
Block
The summary of hours actually worked over a period and its multi-level approval. An approval closes fact-shift editing up to and including the stated day.
The "Time sheet" page shows the fact hours of the selected store's team for the selected period — as a list by employee or as a calendar by day — and this is where the time sheet is approved.
Pick a Store and a Period in the header. Next to them — a search over employees: by name, "System employee ID" or "Additional ID". On the right: Filters (roles, Shifts — Store only or Whole team, and Show dismissed employees), the "list ↔ calendar" toggle, Print, Approve ✓ and Cancel approval ✕.
The approval level comes from the user's role — see "Role rate and time sheet approval level". Without a level both buttons are inactive. The approval covers the last completed day of the period (never later than yesterday).
Shifts hit by the hard hours limit. A shift recorded with zero hours (the limit was already used up before the clock-in) is shown in the calendar with a red cross and "- -" instead of hours, and in the employee window — with a single clock-in time; it enters the totals as zero. A shift cut by the limit keeps its status but gets the scissors ✂ (in the calendar — an orange dot in the cell corner); the hint names the window: "Shift cut at the hard hours limit (Weekly hours limit reached)". In the employee list a red counter of such shifts stands next to the name — "Shifts hit by the hours limit". In the printed form the days with zero-hour shifts are highlighted red. The same icons stand on the "Shift" page: on the card, in the "Clock in/out" window and in the history of changes.
All three buttons — Print, Approve ✓ and Cancel approval ✕ — open the same Select stores window: search by name, checkboxes, Select all and Reset. Print exports one file covering every ticked store; approving signs each of them off for the selected period, and cancelling lifts that signature.
The current store is ticked in advance — provided the chosen action is available for it at all. The rest are greyed out with the reason. When approving that is Already approved — your level has already signed the time sheet off through that day; when cancelling it is Not approved — there is nothing to lift. Common to both actions is Approved at a higher level: the signature above must be cancelled first.
Stores are handled one by one. If some of them fail, the window stays open and shows Could not be approved (or Could not cancel the approval) with their names: the others are already done and need no second attempt.
An approval closes fact-shift editing up to and including the stated day — on the "Day overview" page and in the corrections report too; cancelling reopens it. Cancelling lifts the topmost signature that is not above your own level, so calling it again lifts the next one down.
Block
The "People Planning Review" report: how many people the stores have and what team mix, compared with the ideal structure; HR statuses, the action plan and employee certifications. The month is fixed by a snapshot and approved at three levels, like the time sheet.
The "PPR" item of the main menu opens the whole structure available to you — from the network down to a store — for the chosen month.
Header. Unit — your branch of the structure; Back in the caption line goes one level up. If no unit is assigned to the account, the page shows "No structure assigned".
Month. It is switched with the Previous period and Next period arrows; Current month brings you back to the current one. Future months are unavailable. The current month is calculated live, a past one — from the saved snapshot (see "PPR month"). If some of the stores have no snapshot, a yellow No snapshot banner appears at the top: for those stores the current data is shown. The month is kept in the page address, so the link can be shared.
Charts.
| Structure | Average monthly sales | Manager | Cashier | Cook | Trainee | |
| North region | 9 400 000 | 11 / 12 92 % 2 | 30 / 32 | 24 / 26 | 14 / 12 | › 3 |
| Abay St. store | 12 100 000 | 3 / 3 100 % | 6 / 7 | 5 / 5 | 2 / 2 | › |
Columns of the "Structure" table. A row is a unit or a store.
If the store itself is selected in the header, the table is replaced by the Open restaurant PPR button. On a phone the table turns into cards: the name, "Average monthly sales" and the staffing of "Employees" and "Managers".
If the selected structure has no stores, the table is replaced by the No stores in this structure card with an Open settings button: stores and the ideal structure are set up in the "Admin" section.
How the month is fixed, who approves it and how, and when edits close.
Snapshot.
Month history. When a single store is selected, the month is picked from the Month history list: the saved months and the current one, marked "Current month", "Snapshot", "No snapshot", "Approved". For a group the months are browsed with the arrows. The month chip has an Approved by tooltip: the levels, names, "As of" dates and the snapshot time.
The Approve the PPR ✓ and Cancel the PPR approval ✕ buttons are available to roles that have a "PPR approval level". Both open the Select stores window, as in the time sheet: search, checkboxes, Select all and Reset; unavailable stores show the reason. When approving, you pick the As of date (within the month, no later than today) and can leave a Comment. Stores are handled one by one; the window lists the ones that failed.
Level rules — as in the time sheet.
Notifications. "Month PPR approved" and "Month PPR approval cancelled" go to the store's PPR editors and to every level above. Whoever pressed the button gets no notification.
HR statuses, comments, actions and certifications can be changed only if all the conditions hold:
If editing is closed, the store page shows a banner with the reason (for example, "The month is approved, editing is closed"), and the editing buttons are hidden. The data stays visible.
The store's people for the month: HR statuses, comments, the action plan, certifications and the Excel export.
The page opens from the "Structure" table or with the Open restaurant PPR button. In the header: Store (the month is kept when you switch stores), Back to the overview, the month and the state chip, Take a snapshot, ✓ and ✕ — for this store only — and Download. The month can also be switched to the next one, marked "Upcoming": its HR statuses, comments and action plan are filled in ahead of time; an upcoming month can be approved once it starts. Tabs: Overview, Certifications and Action plan.
The page's data is refreshed after every change, when you switch tabs and when you return to the window; changes made in another browser tab (in the certification catalog, for example) are picked up by themselves. If the data cannot be refreshed, Couldn’t refresh the data appears above the tabs with a Retry button — until then the screen shows the last data that loaded.
The same two charts as in the overview, and the Employees table, split into Managers team and Employees team. The columns:
The table always shows the store's current team; the statuses, the comment and the actions shown are the ones valid in the chosen month. A click on the row or on the arrow at its end opens the employee panel.
Columns. The Columns icon in the right corner of the table header opens the list of columns: the checkbox hides a column, the arrows move it. "Name" always comes first. The choice is saved for you only, in this browser; Reset brings back the default view. Once the charts scroll away, the table header stops under the tabs and the rows scroll beneath it.
HR status. An employee can have only one status in a month. A click on the cell opens the list of suitable statuses: choosing another one replaces the current one, and No status removes it. The chosen status has a Status note field, and if the status requires it — a Key date too. The ↩ icon means that the status was carried over from the previous month. If you replace or remove a carried-over status, it disappears from the current month but stays in the past months. If a status is already set in advance for the next month, the carried-over one stops before it. If a month saved earlier holds several statuses for an employee, the list asks you to choose which one to keep.
Comment. Each month has its own; it does not carry over to the next month. It saves automatically; the Comments from the previous months button shows the earlier ones.
The employee panel brings everything together: statuses, the comment, "Planned actions" and certifications with their granting history.
Matrix. Rows are employees (the "Employees" / "Managers" switch picks the group), columns are the active certifications of the catalog: position certifications first, then role certifications. The tab is there in both modes. The cell colour shows the state: "Valid", "Expiring", "Expired"; the cell holds the expiry date, ✓ — a never-expiring certification. The number of people, "Today: <date>" and the state colours are in the matrix's top-left cell; while you scroll, the matrix header stays under the tabs.
An empty cell without "+" means that this certification cannot be granted to the employee's role. An employee who already holds the certification keeps it and can renew it. If someone holds a certification of the other group (for example, a manager holding a certification for employee positions), its column appears on their side too: that certification can be renewed or revoked there, but not granted to this group. Archived certifications are not in the matrix, but granted ones stay with the employees. The bell reminds the PPR editors of the employee's main store about a certification's expiry.
Empty catalog. While the catalog has no certifications at all, the tab shows a grey card, No certifications yet, instead of the matrix and the row above it. An administrator fills the catalog right from it: Add certification opens the same dialog as in the PPR settings (access "To positions" is picked first; it can be switched to "To roles"), and Create from the positions, after a confirmation, creates one never-expiring certification for every position that requires one and grants nothing to anybody. Once the dialog is closed, the matrix appears on the tab. Everyone else is told that certifications are set up by an administrator. In a closed month there are no buttons.
The card also stands in for the matrix in the other empty cases: Every certification is archived, nobody in the selected group (a button in the card switches to the other group), or No certifications for this group. Only the "Employees" / "Managers" switch stays above it.
An action is added in the employee panel: Action, Details, Due date and Assignee. Action statuses: "Planned", "In progress", "Done", "Cancelled".
The Action plan tab — all the store's actions for the month in one table. Filters: Status, Employee, Overdue only, Including those who left. Tick several rows and close them at once with the Mark as done (N) button.
Due-date reminders arrive in the bell as many days in advance as set in "Remind in advance, days". They go to the store's PPR editors, the action's author and its assignee.
While the month has no actions at all, the table is replaced by the No actions card with a Go to the team button: actions are added on the "Overview" tab. Only Including those who left stays above the card — it can bring back the actions of people who left.
Download saves the file PPR_<store>_<month>.xlsx. It has a single sheet, with the blocks going from top to bottom:
Several actions go on separate numbered lines of the cell, in the same order in all four columns. An overdue due date is highlighted in red and marked "Overdue".
A certification cell holds the month and year of expiry ("MM.YY") on the state colour, ✓ — never expires, a grey cell — the certification cannot be granted to the employee's role, an empty one — no certificate. The certification names in the header are rotated and wrap at spaces.
| Process | Which settings affect it |
|---|---|
| Auto-scheduling | Deployment (positions and ladders) · min/max shift duration · max position changes · hours before opening/after closing · max weekly hours · max shifts in a row · min days off in a row · hours between shifts · night window · shift start rounding · placed lunch breaks · personal limits in cards · underage restrictions · hard hours limits |
| Hard hours limits | "Hard daily hours limit / Hard weekly hours limit / Hard monthly hours limit (norm)" · min/max shift duration · max weekly hours (general, personal in the card, underage) · the "Weekends and holidays" calendar and the fallback calendar · the employee's absences · the break ladder and the role's "Consider lunch breaks" checkbox |
| Schedule accuracy | Deployment · "Min. … schedule accuracy" (threshold) · "Lunch breaks impact accuracy" · "Training hours do not impact accuracy" · the position's "Based on weekly revenue" flag · the manager shift's "Does not impact accuracy" flag |
| Approval and statuses | Role permissions (approval, return to draft) · "Min. employee / manager schedule accuracy" · "Allow print schedule before approval" · "Employees see only approved shifts" · "Schedule deletion is not allowed" · editing depth |
| Fact time tracking | "Biometry shift break" · mark rounding · trimming to opening · "Max difference of fact shift vs scheduled" · approval reasons · "Shifts can be clocked manually" · rewriting of opened/closed shifts · the "Can edit/approve … fact shifts" permissions · hard hours limits |
| Time sheet and period closing | "Time sheet approval level" of roles · "Editing of shifts … closes on date" (previous and current month) · hours total rounding |
| Cost of labor (COL) | Rates: personal → role → default · labor tax ratio · night hours ratio · night window · break ladder · the role's "Consider lunch breaks/special calculations" checkboxes · snapping the rate date to the 1st |
| Productivity: SPMH / TPLH / IPLH | Revenue forecast (sales, transactions, menu items) · the staffed and recommended hours · "Count opening and closing non-productive hours" · "Training and NSO hours do not impact SPMH / TPLH / IPLH" · the position flag "Does not impact SPMH/TPLH" · the position flag "Based on weekly revenue" · hours before opening / after closing (they define the window itself) |
| Manager schedule | Shift types (concepts, roles, repetition cycle, time, monthly revenue minimum) · "Used in managers schedule" of roles · "Min. manager schedule accuracy" · max weekly hours (the month norm) · hard hours limits · fallback calendar · editing depth |
| PPR and team structure reports | Ideal structure (tiers by concept) · "Used in managers schedule" on roles · "Can edit the PPR" and "PPR approval level" · "PPR settings" (editing window, reminders, position and role access approach) · "Can train employees" on roles · HR statuses · certifications · the card's "On training" and "All positions" flags, priority positions · deployment (ideal headcount) · sales forecast (tier selection) |
| Position and role access | "Position and role access approach" · the position's "No certification required" checkbox · the certification catalog (positions and roles) · role job titles · "On an untrained position only with an instructor" · employees' granted certifications |
| Recommendations and forecast | Store revenue forecast (Overview → "Revenue") · sales history (hourly shares over 5 weeks) · deployment · the positions' order channels · working hours and "Preparation and cleaning" from the store card |
| Employee cabinet | Language · first day of week · break ladder (worked hours) · schedule preferences and the "do not consider preferences" days · visibility of unapproved shifts ("Employees see only approved shifts") · hard hours limits (marks on shifts) |