Work Order Attributes and Lifecycle
Attributes of a Work Order can be divided into one of the following categories:
- Core: These are the attributes mandated by the platform for Work Order entities. Some of these attributes are required.
- System: These are system-defined attributes.
- Custom: These attributes are defined by the Tenant to enhance their usability. Tenants can define custom validations and also specify whether they are to be indexed or non-indexed.
Category | Attribute Name | Data Type Expected | Description |
|---|---|---|---|
Core | Tenant ID | String | The ID of the tenant to whose realm the Work Order belongs. |
System | Work Order ID | UUID | System-generated unique ID. |
Core | Order ID | UUID | The Order to which this Work Order belongs. |
Core | Work Order Type | VarChar | Enum - MOVE_CONTAINERS - PHYSICAL_SERVICE - DIGITAL_SERVICE |
Core | Description | VarChar | Short textual description of the work order. |
Core | PickupDetails | VarChar | In case a Work Order has Containers involved, this field stores the pickup details such as: Contact Location PickupSlot ServiceTime |
Core | returnDetails (optional) | VarChar | In case a Work Order has to be returned at a specific location, return details may include: Contact Location returnSlot ServiceTime |
Core | DeliveryDetails (optional) | VarChar | Delivery Details may include: promisedDeliveryDate deliverySlot deliveryServiceTime |
Core | Containers (optional) | List | List of Container IDs. (Container details collected in platform order creation payload.) |
Core | Pickup Quality Checks (optional) | Object |  |
Core | Collect Amount On pickup (optional) | Boolean |  |
Core | Amount to collect on delivery (optional) | Amount Object | Amount Object including currency code. |
Custom | Custom Attributes 1-to-n (indexed) | Key-value | Core attributes for a Work Order with indexing. The tenant will be able to configure validations, if required, for these attributes. |
Custom | Custom Attributes 1-to-n (non-indexed) | Key-value | Custom attributes for a Work Order without indexing. The tenant will be able to configure validations, if required, for these attributes. |
System | Current State | VarChar |  |
System | Current Sub-state | VarChar |  |
System | Schema Version (optional) | Integer | The version of the work order schema configuration (for custom attributes) that was used to create the order. |
System | CreatedAt (optional) | Timestamp |  |
System | UpdatedAt (optional) | Timestamp |  |
System | Created By (optional) | VarChar |  |
System | Updated By (optional) | VarChar |  |
To create a Work Order Custom Attribute, call the POST /work-order/config/attributes endpoint and pass the following parameters in the request body:
Parameter | Description | Validation | Data type |
|---|---|---|---|
name | Name of the attribute. | minLength: 1 maxLength: 32 pattern: ^[a-zA-Z]{1,32}$ | string |
description | Description of the attribute. | minLength: 0 maxLength: 256 pattern: ^([a-zA-Z])([a-zA-Z0-9,\s]*)$ | string |
datatype | The data type of the Attribute. | Valid values: string, number, boolean, object, array, money | string |
validation | Specifies all of the validations that are performed on the Attribute when an order of this type is created or updated. |  |  |
indexed | Specifies whether the Attribute is indexed. Filter or search operation on the basis of a custom attribute is only allowed if this field is set as TRUE. |  | boolean |
Note: Some of the core Work Order attributes that can be updated are listed below:
- pickupDetails
- returnDetails
- deliveryDetails
The following sample payload shows how to create Work Order Custom Attributes named stringValidations and intValidations:
To add a Work Order to an Order, call the PUT /{orderId}/work-order endpoint. The following sample payload shows how to add a Work Order to an Order:
A Work Order has the following lifecycle states and sub-states:
- Created - Work Order has been created in the system.
- InProgress:Scheduled - A job has been created for the work-order.
- InProgress:assigned - Job corresponding to work order has been added to a dispatch
- Inprogress:Active - Job corresponding to the work order has been started
- OnHold:OnHold - Logistics provider wants to restrict any further actions to be taken by the operations (For ex. Payment Issues for an order / Damage Issue for an Order).
- Closed:Success - Work order has been completed successfully.
- Closed:Partial - Work order containers have been partially delivered.
- Closed:Failed - Work order has not been successfully delivered.
- Closed:Canceled: Cancellation request raised by a Client is processed.