ScaleX Dashboard runs inside the Manhattan WMS UI as an embedded iframe. Users open it from Manhattan — there is no separate login or URL to remember. Manhattan handles the authentication and passes a session token to ScaleX automatically.

Token Delivery

When ScaleX loads inside the iframe, it performs a handshake with the parent Manhattan page. Manhattan reads the current authentication token and sends it to ScaleX via a postMessage. ScaleX stores the token locally and attaches it to every API request.

Validation

On each API request, the ScaleX backend checks the token against its own database. If a matching user is found, the request is authorised immediately — no external call is needed. If the token is not recognised, the backend validates it against the Manhattan Scale API to retrieve the username, then stores the mapping for future requests.

Automatic Token Refresh

Manhattan monitors its own authentication token. When the token is refreshed by WMS, Manhattan automatically sends the updated token to the ScaleX iframe. ScaleX stores the new token and re-validates on the next request — no user action required.

Token Expiration

ScaleX automatically expires stored tokens after a configurable period of inactivity. Each time a token is received or refreshed, a timestamp is recorded. The background sync service periodically checks for tokens that have exceeded the configured lifetime and clears them from the database. On the next request, the token is no longer recognised locally, so the backend re-validates it against the Manhattan Scale API — the process is fully automatic and transparent to the user.

If validation fails (expired token, server unreachable, network issue), ScaleX shows an error screen with the option to close the window.

ScaleX does not read directly from the Manhattan WMS database in real time. Instead, a background sync service periodically copies relevant data from WMS into ScaleX's own database. This ensures fast dashboard queries without impacting WMS performance.

Sync Cycle

A hosted background service runs continuously while the application is active. It performs a sync cycle at a configurable interval (default: every 5 minutes). The interval and enabled/disabled state are configurable. Each cycle performs:

Managed in the Announcements page. Announcements let managers publish messages visible to specific users, or the entire warehouse — optionally restricted to a particular page within the application.

Targeting

• User targeting — target a specific user by username, or check All users to broadcast to broadcast to everyone.
• Page targeting — restrict the announcement to a specific page (by pathname), or check All pages to display it globally across the application.

Scheduling

Every announcement has a Show From and Show To date and time. The system automatically calculates the current status:

Announcement Properties

Management

• Create — fill in content, targeting, and schedule. The announcement becomes visible to matching users as soon as the Show From time arrives.
• Edit — modify content, targeting, or schedule at any time.
• Copy — duplicate an existing announcement as a template for a new one.
• Delete — remove a single announcement, or select multiple and delete in bulk.

The messaging module provides two-way communication: managers can send messages to warehouse users from ScaleX, and warehouse users can send feedback directly from the Manhattan WMS interface.

Views

• Inbox — received messages, including feedback sent by warehouse users from WMS. Unread messages are highlighted. Click a message to read it, reply, or delete it.
• Sent — messages you have sent. You can review, edit, or delete sent messages.
• Compose — create and send new messages to one or more recipients.

Composing Messages

• Recipient selector — a searchable tags input with autocomplete. Type a username to find it, or click the down arrow to browse the full list. Select multiple recipients to send the same message to all of them at once.
• Send to all — check this option to send the message to every user in the system.
• Message content — free-text message body.
• Image attachments — drag and drop or browse to attach images. Supported formats: PNG, JPG, GIF, WebP, BMP, SVG, TIFF. Maximum 10 MB per file.

After sending, a results summary shows how many messages were delivered successfully and flags any failures per recipient.

Replying & Threading

Each inbox message has a Reply button. Replies are linked to the original message, so both sides of the conversation are visible together. If a message has already been replied to, the button switches to Edit, letting you update your existing reply. Clearing the reply text and saving removes the reply entirely.

WMS Feedback

WMS users see a Send Feedback button in the top navigation bar of Manhattan WMS.. It opens a dialog where they can send feedback about the WMS system to Logistics Systems Support, and optionally attach a screenshot.

Message Properties

Management

• Edit — modify the content of a sent message or a reply.
• Delete — remove a message permanently.

My Pages is the dashboard system. Every user gets their own collection — fully customisable, personal, synced to server. No limit on page count.

Where My Pages Live in the UI

Pages appear in two places:

• Sidebar — under a collapsible "My pages" section. Each page is listed by name as a clickable link. The sidebar updates instantly when pages are added, renamed, or deleted.
• Settings → Customise My Pages — a dedicated management view where users create, rename, edit descriptions, and delete pages.

Creating a Page

In Customise my pages, click "Add new page". A dialog opens with two fields:

• Page name (required)
• Description (optional)

The name must be unique across the user's pages. On success, the page appears in the sidebar immediately and starts with an empty grid.

Editing & Deleting a Page

Each page has a "⋯" dropdown menu with "Edit page" and "Delete" options. Editing name or description never affects the widget layout. Deletion is immediate — the page, its widget layout, and all cached data are removed. Bulk delete is supported.

Edit Mode

Click the "Edit" button in the page header. The grid becomes interactive — widgets can be dragged, resized, added, and removed.

What you can do in edit mode:

• Move widgets — drag by the header to reposition. Other widgets shift automatically to avoid overlap.
• Resize widgets — drag the bottom-right corner handle. Each widget type has minimum size constraints.
• Add widgets — pick a type from the dropdown. The widget appears in the first available space with default size.
• Remove widgets — each widget has a remove button (×) visible in edit mode.

Saving & Discarding

Saving: Click "Done". The entire layout — every widget's position, size, type, colours, pagination settings, and filters — is saved to the browser instantly and synced to the server in the background. Saving is optimistic — the local cache updates immediately, and if the server is unreachable, the app continues working with cached data.

Discarding: Restores the layout to exactly how it was before entering edit mode. Nothing is saved.

Unsaved Changes Protection

Navigating away, pressing Escape, or closing the window while in edit mode triggers a confirmation dialog with three options: Save, Discard, or Cancel (stay and keep editing).

The Grid

The grid is 24 columns wide. Widgets snap to grid positions — no freeform placement. This ensures clean, aligned layouts.

• Widgets pack upward automatically — no empty gaps between rows.
• The grid expands when widgets are added and contracts when they are removed.
• Smooth animations on move and resize.
• On narrow screens (mobile), the grid switches to a single-column stacked layout. Desktop and mobile layouts are maintained independently.

Widget Types Available

Each page can contain any mix of these five widget types. Multiple instances of the same type are allowed.

Widgets with colour controls let you customise chart colours, segment colours, or ranking colours — saved per widget as part of the layout.

The Summary widget is the main KPI overview for the warehouse. It consists of a header with controls, four KPI summary cards, a bar chart, and a click-through to a detailed day breakdown.

Header & Filters

The header shows a dynamic title (e.g., "All Departments KPI Overview" or the name of the selected department), a Refresh button to reload data on demand, and a Filters button.

The Filters popover contains:

• Department selector — choose "All Departments" or any specific department. Changing the department reloads all data and adjusts the available metrics.
• Date range — "From" and "To" date pickers with calendar dropdowns. If the selected range extends beyond what has already been loaded, an "Apply" button appears to fetch more data from the server.

KPI Summary Cards

Four KPI cards arranged in a row. Each shows the metric name, its average value over the selected date range, and a trend indicator (percentage change and up/down arrow). The active card is highlighted. Clicking a card switches the chart below to show that metric's data.

Trend arrows show whether performance is improving or declining — calculated by comparing the average of the first half of the selected date range against the second half.

Bar Chart

Below the KPI cards, a bar chart displays daily values for whichever metric card is currently selected. Each bar represents one day. Hovering over a bar shows a tooltip with the exact date and value.

Clicking a bar opens the Daily Breakdown — a slide-out panel with a full breakdown of that specific day.

Filter Persistence

All filter selections — active chart tab, selected department, selected custom metric, and date range — are persisted as part of the widget layout. They survive page refreshes and are saved when the user clicks "Done" in edit mode.

The Daily Breakdown is a slide-out side panel that opens when clicking on a day bar in the Summary widget. It provides a deep drill-down into all operational data for a single day.

Header & Leader Note

The header shows the department name (or "All Departments") and the full formatted date (e.g., "Monday, 14 April 2025").

Below is a Leader Note section — a space for leaders to leave daily context notes (e.g., "Short-staffed due to training day"). If a note exists, it is displayed with the author's name and the date it was last updated. Leaders can click the edit icon to open a text editor where they can write or modify the note. Notes are saved per day and per department (or warehouse-wide if viewing All Departments), and editing is permission-based — only users assigned as leaders for the relevant department can edit.

Navigation Tabs

Performance Tab

Shows employees with performance data as clickable rows. Each row displays name, hours worked, and performance percentage — colour-coded performance thresholds. Clicking any employee row opens the Employee KPI Modal.

Sub-filters: Top (highest first — shows the highest performance value, e.g., "Top 112%"), Bottom (lowest first — shows the lowest value, e.g., "Bottom 62%"), and By Department (All Departments mode only). By Department groups employees into expandable department cards showing name, employee count, and average performance. Expanding a card reveals a history bar chart of daily performance (last 7 days by default, switchable to last month or a custom range), a trend indicator, and a sorted employee list within that department.

Performance tab — Top performers sorted by highest performance percentage

Click to enlarge

By Department — expandable cards with history charts per department

Click to enlarge

Activity Tab

All Departments — Inactivities view: Lists every department as an expandable card showing department name, employee count, and average idle time in minutes. Expanding a card reveals a trend indicator and percentage, a history bar chart of daily average idle time (last 7 days by default, switchable to last month or custom range), and a list of employees with their name and idle time. Employees can be sorted alphabetically or by idle time (ascending/descending). Clicking an employee opens the Employee KPI Modal.

Specific Department — Processed/Outstanding Metrics: Two sub-filters with counts. Each metric is displayed as an expandable card showing the metric name and current daily value with unit. Expanding reveals a trend indicator — for "processed" metrics upward trends are green (positive), for "outstanding" metrics the logic is inverted (downward trends are green, as reducing outstanding work is good). A history bar chart shows daily values using the metric's configured colour, with the time range switchable between Last Week, Last Month, or a custom calendar range.

Inactivities — All Departments overview

Click to enlarge

Processed metrics — specific department

Click to enlarge

Headcount Tab

Shows the day's headcount broken down by employee status. Four sub-filters, each showing its count: Unverified employees with transactions whose timeline has not been verified, Working verified working employees, Holiday employees on holiday, Absence employees marked as absent.

For each filter, departments are listed as expandable cards showing department name and employee count. Expanding a card reveals a trend indicator, a history bar chart of the daily count for that status (last week by default, switchable), and a list of individual employees sortable alphabetically or by verified/unverified status. Clicking an employee opens the Employee KPI Modal.

Headcount — status breakdown with expandable department cards

Click to enlarge

Hours Tab

Shows the day's hours breakdown. Three sub-filters: Direct (total direct hours), Indirect (total indirect hours), and By Department. A summary bar at the top of each filter shows the overall average (e.g., "Average Direct Hours (All)").

Direct and Indirect filters list activities as expandable cards. Each card shows the activity name, total hours, average hours per employee, and employee count. Expanding reveals a trend indicator, a history bar chart of daily hours for that activity, and an employee list showing each person's hours — sortable alphabetically or by hours. By Department lists departments with the same structure. Clicking an employee opens the Employee KPI Modal.

Hours — Direct vs Indirect breakdown with history charts

Click to enlarge

Opens when clicking on any employee name anywhere in the Daily Breakdown. Provides a comprehensive individual performance profile.

Header

Shows the employee's name, their department, and a date range selector. The default range is based on the context from which the modal was opened (typically anchored around the selected day). The user can change the date range to analyse a different period — all data in the modal updates accordingly. There is also an employee selector (searchable dropdown) to switch to a different employee without closing the modal.

Overview Tab

Two half-circle donut charts side by side:

• Attendance — a semicircular chart showing the percentage of scheduled time the employee was present vs absent.
• Work Distribution — a semicircular chart showing the split between Direct hours (blue) and Indirect hours (purple).

Functions Tab

Performance sub-tab

A summary bar at the top shows: direct hours, indirect hours, the ratio between them (with a visual proportion bar), average performance percentage — colour-coded performance thresholds — and the count of direct vs indirect functions.

Below, each activity (function) the employee worked on is listed as an expandable card. Each card shows the activity name, whether it is direct or indirect, hours worked, and for direct activities a performance percentage. Expanding a card reveals a daily bar chart — showing daily performance % for direct activities or daily hours for indirect activities — with a trend indicator.

Inactivities sub-tab

Shows the employee's average idle time, colour-coded against a target: green if within target, amber if within 125% of target, red if above. Each activity the employee worked on is listed with idle time statistics: average idle time, median idle time, max idle time, gap count, and transaction count. Expanding an activity shows a daily bar chart of idle time for that specific activity.

Notes Tab

A notes system for recording observations about an employee. Leaders can add notes with a type: positive, neutral, or negative. Adding and deleting notes is permission-based — notes can be deleted by the user who created them.

A full timeline-based tool for reviewing and verifying employee activity throughout their shift. Its purpose is to account for every minute of an employee's workday by identifying time periods where the system could not automatically recognise what the employee was doing (gaps) and allowing leaders to manually assign activities or absences to those periods.

Header Controls

• Refresh button — reloads all timeline data and pending days.
• Previous / Next day buttons — navigate one day backward or forward.
• Filters button — opens the filters popover. Displays the currently selected date and a pending days badge — a small circle showing how many days still have unresolved gaps (red if pending, grey if zero).
• Settings button — opens the gap settings popover.

Filters Popover

• Show only with gaps toggle (default: on) — when enabled, only employees with at least one unresolved gap are displayed.
• Show only with transactions toggle (default: on) — when disabled, all employees in the department appear, useful for identifying no-shows.
• Department selector — "All Departments", a specific department, or "Unassigned" (employees not yet assigned to any department).
• Date picker — a calendar where days with unresolved gaps are marked with a red dot below the day number, making it easy to spot which days need attention.

Gap Settings

Gap Threshold (default: 15 minutes)

Controls how the system distinguishes between normal pauses in work and genuine idle periods that need attention. When an employee finishes one transaction, the system starts watching the clock:

• Next transaction arrives before the threshold — the time between the two transactions is treated as continuous work. KPI for the previous activity is calculated all the way up to the moment the next transaction begins. No gap is created.
• Next transaction arrives after the threshold — the system creates a gap segment covering the entire period from the last transaction to the next one. This gap appears on the timeline as an amber "?" segment that a leader must review and assign.

Start Threshold (default: 10 minutes)

Controls how the system handles the beginning of a shift before the employee's first transaction.

• First transaction within the threshold — the system assumes the employee was working from the beginning of their shift. KPI for that first activity is calculated starting from the shift start time, not from the first transaction.
• First transaction after the threshold — the system creates a gap from the shift start to the first transaction. This gap must be assigned by a leader.

When either threshold value is changed, a "Save Settings" button appears. Saving regenerates all unverified timelines using the new thresholds. Already verified timelines are not affected.

Statistics Bar

Search Bar

Below the statistics bar, a search input allows filtering employees by name. Results update as the user types. A clear button (×) resets the search.

Employee Timeline List

Paginated list (5 or 10 per page, configurable in the footer). Each employee row contains:

Employee Card

• Avatar — circle with the employee's initials.
• Name — clickable, opens the Employee KPI Modal.
• Department — displayed next to the name. Clicking it opens a dropdown to reassign the employee to a different department or mark them as "Unassigned".
• Shift time inputs — two editable time fields (HH:MM – HH:MM). The cursor automatically advances through the fields (hours → minutes → next field), so a full shift time can be entered without lifting hands from the keyboard. Arrow keys and Tab can also be used. The time is saved when the user leaves the field, presses Enter, or finishes typing in the last field.
• Status badge — Setup (no shift configured), X gaps (unresolved count), or Verified (with undo button).

Agency User Accounts

For employees whose username starts with "agency." (shared/temporary accounts used by agency workers), an additional User Assignment Popover appears instead of the regular name. This allows leaders to assign a real person's identity to the agency account for that day. The popover shows a searchable list of temporary users and the ability to create new ones by entering a first and last name.

Timeline Bar

Below each employee's header is a horizontal timeline bar representing their entire shift (or expanded to cover all transactions if they extend beyond shift boundaries). The timeline is divided into colour-coded segments:

Overtime indicators: If the shift is longer than 8 hours, an overtime line is drawn at the 8-hour mark. If the employee has transactions beyond their shift end, the timeline extends past the shift and time labels beyond the shift end are displayed in yellow. KPI is calculated up to the last transaction, not the shift end — the employee receives credit for the full working period.

Pre-shift transactions: If an employee has transactions before their shift start time, the timeline extends backwards to include them. KPI is calculated from the first transaction, not the shift start — the employee receives credit for the full working period.

Time labels: Below the timeline bar, hour markers show the progression of time (e.g., 06:00, 07:00, 08:00…) with the shift start and end times at the edges.

Resolving a Gap

Clicking on an amber gap segment ("?") opens a dropdown with:

Time Range Header

At the top, the gap's time range is displayed (e.g., "10:15 – 11:30"). The end time is editable — the user can change it to split the gap. For example, if a gap runs from 10:15 to 11:30 and the user changes the end time to 10:45 before selecting an activity, only the 10:15–10:45 portion is resolved, and a new gap is automatically created for the remaining 10:45–11:30 portion.

Activity Selector

A searchable list of activities grouped into three categories: Direct (activities with measurable output), Indirect (supporting activities — no KPI), and Other. Each activity shows its colour swatch and name. If the gap had transaction data spread across multiple activities, the transaction count per activity is displayed, helping the leader make an informed decision.

Absence Types

Below the activities, a separate "Absences" section lists all configured absence types (e.g., Holiday, Sick Leave, Unauthorised Absence). Selecting an absence type opens the Absence Modal instead of immediately resolving the gap.

When an activity is selected, the gap is immediately resolved — the segment changes from amber to the activity's colour, the gap count decreases, and the statistics update in real-time. The resolution is saved to the server in the background.

Modifying an Existing Segment

Clicking on any already-recognised activity segment (including manually resolved ones) opens a dropdown with:

• Change activity — allows selecting a different activity. If the segment has transaction data, only activities with matching transactions are shown. Selecting triggers a confirmation dialog displaying the current and proposed activity side by side with an arrow between them.
• Add/Edit note — attach a text note to the resolution explaining the assignment (e.g., "Confirmed with team leader — employee was helping in receiving").
• Clear assignment — removes the manual resolution and reverts the segment back to a gap. Only available for segments that were manually resolved.

For absence segments, the dropdown shows:

• Edit absence — opens the Edit Absence Modal to modify absence details.
• Clear absence — if the absence is part of a multi-day series, a dialog asks whether to delete just this single segment or the entire series across all days.

Absence Modal (Create)

Opened when selecting an absence type from the gap dropdown. Contains:

• Absence type — pre-selected based on what was clicked (shown with colour swatch).
• Date From / Date To — calendar pickers. Defaults to the currently selected day. Can be extended to span multiple days (e.g., for a week-long holiday), which creates an absence series.
• Time From / Time To — time inputs. Defaults to the exact gap boundaries.
• Notes — optional free-text field for additional context.

Saving creates the absence and resolves the corresponding gap(s). If the date range spans multiple days, an absence entry is created for each day in the range (an absence series).

Edit Absence Modal

Opened when clicking "Edit absence" on an existing absence segment. Contains the same fields as the Create modal, plus the ability to change the absence type via a dropdown listing all available types with their colour swatches. The date range and time range can also be modified.

Delete Absence

When clearing an absence that belongs to a multi-day series, a dialog presents two options: "Delete this segment only" (removes only the current day's absence, leaving the rest of the series intact) or "Delete entire series" (removes all absence entries across all days). For single-day absences, a simple confirmation dialog is shown.

Undo Verification

When an employee's timeline is fully verified (green "Verified" badge), an "undo" button appears. Clicking it opens a confirmation dialog warning that all resolutions and absences for that employee on that day will be removed. The timeline resets to raw transaction data and recalculates gaps using the current gap settings. The employee's KPI data for that day is also cleared.

Auto KPI Calculation

When the last gap on an employee's timeline is resolved, the system automatically: marks the employee as "fully verified" for that day, calculates and saves KPI metrics (total hours, direct hours, indirect hours, performance percentage, transaction counts) based on the verified timeline, and updates the pending days tracker — if all employees for a given day are now verified, that day is removed from the "Days behind" count.

If any resolution is later changed, cleared, or a verification is undone, the system automatically recalculates KPI metrics. If all gaps remain resolved after the change, the employee stays verified with updated KPI values. If a gap is reopened, the KPI data is removed and the day returns to the pending list.

Filter Persistence

All filter selections — date, department, show only with gaps, show users without transactions — are persisted as part of the widget layout and survive page refreshes.

Analyses idle time between WMS transactions for each employee on a given day. Ranks employees by their average idle time and provides a visual breakdown of how inactivity periods are distributed throughout the shift. The purpose is to identify employees who spend too much time between moves (transactions) — which may indicate inefficiency, equipment issues, or areas needing attention.

How Inactivity is Calculated

An "inactivity" is the time gap between two consecutive WMS transactions for the same employee. For example, if an employee scans a pick at 10:15:00 and their next scan is at 10:18:30, that's a 3.5-minute inactivity. The widget collects all such gaps throughout the day and computes statistics (average, median, max).

Inactivities that exceed the exclusion threshold (configurable, default 25 minutes) are excluded from the average calculation. These are considered outliers — likely breaks, meetings, or other planned absences rather than genuine idle time. They still appear on the timeline but are visually separated and don't inflate the average.

Header

• Refresh button — reloads all data.
• Previous / Next day buttons — navigate one day at a time. Future dates are disabled.
• Date picker — calendar to jump to any date (up to today).
• Thresholds button — opens the thresholds popover.

Thresholds Popover

Controls how inactivity durations are colour-categorised. Four colour bands are defined by three configurable threshold values. The thresholds enforce ordering — each must be higher than the previous. A live legend preview at the top of the popover shows the current ranges. Changing any threshold immediately clears and recalculates all timeline previews.

Search Bar

Filters employees by name. Results update as the user types.

Employee List

A paginated list (5 or 10 per page) of employee cards, sorted by average idle time descending (worst performers at the top). Each card shows:

• Avatar with initials, name, and department.
• Average idle time — the main metric, displayed prominently on the right.
• Preview timeline bar — a thin horizontal bar showing the distribution of inactivity durations throughout the shift, colour-coded by the threshold bands. A mostly green bar means the employee was consistently fast, while orange segments indicate problem periods.

The preview timelines use a two-tier loading approach: the initial API call loads the lightweight employee list (names, stats), then a second call lazily loads the timeline preview data only for the currently visible page. This keeps the initial load fast.

Clicking an employee card opens the Employee Detail Drawer.

Employee Detail Drawer

A bottom drawer that slides up when clicking an employee.

Header

Employee name (clickable — opens the Employee KPI Modal) and department.

Metrics Grid

Four stat cards in a row:

• Avg Idle (green) — average inactivity duration, excluding outliers above the threshold.
• Median (blue) — the median inactivity duration.
• Max Idle (orange) — the longest single inactivity recorded.
• Transactions — the total number of WMS transactions for the day.

Full Timeline

A horizontal bar chart similar to the preview but larger and interactive. Consecutive inactivities of the same colour band are grouped into segments. Each segment represents one or more inactivities that fall into the same threshold category and occurred sequentially. Segments are clickable — hovering shows a tooltip with the average duration, count of inactivities, and time range. Small segments are guaranteed a minimum visual width so they remain visible and clickable.

A colour legend below shows the four bands with their current threshold values.

Segment Detail Sheet

Clicking a segment on the drawer timeline opens a right-side sheet with a detailed breakdown of every inactivity within that segment group:

Group Summary

• Count — how many individual inactivities are in this group.
• Average — average duration across the group.
• Total — combined duration of all inactivities in the group.
• Time Range — the start and end time of the group.

Individual Inactivities

Each inactivity is displayed as a card showing:

• Inactivity number and duration — with a colour-coded badge matching the threshold band.
• Transaction Before — the WMS transaction type and time that occurred immediately before this idle period, plus the work type (e.g., "PICK").
• Transaction After — the WMS transaction type and time that ended this idle period, plus the work type.
• Excluded badge — if the inactivity exceeds the exclusion threshold, a warning badge indicates it was excluded from the average calculation.

This level of detail allows leaders to understand exactly what happened — which transactions bookended each idle period, whether the employee switched work types, and at what time of day the idleness occurred.

Pagination

Footer contains rows per page selector (5 or 10), page indicator ("Page X of Y"), and Previous/Next buttons. When searching, the filtered result count is displayed.

Filter Persistence

All settings — date and all three thresholds — are persisted as part of the widget layout and survive page refreshes.

Ranks employees by their average performance percentage over a configurable date range. It answers the question "who are our best (or worst) performers across a given period?" Performance is calculated as actual output versus the standard target defined on each activity (Standard Per Minute × minutes worked). An employee averaging 105% is producing 5% above target; one averaging 78% is significantly below.

Header

The header displays a dynamic title — switching between "Top Performers" and "Bottom Performers" depending on the current mode. A Filters button opens the filters popover and shows the currently selected date range as a summary label.

Filters Popover

• Display Mode — toggle between Top (sorted by performance descending, best first) and Bottom (sorted ascending, worst first).
• Department — dropdown to filter by a specific department or view "All Departments".
• Date Range — a two-month range calendar picker. The widget aggregates performance across all days in the selected range. Default: January 1st of the current year to today.
• Display Count — 10, 20, or 50 employees returned.

Changing any filter immediately re-fetches data from the API.

Search Bar

Filters the returned performer list by name. Real-time filtering as the user types.

Employee Cards

A paginated list of employee cards ranked by performance. Each card shows:

• Rank badge — numeric position (1, 2, 3…). In Top mode, the first three positions have special styling: gold (#1), silver (#2), bronze (#3). In Bottom mode, all ranks use the default neutral style.
• Name and department.
• Performance percentage — the main metric, displayed prominently. Colour-coded performance thresholds.
• Trend indicator — an arrow (up or down) with a percentage showing how the employee's performance is trending. Green for positive trend, red for negative.
• Performance bar — a horizontal progress bar filled proportionally to the performance percentage (capped at 100% width). Bar colour matches the performance threshold colour coding (green/amber/red).

Clicking an employee card opens the Employee KPI Modal with the widget's date range pre-set, so the leader can drill into that employee's detailed KPI for the same period.

Pagination

Footer contains rows per page selector (5 or 10), page indicator ("Page X of Y"), and Previous/Next buttons. When searching, the filtered result count is also displayed.

Filter Persistence

All settings — mode (top/bottom), department, date range, and display count — are persisted as part of the widget layout and survive page refreshes.

The Forecast widget will display a line chart comparing actual warehouse performance against forecast targets over a selected time period. It will help managers see whether operations are tracking above or below projections and identify trends early.

Planned Design

The sections below describe the planned functionality based on the current design.

What It Will Show

Two lines plotted on the same chart:

• Actual — real performance data from completed periods.
• Forecast — projected values extending into future periods where actual data is not yet available.

Where both lines overlap (past periods), managers will be able to see how closely actual performance matched the forecast. Where only the forecast line continues (future periods), it will show projected targets.

Header

The header will show a dynamic title based on the selected unit type (e.g. "Lines Forecast" or "Replenishments Forecast") and the description "Actual vs Forecast comparison". A Filters button will open a popover with filter controls.

Filters

The Filters popover will contain:

• Unit Type — a dropdown to switch the metric being charted (e.g. Lines, Replenishments). Changing the unit type will immediately update the chart data.
• Date Range — a date range picker with a two-month calendar view. Selecting a range will filter the chart to show only data within that period.

Chart Interaction

Hovering over any data point on the chart will show a tooltip with the exact month and values for both lines. The Y-axis will adjust dynamically to fit the visible data range.

Trend Indicator

Below the chart, a footer will display a trend summary — showing the percentage change and direction (up or down arrow) across the selected period.

Custom Colours

The Forecast widget will support custom colour controls. In edit mode, colours for the Actual line and Forecast line will be customisable independently. These colour choices will be saved as part of the widget layout.

Filter Persistence

All filter selections — unit type and date range — will be persisted as part of the widget layout, surviving page refreshes.

Managed in Settings → Metrics management. This is where administrators define custom metrics that appear on the Summary widget and in Daily Breakdown views.

What is a Metric

A metric is a custom numeric value imported daily from the WMS database. It represents any measurable quantity relevant to a department — for example "Cartons Packed (AM shift)", "Orders Outstanding", "Pallets Received", etc. Each metric belongs to a specific department and is imported automatically by executing a SQL query against the WMS database at a scheduled time each day.

Metric Properties

Creating, Editing & Deleting

Creating: Click "Add metric", fill in the fields. The metric code is validated for uniqueness within the department. The category must be either "processed" or "outstanding". If both WMS SQL and Schedule Time are provided, the system will begin importing automatically from the next scheduled cycle. The new metric immediately becomes available in the Summary widget when viewing that department.

Editing: All fields changeable except Department and Code (locked after creation to preserve data integrity). Changes take effect immediately.

Deleting: Only possible if no historical data exists. If the metric has data, deletion is blocked — disable it instead by toggling Active to off.

Reordering Metrics

Metrics can be reordered within a department by changing their display order. This controls the sequence in which metrics appear in the Summary widget dropdown and in Daily Breakdown sections.

How Metric Import Works

The system runs a background sync cycle every 5 minutes. During each cycle, it checks which metrics are due for import based on their scheduled time:

How Metrics Appear on Dashboards

Summary Widget

When a specific department is selected, the second chart tab becomes a dropdown listing all active "processed" metrics for that department (using their Short Name). The user selects which metric to chart — the bar chart shows the daily imported values over the selected date range. When "All Departments" is selected, this tab shows Average Idle Time instead (a built-in metric, not user-defined).

Daily Breakdown

When you click on a day bar in the Summary widget, the Daily Breakdown opens. For a specific department, the Activity tab shows two sections: Processed metrics and Outstanding metrics. Each metric displays its current daily value, a trend indicator (comparing the average of the first half of the history window against the second half), and a history bar chart.

Managed in Settings → Activity management. This is where administrators define the activities (functions) that the system uses to recognise what employees are doing on the warehouse floor. Activities are the foundation of the Gap Verification widget — they determine how WMS transactions are mapped to colour-coded segments on employee timelines.

What is an Activity

An activity represents a type of work performed in the warehouse — for example "Case Picking", "QC Packing", "Replenishment", "Break", "Training". The system uses each activity's filter criteria to match WMS transactions to the correct segment on an employee's timeline. When transactions don't match any defined activity, they appear as gaps (or "unmatched" segments) that need manual verification.

Activity Types

The activity type cannot be changed after creation.

Activity Properties

The activity edit dialog has three tabs:

Basic Info

• Active — toggle to enable or disable. Inactive activities are excluded from timeline matching and don't appear in gap resolution dropdowns, but existing resolved segments using them are preserved.
• Code — unique identifier, auto-uppercased (e.g., PICK). Max 10 characters. Locked after creation.
• Name — descriptive name (e.g., "Case Picking"). Max 100 characters. Must be unique across all activities.
• Description — optional free-text description of the activity.
• Activity Type — Direct, Indirect, or Other. Locked after creation.
• Default Colour — the colour used to display this activity's segments on timelines and charts. Chosen via colour picker or hex input.

KPI Settings (Direct only)

• Enable KPI Tracking — toggle. When enabled, the system calculates performance metrics for this activity.
• KPI Data Source — selects which WMS source table to query for transaction data. The dropdown lists all configured KPI source tables with their names and table identifiers.
• Filter SQL — a SQL WHERE clause that filters transactions from the source table to identify this activity (e.g., transaction_type IN ('PICK', 'PIKC') AND status = 'COMPLETED'). The system validates the SQL syntax on save. When the filter is created or changed, the system immediately remaps all activity matches — this may take a moment as it reprocesses historical data.
• Standard Per Minute — the target number of units an employee should process per minute. Used to calculate performance percentage (actual vs standard).
• Measure Unit — unit of measurement for KPI (options: units, cases, pallets, packages, lines, locations, orders, items).

Behaviour

• Priority (1–100) — lower number = higher priority. When a transaction could match multiple activities, the one with the highest priority (lowest number) wins.
• Display Order — controls the sequence in which activities appear in dropdowns and lists.
• Idle Target — the maximum acceptable idle time (minutes:seconds) between transactions for this activity before it's flagged as an inactivity gap. Used in the Gap Verification and Inactivities widgets.
• Default Duration — the default assignment duration (minutes:seconds) when this activity is manually assigned to a gap during verification.

Creating an Activity

Click "Add New Activity" in Activity management. Fill in the tabs and save. On save: code and name are validated for uniqueness. For direct activities with KPI enabled, the Filter SQL is validated against the selected source table. If the activity is direct and has a filter, the system immediately runs activity matching to map existing transactions.

Editing an Activity

Click on an activity to open the edit dialog. All fields can be changed except Code and Activity Type. If the Filter SQL or KPI Data Source is changed, the system re-runs activity matching on save, which may take longer as it reprocesses historical data.

Deleting an Activity

An activity can only be deleted if it is not currently assigned to any timeline segments (resolutions). If the activity is in use, deletion is blocked and the user is informed. Bulk deletion is supported — select multiple activities and delete them at once. The system checks each one individually; those in use are skipped.

If you want to stop using an activity that's in use, deactivate it instead by toggling Active off. This prevents it from matching new transactions while preserving existing data.

How Activities Connect to Gap Verification

Activities are the core of the Gap Verification workflow:

Managed in Settings → User permissions. This page controls which users (and roles) have access to which parts of the application.

How Permissions Work

A permission is a named access right tied to one or more API paths (e.g., kpi.read, kpi.write, users.manage). Each permission has a description explaining what it grants and whether it is a default permission (granted automatically to all users). The full list of available permissions is defined in the system and cannot be modified by users — administrators can only assign or revoke them.

Permission Sources

• Direct permissions — permissions assigned specifically to the user.
• Role permissions — permissions inherited from roles assigned to the user. If a user has the role "Leader" and that role includes kpi.write, the user inherits that permission.

The final set of permissions for any user is the union of their direct permissions and all permissions from their assigned roles.

Users / Roles Mode Toggle

At the top of the page there is a toggle to switch between two modes:

• Users mode — manage permissions for individual users. A tags input field is displayed — start typing a username to see suggestions from all active system users (fetched from the external WMS authentication system). Select one or more users; their names appear as tags. Only valid usernames (those that exist in the system) are accepted. Checkboxes are green when checked.
• Roles mode — manage permissions for roles. A similar tags input shows available roles (by display name). Select one or more roles to view and modify their permissions. Changes to role permissions affect all users who hold that role. Checkboxes are blue when checked.

Permission Table

Once at least one user (or role) is selected, a permission matrix table appears:

• Rows — one row per available permission. Each row shows a checkbox (for bulk operations), the permission description, and a "(default)" label if it is a default permission.
• Columns — one column per selected user (or role). In Users mode, column headers are usernames. In Roles mode, column headers are role display names.
• Cells — each cell contains a checkbox. A checked checkbox means the user (or role) has that permission.

Toggling a checkbox immediately updates the permission state locally. Changes are batched and saved to the server. The first two columns (checkbox and permission name) are sticky — they remain visible when scrolling horizontally through many users/roles. Rows have alternating background colours for readability, and a hover highlight.

Permission Filter

Above the table, a filter input allows searching permissions by description. This narrows the visible rows to only those matching the search term.

Bulk Operations

Each permission row has a row checkbox on the left. Clicking it opens a confirmation dialog that allows adding or removing that permission for all currently selected users (or roles) at once. The dialog shows the selected permission name and the list of affected users/roles, with two radio options: Add (grant the permission to all selected) or Remove (revoke it from all selected). This is useful when onboarding a group of users who all need the same set of permissions, or when revoking access across multiple accounts.

Empty States

If no users or roles are selected, the table area shows a message prompting the user to make a selection.

Managed in Settings → Role management. A role is a named group of permissions that can be assigned to users. Instead of granting 15 individual permissions to each new leader, you create a "Leader" role with those permissions and assign the role. If the required permissions change later, you update the role once and all users with that role are automatically affected.

Role Properties

Creating a Role

Define the display name, description, default status, and optionally assign department access. On save, the internal name is generated automatically.

Editing a Role

All fields can be changed except the internal name. Updating department access immediately affects which department data users with this role can view.

Deleting a Role

Deleting a role removes it from all users who currently have it assigned. Their permissions that came from that role are revoked (unless they also hold those permissions directly or through another role).

Role Permissions

Each role has a set of permissions assigned to it. These are managed through the Roles mode on the User Permissions page — select a role in the tags input, and the permission matrix shows which permissions that role currently grants. Toggle checkboxes to add or remove permissions from the role.

Assigning Roles to Users

Users can have multiple roles assigned simultaneously. The combined (union) of all role permissions plus the user's direct permissions form their effective permission set.

How Permissions Protect the Application

The ScaleX backend uses a middleware that intercepts every API request. For each API path, a required permission is defined. The middleware:

This means permissions are enforced at the API level — even if a user somehow navigates to a UI page they shouldn't see, the data requests will be blocked.

Separate from pages, each user has global preferences that apply across all widgets and pages:

• Activity colours — custom colour overrides for activity types, applied across all widgets and pages.
• Theme — light, dark, or system (follows OS setting). Persists across sessions.

Performance Thresholds

Performance percentages are colour-coded throughout the application to give an instant visual indication of how employees or departments are performing. The default thresholds are:

These thresholds are configurable and apply consistently across all views: Summary widget KPI cards, Daily Breakdown Performance tab, Employee KPI Modal, Top/Bottom Performers widget, and By Department view.

Persistence

Layouts are saved to the server and cached locally. Saving is optimistic — the local cache updates instantly, server sync happens in the background. If the server is unreachable, the app works with cached data.