Allocation & Equivalences

What the Allocation engine does

The Allocation engine decides which real machine in your Inventory should fulfil a dedicated-server order. When a paid order needs a physical machine, the engine scores every available server against the product's specifications, picks the best match, reserves it, and works out an estimated delivery time. Everything on this page is configuration: the matching modules that run, the equivalence tables that let near-matches count as matches, the delivery rules that add lead time when extra work is needed, and the global delivery configuration.

How to open it

Open Products from the sidebar, then click the Allocation tab in the row of tabs at the top of the page. (This tab only appears when the inventory feature is enabled for your panel.) Inside Allocation you will find seven sub-tabs:

• Modules — the checks that run during matching.
• Storage Equivalences — disk-size mappings.
• CPU Equivalences — processor-name mappings.
• RAM Equivalences — memory-size mappings.
• Delivery Rules — adjustments to the delivery estimate.
• Configuration — base delivery time and business hours.
• History — a log of past allocation decisions.

How matching works

When an order requiring a machine is processed, the engine reads the product's hardware specification (CPU, RAM, storage, network) and runs every enabled module against each candidate server in priority order. Each module returns one of three results:

Compatible

The server fully satisfies that check.

Partial

The server can satisfy the requirement, but only after extra work (for example installing a NIC or adding storage). It stays in the running and may trigger a delivery rule that adds lead time.

Incompatible

The server fails the check.

A module marked Required removes any candidate it rates Incompatible. A module marked Optional keeps the candidate even on a partial result, so you can compensate with lead time instead of rejecting the machine. The first surviving server is reserved for the order, and its delivery estimate is built from the base time plus any delivery-rule effects.

Modules tab

The Modules sub-tab lists every matching module in a sortable table. Columns: Module (its name and identifier), Category (Hardware, Storage, Network, or Custom), Priority (lower numbers run first), Required (Required or Optional), and Status (Enabled or Disabled). Modules cover the main dimensions of a server match — location, CPU, RAM, storage, and network/NIC. A Refresh button at the top of this sub-tab reloads the list.

Configuring a module

Click Configure on a module row to open its settings dialog. Every module shares three basic settings:

Setting	What it does
Enabled	Turns the module on or off. A disabled module is skipped entirely during matching.
Required	When on, any server the module rates incompatible is removed from the pool. When off, the module is advisory and can only influence delivery time.
Priority	Determines the order modules run in. Lower numbers run earlier.

Some modules add their own options below the basic settings:

Module	Extra options
CPU compatibility	Strict mode — require an exact processor match instead of allowing equivalences.
RAM compatibility	Allow upgrade — let a server with less memory qualify if RAM can be added; Upgrade penalty days — lead time added when an upgrade is needed.
Storage availability	Upgrade penalty days — lead time when disks must be added; Check storage type — also compare media type (HDD/SSD/NVMe), not just capacity.
Network / NIC	NIC penalty days — lead time when a network card must be installed; Check port speed — also compare link speed, not just port count.

Click Save in the dialog to apply your changes.

Keep checks you can never relax (such as CPU and RAM) set to Required, and set checks you can satisfy with a little extra work (storage, network) to Optional with a delivery penalty. That way a near-perfect machine is still offered, just with a longer ETA, instead of being rejected outright.

Storage Equivalences tab

Marketing capacities rarely match what a drive actually reports — a "500 GB" disk often formats to 480 GB. Storage equivalences let those count as a match. Click Add Equivalence to open the dialog:

Field	What it does
Actual Size (GB)	The capacity the machine actually has.
Equivalent Size (GB)	The advertised capacity it should be treated as.
Storage Type	Any type, HDD, SSD, or NVMe. "Any type" applies the mapping across all media.
Description	Optional note to explain the mapping.
Active	Whether the mapping is in use. Inactive rows are ignored during matching.

The table lists each mapping with Actual Size, Equivalent Size, Type, Description, and Status. Each row has buttons to edit (pencil), toggle active, and delete (trash). A confirmation prompt appears before a row is deleted.

CPU Equivalences tab

The same processor is often written differently on a product page versus an inventory record ("Dual E5-2630v3" versus "2x Intel Xeon E5-2630 v3"). CPU equivalences map one naming style to another so the difference doesn't block a match. Click Add Equivalence:

Field	What it does
Pattern	The CPU text as written on the product.
Equivalent	The CPU text as written on the server in inventory.
Description	Optional note.
Active	Whether the mapping is applied.

Rows show Pattern, Equivalent, Description, and Status, each with edit, toggle, and delete actions.

RAM Equivalences tab

A machine usually reports slightly less memory than its rated size after firmware reservations — a 128 GB host may report 124928 MB. RAM equivalences map the reported value to the plan value so the RAM check still passes. Click Add Equivalence and enter:

Field	What it does
Reported (MB)	The memory figure the machine reports (in megabytes).
Equivalent plan (MB)	The plan capacity it should be treated as (for example 131072 for 128 GB).
RAM Type	A dropdown: Any type, DDR3, DDR4, or DDR5. Leave it on "Any type" to apply the mapping regardless of memory generation.
Description	Optional note.
Active	Whether the mapping is applied.

This table starts empty. Add a row the first time a host reports an unexpected memory figure that would otherwise fail the RAM check.

Add your equivalences before bulk-importing a batch of unfamiliar machines. Without a matching row, a legitimate server can be rated incompatible purely because its reported numbers or naming don't literally equal the product spec.

Delivery Rules tab

Delivery rules adjust the estimated delivery time based on how a module rated a server — typically to add lead time when a partial match means extra work. Click Add Rule to open the editor:

Field	What it does
Name	A label for the rule (required).
Description	Optional internal note.
Module	Which module's result triggers the rule. Pick from your enabled modules (required).
Status	The result that fires the rule: Compatible, Partial, or Incompatible.
Effect Type	Add, Set, or Multiply the delivery time.
Effect Value	The number applied by the effect.
Effect Unit	Minutes, Hours, or Days.
Customer Message	Optional text explaining the delay, shown to the customer.
Priority	Order in which rules are evaluated (lower first).
Active	Whether the rule is in effect.

A live preview in the editor reads the rule back in plain language (for example, +3 days when storage-availability is partial) so you can confirm it before saving. The rules table shows each rule's name, condition, effect, priority, and status, with edit and delete actions.

Configuration tab

The Configuration sub-tab ("Delivery Configuration") holds the global timing settings that apply to every allocation:

Setting	What it does
Base Delivery Time (minutes)	The default estimate used when every spec matches exactly, before any delivery-rule effects.
Skip Weekends	Excludes Saturday and Sunday from delivery-time calculations.
Working Hours Only	Counts only business hours. Turning this on reveals Start Time and End Time fields.
Timezone	The reference timezone for weekend and working-hour rules: UTC, America/New_York (EST), America/Los_Angeles (PST), Europe/London (GMT), Europe/Amsterdam (CET), or Asia/Tokyo (JST).

Click Save Configuration to apply.

History tab

The History sub-tab is an audit trail of past allocation decisions. The table lists Date, Order, Product, Server, Status, and the calculated Delivery time, and is paginated with Previous and Next buttons once there is more than one page. Click View on a row to open a detail panel showing the order and product, the chosen server, the estimated delivery, a compatibility score, each module's result, the breakdown that produced the delivery estimate, and the requested versus matched specifications — useful for understanding why a particular machine was (or wasn't) picked.

Putting it together: a sample order

1. A customer orders a dedicated server (for example a Xeon E5-2630 v3 with 128 GB and 2 × 240 GB SSD) in a chosen location.
2. The location check narrows the pool to machines in that location.
3. The CPU check normalises the product's processor text through your CPU equivalences and matches a host whose name is written differently.
4. The RAM check sees the host reporting 124928 MB, finds your RAM equivalence to 131072 MB (128 GB), and rates it compatible.
5. The storage check sees the reported drive size, applies your storage equivalence, and rates it compatible — no penalty.
6. The network check confirms the required bandwidth — compatible.
7. The engine reserves the host and the order moves to provisioning with the base delivery time as its ETA.

Related

Products, Inventory, Orders.