What Is the Order Management System? (Overview & Key Concepts)

The ARMOR Order Management System provides a centralized, automated way to request parts, service work, and capital equipment for your assets. Instead of managing vendor communications through scattered emails, phone calls, or paper forms, the system streamlines the entire ordering process—from initial request through vendor notification—while maintaining complete audit trails and optional approval workflows.

This article introduces the core concepts and components of the Order Management System, helping you understand how orders flow from creation through vendor notification, and how automation rules eliminate manual vendor selection.

System Overview

The Order Management System is built around three foundational concepts:

1. Orders - Requests for parts, service, or capital equipment tied to specific assets
2. Vendors - Service providers who fulfill orders, with designated contact emails for each order type
3. Automation Rules - Tag-based logic that automatically routes orders to the appropriate vendor

When you create an order for an asset, the system automatically:

• Matches the asset's tags against configured rules
• Selects the appropriate vendor based on rule priority
• Routes through approval workflow (if required)
• Sends formatted email notification to the vendor with asset details and attachments
• Tracks order status and maintains complete history

Important: The Order Management System handles the request and notification phases only. It does not track vendor fulfillment, shipping, or completion. Once the vendor receives the order notification, any subsequent coordination happens outside the platform.

The Three Order Types

Every order must be classified as one of three types, which determines which vendor contact receives the notification:

Order Type	Purpose	Vendor Contact Used	Typical Examples
Part	Request replacement components, consumables, or spare parts	Parts Contact Email	Hard drive replacement, toner cartridge, brake pads, filters, batteries
Service	Request maintenance, repair, or professional services	Service Contact Email	Equipment inspection, preventive maintenance, repair work, calibration
Capital	Request new equipment or major asset purchases	Capital Contact Email	New server, vehicle, machinery, major equipment upgrade

A single vendor can support one, two, or all three order types by providing the corresponding contact emails. For example, a vehicle maintenance vendor might have service and parts contacts but no capital contact.

How Orders Flow Through the System

Understanding the complete order lifecycle helps you configure the system effectively. Here's how an order progresses from creation through vendor notification:

Step 1: Order Creation

A user creates an order for an asset through the web portal or mobile app, selecting:

• The target asset (required)
• Order type: part, service, or capital (required)
• Part number, notes, and attachments (optional)

The system generates a unique order name using sequential counters (e.g., "PART-001", "SVC-042", "CAP-015").

Step 2: Vendor Resolution

The system automatically determines which vendor should receive the order:

1. Asset Tag Retrieval: System loads the asset's tags (manufacturer, model, location, custom tags)
2. Rule Matching: Evaluates all active rules to find one matching the asset's tags
3. Priority Selection: For the matched rule, finds the highest-priority vendor assignment for the order type
4. Vendor Validation: Confirms the vendor is not disabled and has the appropriate contact email

If no matching rule is found, the order is created but cannot be sent until a vendor is manually assigned.

Step 3: Approval Decision

The system determines if approval is required based on two factors:

• Rule Approval Settings: The matched rule may require approval with designated approvers
• Vendor Approval Settings: The selected vendor may require approval with its own approver list

If either requires approval, the order enters Pending status and waits for an admin to approve or reject it. If no approval is needed, the order proceeds directly to notification.

Step 4: Vendor Notification

Once approved (or if no approval was required), the system:

1. Generates a formatted HTML email containing:
   • Asset details (name, serial number, manufacturer, model, location)
   • Requester information
   • Order-specific data (part number, notes)
   • Asset image and order attachments
2. Sends email to the vendor's appropriate contact (parts, service, or capital)
3. Updates order status:
   • Sent - Email successfully delivered
   • Failed - Email delivery failed (can be resent)

Note: After the vendor receives the notification email, all subsequent fulfillment coordination happens outside the ARMOR platform. The system does not track shipping, delivery, or completion.

Key System Components

Vendors

Vendors represent service providers, suppliers, or contractors who fulfill orders. Each vendor configuration includes:

• Name: Vendor identifier (must be unique within your account)
• Contact Emails: Up to three contacts for parts, service, and capital orders
• Conditions: Tag-based criteria that automatically generate matching rules
• Approval Settings: Whether orders to this vendor require approval and who must approve
• Status: Active or disabled (disabled vendors are skipped during vendor resolution)

Vendors can be configured with conditions—tag combinations that define which assets they service. When you create a vendor with conditions, the system automatically generates a matching rule and rule assignments.

Automation Rules

Rules define the logic for matching assets to vendors. Each rule contains:

• Name: Descriptive identifier for the rule
• Required Tags: Asset must have ALL of these tags to match (AND logic)
• Optional Tags: Asset must have AT LEAST ONE of these tags to match (OR logic)
• Approval Settings: Whether orders matching this rule require approval

Rules can be:

• Manually Created: Explicitly defined by admins with custom tag combinations
• Auto-Generated: Automatically created when you add a vendor with conditions

Auto-generated rules are linked to their source vendor and are marked as system-managed.

Rule Assignments

Rule assignments connect rules to vendors for specific order types. Each assignment specifies:

• Rule: Which matching rule this applies to
• Vendor: Which vendor receives orders
• Order Type: Part, service, or capital
• Priority: Numeric value (1 = highest priority) for fallback scenarios
• Auto-Maintenance Flag: Whether to automatically set the asset to maintenance mode

A single rule can have multiple assignments for different order types, and multiple assignments for the same order type at different priorities (for vendor fallback).

Tag-Based Matching Explained

The automation system relies on asset tags to determine vendor routing. Tags are key-value pairs stored on each asset, such as:

• manufacturer:Dell
• model:PowerEdge R740
• location:DataCenter-1
• department:IT
• support-tier:premium

Rules use two types of tag matching logic:

Required Tags (AND Logic)

Asset must have all required tags to match the rule.

Example: Rule requires manufacturer:Dell AND department:IT

• Asset with tags manufacturer:Dell, department:IT, location:Building-A → Matches
• Asset with tags manufacturer:Dell, department:HR → Does not match (missing IT department)

Optional Tags (OR Logic)

Asset must have at least one optional tag to match the rule.

Example: Rule has optional tags model:PowerEdge R740 OR model:PowerEdge R750

• Asset with tags manufacturer:Dell, model:PowerEdge R740 → Matches
• Asset with tags manufacturer:Dell, model:OptiPlex 7090 → Does not match (no matching model)

Combined Logic

Rules can use both required and optional tags together:

Example: Rule requires manufacturer:Dell AND one of (model:PowerEdge R740 OR model:PowerEdge R750)

• Asset must be a Dell AND one of the specified models

Approval Workflows

The system supports optional approval workflows to ensure appropriate oversight before orders are sent to vendors. Approval can be triggered by two configurations:

Rule-Based Approval

When a rule is configured to require approval:

• Any order matching that rule enters Pending status
• Designated approvers (user IDs specified in the rule) receive notification
• Order cannot be sent until an admin approves it

Vendor-Based Approval

When a vendor is configured to require approval:

• Any order routed to that vendor enters Pending status
• Designated approvers (user IDs specified in the vendor) receive notification
• Order cannot be sent until an admin approves it

Combined Approval

If both the rule and vendor require approval:

• Order requires approval (source: "Rule+Vendor")
• Approver lists from both sources are merged and deduplicated
• Any designated approver can approve the order

Note: Rule approval settings take precedence. If a rule requires approval, vendor approval settings are ignored.

Order Status Lifecycle

Orders progress through different statuses based on approval requirements and notification success:

Status	Meaning	Next Action
Pending	Order created but awaiting approval (if required) or initial send attempt	Admin approves/rejects, or system attempts first send
Approved	Order approved by designated user, ready for vendor notification	Admin manually triggers notification send
Rejected	Order rejected by approver, will not be sent	None - order closed
Sent	Email successfully delivered to vendor	None - fulfillment happens outside platform
Failed	Email delivery failed due to technical issue	Admin can resend notification
Cancelled	Order cancelled by requester or admin before sending	None - order closed

Once an order reaches Sent status, the vendor has received the notification and fulfillment coordination happens externally. The system does not track shipping, delivery, or completion milestones.

Automatic Maintenance Mode

Rule assignments support an Auto-Maintenance flag that automatically sets an asset to maintenance mode when an order is created. This feature:

• Prevents the asset from appearing in certain reports or dashboards
• Signals that the asset is temporarily out of service
• Requires manual removal from maintenance mode after service is complete

This is particularly useful for service orders where equipment will be unavailable during repair or maintenance work.

Scope Tags and Multi-Tenant Support

For organizations with hierarchical account structures (parent accounts with multiple child accounts), the system supports scope tags for access control:

• Vendors can be scoped to specific child accounts or shared across the organization
• Rules inherit scope from their primary vendor or can be explicitly scoped
• Orders inherit scope from the account creating them

This allows you to:

• Create organization-wide vendors visible to all child accounts
• Create location-specific vendors visible only to certain locations
• Maintain separate vendor lists for different business units

System Limitations and Design Philosophy

The Order Management System is designed to handle the request and notification phases of ordering. It does not:

• Track fulfillment: No shipping status, delivery confirmation, or completion tracking
• Manage invoicing: No purchase orders, invoices, or payment tracking
• Inventory management: No stock levels, part availability, or warehouse integration
• Vendor portal: Vendors interact via email only, not through the platform

This focused design ensures the system excels at automating vendor selection and notification while keeping configuration simple. Organizations that need full procurement workflows should integrate the system with existing ERP or procurement platforms.

Getting Started Checklist

To begin using the Order Management System effectively:

1. Define Your Vendors
   • List all service providers, suppliers, and contractors
   • Gather contact emails for parts, service, and capital orders
   • Identify which vendors require approval workflows
2. Review Asset Tags
   • Ensure assets have consistent manufacturer and model tags
   • Add location, department, or custom tags as needed for routing
   • Standardize tag naming conventions across your organization
3. Configure Vendors with Conditions
   • Create vendors with tag-based conditions to auto-generate rules
   • Start with simple manufacturer-based rules, then refine
   • Test vendor resolution before going live
4. Set Up Approval Workflows (If Needed)
   • Identify which vendors or order types require approval
   • Designate approver users in vendor or rule configurations
   • Document approval procedures for your team
5. Train Your Team
   • Show users how to create orders from the web portal and mobile app
   • Explain when to use parts vs. service vs. capital order types
   • Clarify what happens after the vendor receives the notification

Next Steps

Now that you understand the core concepts, explore these related articles:

• Understanding Parts, Service, and Capital Orders - Detailed guidance on choosing the right order type
• Order Permissions & Roles - Who can create, approve, and manage orders
• How to Create a Vendor - Step-by-step vendor configuration instructions
• What Are Order Automation Rules? - Deep dive into tag-based matching logic

The Order Management System transforms scattered vendor communications into a centralized, automated, auditable process. By leveraging tag-based automation and optional approvals, you eliminate manual vendor selection while maintaining appropriate oversight.