Order Management Modal

Order Management Modal – Complete, End-to-End Description

The Order Management Modal is a guided configuration workflow used to define how orders behave across the entire system. It is not a scheduling screen and not a reporting screen. Instead, it is the foundation layer that prepares order types, their data structure, their statuses, and how they appear later in weekly scheduling, dashboards, and top-header filters.

This modal always opens as a step-by-step wizard (1/4 → 4/4) so the user configures orders in the correct logical sequence.

What This Modal Is Responsible For

At a high level, this modal answers four critical questions:

What order types exist?
What data can each order store?
What statuses and colors describe an order’s lifecycle?
Which fields should users actually see on the order dashboard?

Only after these questions are answered can orders be safely used in scheduling and daily operations.

Modal Header – Orientation & Control

When the modal opens, the header immediately communicates context and safety:

The title “Order” confirms you are configuring order definitions.
The progress indicator “1/4” clearly shows that this is a multi-step process.
The subtitle “Next: Order custom fields” tells the user what comes next, reducing confusion.
A Close (×) button allows exiting the modal at any time.
An information (i) icon provides contextual help for users who need guidance.

This header remains consistent across all four steps so the user always knows where they are in the workflow.

Step 1 of 4 – Order (Defining Order Types)

Purpose of Step 1

Step 1 is where order types are created and maintained.

An order type is a template, not a booking. Every order you later schedule, filter, or display is based on one of these definitions.

Examples of order types might include internal names like test, swiggy, zomato, lapin oz, or any business-specific label.

Global Visibility Control

At the top of Step 1 there is a toggle:

“Show in top header order list”

This switch controls whether the order types defined here should be visible in the top header of the application as quick-access filters or tabs.

When enabled, these order names appear throughout the UI and can be quickly selected.
When disabled, the orders still exist but remain hidden from high-level navigation.

This allows administrators to keep internal or experimental order types out of everyday workflows.

Adding New Orders

A prominent blue “+” button allows users to add new order types.

When clicked, it opens an entry form where the user defines:

The order name (what users will see)
The default price
The minimum number of days allowed for that order

This ensures every order type has consistent rules before it is used.

Order List Table (Core of Step 1)

The main body of Step 1 is a scrollable table listing all existing order types.

Each row represents one order definition.

For each order, the system displays:

A unique ID used internally
The Name used across the UI
The Price associated with that order
The Minimum days rule
Actions to edit or delete the order

Editing allows updating the name or rules. Deleting removes the order type entirely (usually after confirmation), ensuring outdated or unused orders do not clutter the system.

This table is scrollable, allowing large organizations to manage many order types without overwhelming the screen.

Navigation from Step 1

Once the order list is correct, the user clicks Next.
This does not create bookings—it simply moves the workflow forward to define what data orders can hold.

Step 2 of 4 – Order Custom Fields (Defining Order Data)

Purpose of Step 2

This step defines what information an order can store beyond basic name and price.

Examples:

Delivery time
Quantity
Extra notes
Tags
Calculated totals
Automation triggers

Without this step, orders would be flat and inflexible.

Custom Field Creation

Users can add custom fields using “Add order custom fields”.

Each field can be configured with:

A field type (text, number, yes/no, select, date, hour, tags, numeric groups, title blocks, buttons, automation triggers, calculations)
Labels in English and Hebrew
Optional price and cost price
Options for select-type fields (with color and pricing per option)
Validation rules like minimum, maximum, step values
Defaults for yes/no or numeric fields

Custom Fields Table

All defined fields appear in a table showing:

Field names
Field types
Actions to edit or remove

This table gives administrators a complete overview of the order data model.

Navigation from Step 2

Back returns to Step 1 if order definitions need adjustment.
Next moves forward to define how orders are visually and logically tracked using statuses.

Step 3 of 4 – Order Status (Lifecycle & Colors)

Purpose of Step 3

This step defines the lifecycle of an order.

Statuses describe what state an order is in, such as:

New
In progress
Completed
Cancelled
Pending approval

Each status also has a color, which is used in scheduling views and dashboards.

Order Status Title

At the top, the user can customize the Order Status title itself.
This controls how the status label appears across the UI and allows wording to match business terminology.

Adding and Managing Statuses

Users can add statuses by defining:

The status name
The status color

Each status appears in a table where it can be edited or deleted.

Colors chosen here are reflected later in calendar cards and order lists, making visual scanning fast and intuitive.

Navigation from Step 3

Back returns to custom fields.
Next proceeds to the final step: deciding what fields users actually see.

Step 4 of 4 – Field List (Dashboard Visibility)

Purpose of Step 4

Not every field defined in Step 2 needs to be visible all the time.
This step controls which fields appear on the order dashboard and in lists.

Field Selection

Users can:

Add fields to the dashboard display
Arrange their order
Remove unnecessary fields from view

This allows the interface to stay clean and focused on the most important data.

Saving and Finishing

Once fields are selected:

The user clicks Save
The wizard completes
All order configuration is finalized

There is no “Next” after this step—this is the end of the workflow.

How This Modal Connects to Scheduling

Everything configured here directly powers other screens:

Weekly Order Scheduling uses:
- Order names from Step 1
- Status colors from Step 3
Top header filters depend on:
- The visibility toggle in Step 1
Order detail views display:
- Custom fields from Step 2
- Dashboard field selection from Step 4

Without completing this modal, scheduling views would have no structure.

Final Mental Model

Step 1: Define what orders exist
Step 2: Define what data orders store
Step 3: Define how orders progress visually
Step 4: Define what users see day-to-day

One-Line Summary

The Order Management Modal is a four-step configuration wizard that defines order types, their data, their statuses, and their visibility—forming the backbone of all order scheduling and management in the system.

Order Management Modal