Documentation

Follow these steps in order to get your shop running. Each step builds on the previous one:

App Launcher is your home screen — it shows the shop's hero icons and quick-access tiles. Production Setup is where you define lines, processes, and workflows. Work Ordersis where you create and manage jobs. Kiosk is the operator-facing interface. FlowBoard is the real-time pipeline view for leads and managers. Settings controls all configuration.

Once your shop is configured, the day-to-day flow is: create or import work orders → schedule them to lines → operators scan in at the kiosk → units advance through the workflow → QC gates pause for inspection → completed units write back to inventory and analytics. The FlowBoard shows you the live pipeline; the Daily Report and Analytics pages show you what happened.

A sales order splits into work orders when the job needs different products or separate routings. Each work order gets its own part number, workflow, line, and due date. One sales order can drive one or many work orders — the split is a scheduling and tracking decision.

The quantity field determines how many physical units the order produces. A qty of 1 is a single card on the floor; a qty of 10 expands into 10 independent units, each tracked through the workflow step by step via unit_states. Operators can run multiple units in parallel; the kiosk times each unit's process separately so per-unit cycle data stays clean.

When a workflow defines sub_assembly_workflow_id, creating a work order auto-creates a linked sub-assembly work order. The sub_assembly_quantity_multipliercontrols how many sub-units each parent unit needs — a 10-unit parent with a 2× multiplier spawns a 20-unit sub-assembly. Completing the sub-assembly feeds back into the parent's progress.

Every work order moves through these statuses:

Soft-deleted orders get status='deleted'and a deleted_at timestamp; they're permanently removed after 30 days.

Create work orders individually from the Work Orders page using the "New Work Order" form, or import them in bulk from CSV, PDF, or connected external systems. Each work order requires at minimum an order number, part number, and quantity. The workflow, line (department), due date, and priority are assigned during creation or later.

Every work order moves through these statuses:

pending orders exist but aren't scheduled to a line yet.scheduled orders have a line and date assigned.in_progress means a unit is actively being worked.paused halts work with a reason. QC gates createawaiting_qc and qc_failedstates. completed closes the order. Soft-deleted orders get status='deleted' and are permanently removed after 30 days.

The Work Orders page supports full-text search across order numbers and part numbers, plus filters for status, priority, department, workflow, customer, and date range. Filter combinations can be saved for quick access. Pinned work orders stay at the top of the list for priority visibility.

Click any work order to open the detail dialog. From there you can edit fields, view time logs, manage attachments, create sub-assemblies, adjust unit states, reassign employees, change the workflow, and view the revision history. Available actions depend on the work order's status and your role.

When a workflow defines sub_assembly_workflow_id, creating a work order auto-creates a linked sub-assembly work order. The multiplier controls how many sub-units each parent unit needs — a 10-unit parent with a 2× multiplier spawns a 20-unit sub-assembly. Completing the sub-assembly feeds back into the parent's progress.

A Sales Order groups work orders under a customer request. It tracks the customer, PO number, due date, and line items. Creating work orders from a sales order pre-fills the customer and can auto-assign workflows based on the product. Sales order status updates automatically as linked work orders progress.

Customer records store contact information, shipping address, and account details. Customers can be assigned priority levels that influence scheduling and auto-priority rules. The customer priority sync ensures high-priority customers' orders are scheduled first when capacity is constrained.

Supplier records track vendors and their contact information. Purchase Orders are created to replenish inventory — each PO line item references an inventory item, quantity, and unit cost. When a PO is received, the inventory item's stock increases and a receive-type StockTransaction is written.

The Customer Portal lets customers track their orders in real time. A 6-characterportal_code identifies the shop. Portal visibility is controlled by customer_portal_settings — toggle status, progress, employee name, timeline, due date, attachments, and notes independently.

Each step in a workflow references a process by process_id, has anorder, and can be marked optional. Steps can definebranches — conditional routes out of the step. A branch has acondition_type of operator_choice(operator picks at the kiosk) or qc_result (auto-routed based on QC pass/fail/needs_rework). The next_process_id on each branch determines where the unit goes; __COMPLETE__ means the order completes.

designated_time_minutes on the workflow is the total expected time per unit. Combined with the daily headcount, it computes the expected per-person time. The kiosk times every step for real; when actual time exceeds 1.5× the designated time, that step is flagged an outlier in analytics. The workflow-level designated time supersedes individual process times for analytics flagging.

When is_inline_flow is true, the kiosk keeps the card open and advances the part through each step sequentially, timing each process and the full workflow — like a time study run. Best for single-operator continuous flows.

required_materials is an accumulated list of materials needed across all steps. Each entry has an item_sku,quantity_per_unit, and the process step it's used in. On work order completion, the consume automation deducts stock from matching inventory items.

produces_inventory configures what finished good the workflow adds back to stock on completion. When enabled, completing a work order adds quantity_per_unit × wo.quantity to the target inventory item.

An operator scans in or taps a work order card. The first unit transitions fromscheduled to in_progress, a work time-log opens with started_at, and thecurrent_process_id is set to the workflow's first step.

When the operator completes a normal process, the time-log closes (ended_at,duration_minutes), the unit advances to the next step, and a new time-log opens. If the step requires QC, the unit moves to awaiting_qcand waits for an inspector. If the step has branches, the operator picks a branch (or it's auto-routed by QC result).

An inspector passes or fails the QC. Pass → unit advances to the next step (or the operator-chosen branch destination saved in pending_branch_next_process_id). Fail → unit goes back for rework; a rework time-log is added, rework_countincrements, and needs_rework is set with instructions.

For multi-quantity orders, each unit runs the workflow loop independently. The kiosk tracks per-unit state inunit_states — status, current process, assigned employee, start/complete timestamps, and rework flags. Operators can run multiple units in parallel at the same station.

The kiosk polls for barcode scans (when kiosk_barcode_polling_enabled). A scan can match an existing work order by order number or part number. Free-form scan recognition extracts aunitToken from the scanned string to map concurrent multi-unit work orders to specific unit slots.

Operators can pause a unit with a reason (from settings.pause_reasons). A pause time-log is created with type='pause'. Help requests notify leads/managers based on help_request_settings.notify_mode.

Cards display detected key dimensions (width, height, handing, etc.) based on the Dimension Type registry and per-line flowboard_card_config overrides. Each line can control which dimensions to show, how many, and starting index — independent of shop-wide settings.

When an operator signals a step is done, ready_to_move_at is set on the unit. A card with ready set and the next step empty means the next station is the bottleneck. The board clears ready_to_move_atautomatically when the unit shifts to the next step.

A line's flowboard_card_config.remaining_override lets managers manually set the "Units remaining" KPI. The board counts down from this number as units complete, subtracting completions since remaining_override_set_at.

The flowBoardShift module handles moving units between steps.applyShiftsToWO processes shift operations — advancing units, applying branch routing, and clearing ready-to-move flags. Shifts can be triggered by kiosk completion, FlowBoard drag, or scan-advance behavior.

When a work order completes, the consumeMaterialsOnComplete backend function runs. For each required_materials entry on the workflow, it finds the inventory item by SKU and subtractsqty_per_unit × wo.quantity × (1 + scrap_factor), floored at zero. A consume StockTransaction is written with the reason, triggering WO, and running balance.

If produces_inventory.enabled is set on the workflow, theproduceInventoryOnComplete function addsquantity_per_unit × wo.quantity to the target inventory item and writes a receive StockTransaction.

Every movement is logged as a StockTransaction with type (consume, receive, adjust, transfer), quantity (signed),reason, work_order_id, and balance_after. This is the audit trail for every stock change.

Each InventoryItem has min_quantity andmax_quantity. The monitorInventoryLevelsworkflow checks levels on a schedule and fires alerts when stock drops below the minimum. Restock requests can be created automatically via createQuickRestockRequest.

StockCodePattern entries map scanned/entered codes to inventory items and workflows. When a work order's part number matches a pattern, the workflow (and its first process + starting department) is auto-assigned. Patterns support plain (keyword tokens), string (literal substring), and regex matching.

DimensionType entries define how key dimensions are detected from work order fields. Built-in types (door_size, jamb_width, panel_count, etc.) use hard-coded extractors. Custom types usedetection_regex (regex mode) or pipe-separated literal strings (simple mode). Detected dimensions appear on kiosk cards and FlowBoard cards.

Designations (qc_inspector, maintenance,purchaser, trainee) layer targeted abilities on top of the role — e.g. an operator with qc_inspectorcan perform QC inspections even though operators normally can't.

The shop's role_permissions matrix maps each role to feature toggles (can_access_kiosk,can_manage_work_orders, etc.). Sidebar nav items carry role lists; pages check permissions before rendering sensitive actions. Admins customize this in Settings → Access.

Certification records define certifiable skills. EmployeeCertification links employees to certifications with issue/expiry dates. TrainingGuide and TrainingRecord track training progress. The Training Matrix shows a cross-tab of employees vs. certifications with status indicators.

ai_scheduler_config controls optimization weights:priority_weight, due_date_weight,workload_balance_weight, employee_preference_weight. It also has toggles for prioritizing pinned/urgent/due-date orders, respecting certifications and shifts, allowing overtime, and max hours per day.

auto_priority_rules let admins define rules that automatically set work order priority based on conditions (customer, part number, due date proximity, etc.). Rules are evaluated when auto_priority_enabled is true.

due_date_settings controls which days are allowed for due dates (allowed_days), holidays (excluded), and the default number of business days to add. The system skips holidays and non-allowed days when computing due dates.

When auto_scheduling_config.enabled is true, theautoScheduleWorkOrders workflow runs on a schedule and assigns work orders to lines days_before_due_date days before their due date.

Cycle time = sum of every work + rework time-log for a unit, from start to completion. Actual hours = cycle time ÷ 60, rolled up per employee and per work order. Per-step time comes from each time-log's duration_minutes, compared against the process's designated time to flag outliers (threshold: 1.5× designated). Rework rate = rework count ÷ units completed, tracked per process and per workflow.

outlier_exemptions on a work order lets managers exclude specific time logs or steps from outlier flagging. prod_time_analysis_exclusionsin settings controls shop-wide exclusion patterns. The setProductionTimeFilterfunction applies these filters before analytics queries run.

AnalyticsQuery records store saved searches with a structuredquery_config — metric, groupBy, seriesBy, normalization, filters, dateRange, chartType, vettedOnly, andwoDateBasis. Pinned queries appear on the analytics dashboard and can auto-refresh on an interval.

CustomDashboard records let users compose widget grids from saved analytics queries, KPIs, and charts. The AI Dashboard Builder can generate dashboards from natural language descriptions. Widgets are registered in a widget registry and pull data via the query engine.

QCChecklist records define inspection items for a process. A checklist has a name, a set of check items (each with a pass/fail/na outcome), and can be marked as final QC. When a workflow step requires QC, the matching checklists are attached to the work order as pending_qc_checklists.

QCInspection records capture the actual inspection — the inspector, work order, unit number, process, checklist results, and overall outcome (pass/fail/needs_rework). A pass advances the unit; a fail sends it back for rework with instructions. manager_only_final_qc in settings controls whether only managers can perform final QC.

When QC fails, the unit gets needs_rework=true,rework_instructions, and a rework time-log is added. Therework_count increments. ReworkMaterial records track materials consumed during rework. The autoReserveReworkMaterialsfunction can pre-reserve materials for known rework scenarios.

Expectation items can be plain ticks or tied to a shop measure (units per day, QC pass rate, and so on) with a baseline and target. ImprovementGoal records track auto or hand-entered values, and ImprovementLog keeps the entry history for every progress note, review and milestone.

Plans marked for the daily digest appear on the board until they have been updated that day. Reminder emails run on a schedule and use the improvement plan email templates, so owners get a heads-up before the final date.

JobPacketTemplate records define the work order prefix, material SKU naming pattern, block title, and surfaced sections (source materials, process instructions, SO/PO). Only one template can be the shop-wide default. Templates also carry default reference images per process and per inventory item.

JobPacket records contain materials (BOM with SKU, name, quantity, UOM) and operations (ordered process steps with instructions, default minutes, and reference images). A packet applies when a work order matches ANY of its assignments — dates, customers, lines, sales orders, or explicit work order IDs.

When multiple packets match the same job, the one with the highest prioritynumber wins. A packet marked is_default is the shop-wide fallback for jobs with no specific match. Only one default per shop.

RFIDLocation records map a scanned tag or location code to a rack position. Scanning into the layout assigns or moves stock to that cell, and the RFID activity log keeps a record of each movement.

Where a station has no scan points, the Count Board records manual piece counts against a line, and ManualCounter records hold those tallies for reporting.

The builder lets you design barcodes with live preview, adjust bar width, height, font size, margins, and colors. Bulk print supports multiple copies. Layouts arrange multiple barcodes on a page with custom page dimensions (in inches) and serialized element positions stored in elements_json.

Barcodes drive kiosk and FlowBoard actions. The kiosk polls for scanner input and matches scanned values to work orders by order number or part number. The useBarcodeScannerhook and useCameraBarcode hook handle hardware scanner and camera-based scanning respectively.

Maintenance schedules define intervals (calendar-based or runtime-based) and trigger maintenance work orders when due. The sendPMNotifications workflow runs daily and notifies the right people about upcoming or overdue PMs.

When integration_settings.auto_track_equipment is true, theinferEquipmentFromWorkOrder function automatically links work orders to equipment based on process and department, so machine usage data is captured without manual assignment.

MachineConnection records connect to external machine data sources. MachineReading records capture runtime, cycle counts, and OEE metrics. ThereceiveMachineData andprocessMachineEvent functions handle real-time machine data ingestion.

Each task has a type and a priority tier. The type determines whether it's a "do by" task (complete by a specific time) or a "do now" task (action immediately with an alert). The priority tier sorts tasks into Must Do, Should Do, and Want To Do buckets for daily planning.

The priority_tier field sorts tasks into three daily planning buckets. Must tasks are non-negotiable for today. Should tasks are important but flexible. Want tasks are nice-to-have if time allows. This Eisenhower-style matrix helps managers focus on what matters each day.

Tasks can recur daily, weekly, or monthly. When a recurring task is completed, the next instance is auto-created with the due date shifted by the recurrence interval. This is useful for standing tasks like weekly safety walks, monthly inventory audits, or daily shift-start checklists.

Each task can have a timer. Start the timer to track how long a task takes; pause and resume as needed. Timer data rolls into the task's total duration. The floating timers widget shows all running timers across the app, so managers can track multiple tasks simultaneously.

Managers with manager_can_view_all enabled can see all team members' tasks in the Team View. auto_task_triggerscan auto-create tasks when work orders hit certain states, andauto_complete_triggers can mark tasks done when linked entities change.

A TimeStudy record defines a structured study — the area, shift, workflow, and ordered process steps. Each step has a step type (touch, decision, wait, transport, inspection), a target time in seconds, and an optional pinned employee. The kiosk runs the study as a live work order, timing each step and the full flow with second-level precision.

When actual step time exceeds 1.5× the designated time, that step is flagged as an outlier. TheOutlierFlag component shows outliers visually on the study results. Outliers can be exempted individually viaoutlier_exemptions on the work order, or shop-wide viaprod_time_analysis_exclusions in settings.

A KaizenEvent structures an improvement event — problem statement, target state, scope, team, and goal metric. The event generates baseline work orders to measure current performance, then improvement work orders after changes are applied. Before/after comparison quantifies the improvement.

WasteObservation records capture the 8 wastes: Transport, Inventory, Motion, Waiting, Overproduction, Overprocessing, Defects, and unused Skills. Each observation links to a process step, describes what was seen, estimates impact in seconds, and tracks status from identified → action → verified. Photos can be attached for documentation.

The MapLayout and SpaghettiPath entities support visual floor mapping. Draw the shop layout, plot operator movement paths, and identify unnecessary motion waste. The layout analyzer can suggest improvements based on path density and crossing patterns.

The Daily Report shows all work order activity for a selected date — units started, completed, paused, and their time logs. Each work order's log is searchable and collapsible. Duration formatting is precise to the second. The report includes per-employee time breakdowns and per-work-order summaries.

The End of Shift Report provides a concise summary of a single shift — units completed, active work orders, downtime, and rework events. It's designed for handoff communication between shifts. Like the Daily Report, it's exportable to PDF.

Before a day's data enters analytics, it must be vetted. The DailyVetting panel shows each production day with detected shift start/end, present employees, and actual billed hours. Admins review the data, adjust as needed, and mark the dayvetted=true. Only vetted days are included in analytics queries — this prevents noisy or incomplete data from skewing trends.

The Analytics page provides a query builder for custom metrics, saved searches, and pinned dashboard cards. Prebuilt charts cover cycle time by workflow, rework rate trends, delivery performance, and department productivity. The AI Dashboard Builder can generate dashboards from natural language descriptions. Custom dashboards compose widget grids from saved queries and KPIs.

The Mobile Station is a lightweight, touch-first interface for operators on the floor. It shows the operator's assigned line, key stats (done today, due today, time on line, efficiency), and a scan field for barcode-driven actions. Help requests can notify a designated email when an operator needs assistance.

Configure which stats appear on the mobile station viamobile_station_settings.enabled_stats. Options include done_today, due_today, time_on_line, and efficiency. Sethelp_notify_email to route help requests to a specific person.

The Customer Portal is a public page where customers track their orders in real time. They enter the shop's portal_code and their order number to see live status, progress percentage, production timeline, and estimated completion. Portal visibility is controlled per shop — toggle status, progress, employee name, timeline, due date, attachments, and notes.

Shop name, description, logo, timezone, date format, currency, work-week start, default shift hours, and the customer portal code. Also allow_duplicate_work_orders andauto_release_enabled.

Departments, processes, workflows, routing templates, and the Workflow Strategizer. Also the Kiosk Card Designer (operator field layout, dimensions, display toggles) and Dimension Type management.

Shifts, global breaks, due-date settings (allowed days, holidays, default days), AI scheduler config (weights, auto-priority rules), and auto-scheduling config (enabled, days before due date).

Kiosk card config (operator fields, timer, time progress, next step, training guide, rework banner, notes, job packet, detected dimensions, build image), barcode polling, step notification duration, admin/manager visibility in operator selector, and pause reasons.

Role-permission matrix — toggle nav visibility per role and flip feature permissions. Also CI kiosk access control and help request settings (notify mode, specific users, work order context visibility).

Notification settings — email enabled, Slack webhook, alert on downtime, alert on rework. Also the mobile station settings (enabled stats, help notify email).

External integrations (Google Calendar, Sheets, Gmail, Epicor, WMS scraper, email order connector), data importers (CSV, PDF, historical), and integration settings (auto-create inventory, auto-track equipment, AI inference toggles).

AI shop setup, data retention settings, App Launcher customization (hero icons, hidden features), sidebar customization, and the danger zone (delete all shop data).

Workflows are trigger-driven automations stored as .jsonc files. Triggers: scheduled (cron/interval), entity (create/update/delete), connector (webhook), and app events (auth, publish, payment). Activities: invoke_backend_function andcompute_seconds_until. Steps chain viacall, wait, andswitch.

customer_portal_settings controls what customers see in the portal: status, progress, employee, timeline, due date, attachments, and notes. The portal uses a 6-characterportal_code to identify the shop.

The Owner Portal gives shop owners a single overview across every shop they own or belong to, with the same role rules that apply inside a shop. Users switch shops from the Shop Selector.

The Reconciler compares orders pulled from an external system (WMS, Epicor, a scraped report) against open work orders, so quantities, due dates and statuses are corrected instead of duplicated. ThereconcileOpenWorkOrders function performs the comparison and marks anything it closes out as not scanned.