Order Permissions & Roles

The Order Management System uses role-based permissions to control who can create orders, approve requests, manage vendors, and configure automation rules. Understanding these permissions helps you delegate responsibilities appropriately while maintaining security and oversight.

This article explains the permission model, details what each role can do, and provides guidance on assigning roles effectively within your organization.

Permission Model Overview

The Order Management System recognizes three primary user roles:

Role	Typical Users	Key Capabilities	Access Scope
Regular User	Equipment operators, technicians, field staff	Create orders, view own orders	Limited to own orders
Admin	Department managers, facility managers, IT leads	Create/manage orders, approve orders, manage vendors, configure rules	Account-wide visibility
API Token	Automated systems, integrations	Create orders programmatically on behalf of users	Account-wide, requires user ID specification

Roles are assigned at the user account level and apply across all platform features, not just Order Management.

Regular User Permissions

Regular users have limited permissions focused on creating and tracking their own orders.

What Regular Users Can Do

• Create Orders: Create part, service, and capital orders for any asset they have access to
• View Own Orders: See all orders they personally created
• Add Notes: Add additional information to their own orders
• Upload Attachments: Attach photos or documents to orders during creation
• Cancel Own Orders: Cancel orders they created (before sending only)

What Regular Users Cannot Do

• View Others' Orders: Cannot see orders created by other users
• Approve Orders: Cannot approve pending orders (even their own)
• Manage Vendors: Cannot create, edit, or disable vendors
• Configure Rules: Cannot create or modify automation rules
• Resend Notifications: Cannot manually resend failed notifications
• Override Vendor Assignment: May be restricted from manually selecting vendors (configurable)
• Edit Order Status: Cannot manually update order status after creation

Order Visibility

Regular users see only their own orders in the Order Management dashboard. This maintains privacy and prevents confusion when multiple users are creating orders across the organization.

Exception: When viewing an asset detail page, regular users may see all orders for that asset (configurable based on organization preference).

Typical Use Cases for Regular Users

• Field Technicians: Create service orders when equipment fails
• Equipment Operators: Request parts for routine maintenance
• Facility Staff: Request building system repairs
• Department Staff: Request IT equipment or office supplies

Admin Permissions

Admins have comprehensive permissions to create, manage, and oversee all orders within their account.

What Admins Can Do

Order Management

• Create Orders: Create orders for any asset, on behalf of any user
• View All Orders: See all orders across the entire account
• Edit Orders: Update notes, status, and other order properties
• Cancel Any Order: Cancel orders created by any user
• Approve Orders: Approve or reject pending orders (if designated as approver)
• Resend Notifications: Manually trigger notification resend for failed orders
• Manually Send Approved Orders: Trigger notification after order approval
• Override Vendor Assignment: Manually select vendors regardless of automation rules
• Update Order Status: Manually change order status for record-keeping

Vendor Management

• Create Vendors: Add new vendor configurations
• Edit Vendors: Update contact emails, approval settings, conditions
• Disable Vendors: Temporarily disable vendors (prevents auto-selection)
• Delete Vendors: Remove vendors (only if no orders reference them)
• Configure Approval Requirements: Specify which vendors require approval
• Designate Approvers: Assign specific users as approvers for vendors
• Set Vendor Conditions: Define tag-based routing conditions

Rule Management

• Create Rules: Define new automation rules with tag-based matching
• Edit Rules: Modify required/optional tags, approval settings
• Delete Rules: Remove rules (also deletes associated rule assignments)
• Create Rule Assignments: Link rules to vendors for specific order types
• Set Assignment Priority: Configure fallback vendor order
• Configure Auto-Maintenance: Enable automatic maintenance mode for service orders
• View Auto-Generated Rules: See system-created rules from vendor conditions

Configuration & Reporting

• Access Dashboard: View account-wide order metrics and trends
• Generate Reports: Export order data for analysis
• View Audit Logs: See complete history of order changes
• Configure Scope Tags: Set multi-tenant access controls

Typical Use Cases for Admins

• IT Managers: Configure vendors for hardware/software, approve capital orders
• Facilities Managers: Manage building service vendors, approve HVAC/electrical work
• Operations Managers: Oversee fleet vendors, approve major service orders
• Finance Leaders: Review and approve high-value orders

API Token Permissions

API tokens allow external systems to interact with Order Management programmatically. This is useful for integrations with monitoring systems, maintenance scheduling tools, or custom applications.

What API Tokens Can Do

• Create Orders: Programmatically create orders via REST API
• Specify User Context: Create orders on behalf of specific users (requires user ID)
• Query Orders: Retrieve order details and status
• List Vendors: Get available vendors for API-driven selection
• Preview Vendor Resolution: Test which vendor would be selected before creating order

What API Tokens Cannot Do

• Approve Orders: Approval requires human user interaction
• Manage Vendors: Cannot create or edit vendor configurations
• Configure Rules: Cannot modify automation rules
• Delete Orders: Cannot remove orders from system

API Token Security

API tokens have account-level scope and must be secured properly:

• Treat as Passwords: Never expose tokens in client-side code or public repositories
• Rotate Regularly: Change tokens periodically (quarterly recommended)
• Limit Distribution: Only provide tokens to authorized systems
• Monitor Usage: Review API logs for unexpected activity

When creating orders via API, you must specify the user ID of the person on whose behalf the order is being created. This maintains proper attribution and audit trails.

Approval Permissions

Approval capabilities are separate from the Admin role. Any user (Regular or Admin) can be designated as an approver for specific vendors or rules.

How Approvers Are Designated

Approvers are specified by user ID in two places:

1. Vendor Configuration: Vendor's "Approver User IDs" field lists users who can approve orders to that vendor
2. Rule Configuration: Rule's "Approver User IDs" field lists users who can approve orders matching that rule

A user need not be an admin to be an approver—you can designate Regular users as approvers for specific workflows.

Approval Workflow Permissions

Action	Who Can Do It	When
Create order requiring approval	Any user with order creation permission	During order creation
Approve order	Users listed in vendor or rule approver settings	While order in Pending status
Reject order	Users listed in vendor or rule approver settings	While order in Pending status
Trigger notification after approval	Admins only	After order approved

Best Practice: Separate Approval Authority

Consider designating specific approvers based on:

• Cost Thresholds: High-value orders require senior manager approval
• Department Alignment: IT orders approved by IT lead, facilities orders by facilities manager
• Vendor Relationships: Strategic vendors require relationship owner approval
• Order Type: Capital orders require finance approval, service orders require ops approval

Multi-Tenant Permissions (Scope Tags)

Organizations with hierarchical account structures (parent account with multiple child accounts) can use scope tags to control visibility.

How Scope Tags Work

• Vendors can be tagged for specific child accounts or shared organization-wide
• Rules inherit scope tags from their linked vendor or can be explicitly scoped
• Orders inherit scope tags from the creating user's account

Visibility Rules

Users see vendors, rules, and orders based on scope tag matching:

User's Scope	Object's Scope	Visibility
No scope tags (root account)	Any scope	Visible (root sees everything)
Child account A	Child account A	Visible (exact match)
Child account A	Child account B	Not visible (different scope)
Child account A	No scope tags (organization-wide)	Visible (shared resource)

Use Cases for Scope Tags

• Regional Vendors: Create location-specific vendors visible only to that location's users
• Department Vendors: IT department vendors separate from facilities vendors
• Shared Vendors: Organization-wide vendors (e.g., national service providers) visible to all child accounts

Permission Assignment Best Practices

Start Restrictive, Expand as Needed

Begin with minimal permissions and grant additional access based on demonstrated need:

1. Initial Rollout: Most users as Regular, few designated Admins
2. Monitor Usage: Identify users who frequently need admin intervention
3. Promote Selectively: Elevate specific users to Admin based on role requirements
4. Document Criteria: Establish clear rules for who should have Admin access

Designate Approvers Thoughtfully

Balance oversight with efficiency:

• Too Few Approvers: Bottleneck delays urgent orders
• Too Many Approvers: Dilutes accountability, unclear who should approve
• Right Approach: 2-3 approvers per vendor/rule, covering different time zones or shifts

Separate Duties for High-Value Orders

For capital orders or high-cost vendors:

• Requestor creates order (Regular user)
• Department manager reviews (designated approver)
• Finance approves (separate designated approver)
• Admin triggers final send

This separation ensures multiple reviews for significant expenditures.

Document Your Permission Model

Create internal documentation explaining:

• Who has Admin access and why
• Which users are approvers for which vendors/rules
• Escalation paths when approvers are unavailable
• Process for requesting permission elevation

Common Permission Scenarios

Scenario 1: Small Organization (10-50 users)

Structure:

• All staff as Regular users
• 2-3 managers as Admins
• 1 executive as approver for all orders over $5,000

Workflow:

• Staff create orders freely
• Low-value orders auto-send to vendors
• High-value orders require executive approval
• Managers handle vendor configuration and failed notifications

Scenario 2: Medium Organization with Departments (50-200 users)

Structure:

• Most staff as Regular users
• Department leads as Admins (IT Lead, Facilities Manager, Operations Manager)
• Department leads also designated as approvers for their respective vendors
• CFO as approver for all capital orders

Workflow:

• Staff create orders in their areas
• Routine orders auto-send
• Department-specific orders require department lead approval
• Capital orders require CFO approval
• Department admins manage their own vendors/rules

Scenario 3: Large Organization with Locations (200+ users)

Structure:

• Most staff as Regular users
• Site managers as Admins (scoped to their location via scope tags)
• Central procurement team as root Admins (organization-wide visibility)
• Site managers as approvers for local vendors
• Procurement team as approvers for shared/national vendors

Workflow:

• Staff create orders for assets at their location
• Site managers see only their location's orders
• Local vendors auto-route based on location tags
• Site-specific orders approved by site manager
• Organization-wide orders approved by procurement
• Central team manages shared vendors, site managers manage local vendors

Troubleshooting Permission Issues

User Can't Create Orders

Possible Causes:

• User account not active
• User doesn't have access to any assets
• User role improperly configured

Solution: Verify user account status and asset access permissions.

User Can't See Orders

Possible Causes:

• Regular user trying to see others' orders (expected behavior)
• Scope tag mismatch (user can't see orders from different scope)

Solution: If user needs broader visibility, promote to Admin or adjust scope tags.

User Can't Approve Orders

Possible Causes:

• User not listed in vendor or rule approver settings
• User ID mismatch (user's ID doesn't match approver list)

Solution: Add user's ID to the vendor or rule's "Approver User IDs" field.

User Can't Manage Vendors

Possible Causes:

• User is Regular user (expected—only Admins can manage vendors)

Solution: Promote user to Admin role if vendor management is part of their responsibilities.

Security Considerations

Principle of Least Privilege

Grant users only the permissions required for their job function:

• Field technicians rarely need Admin access—Regular user permission suffices
• Department managers need Admin to configure vendors but may not need approval authority
• Executives may be approvers without needing Admin access to configuration

Audit Trail Importance

All order actions are logged with user attribution:

• Who created the order
• Who approved or rejected it
• Who manually updated status or resent notifications

This audit trail is critical for compliance, dispute resolution, and process improvement.

Regular Permission Reviews

Periodically review permissions (quarterly recommended):

• Remove Admin access for users who changed roles
• Update approver lists when managers change
• Revoke API tokens no longer in use
• Verify scope tags still align with organizational structure

Next Steps

Now that you understand roles and permissions, explore these related articles:

• Placing Orders From the Web Portal - What Regular users see during order creation
• How to Create a Vendor - Admin task: setting up vendor configurations
• How the Approval Workflow Works - Detailed approval process for designated approvers
• What Are Order Automation Rules? - Admin task: configuring tag-based routing

Properly configured permissions ensure the Order Management System operates efficiently—empowering users to request what they need while maintaining appropriate oversight and control.