Platform Order Attributes and Lifecycle
Platform Order Attributes are divided into the following categories:
- Core: These are pre-defined attributes by the CoreOS Platform. Although, some of these attributes are optional.
- System: These are system-defined attributes that indicate the current order state. These attributes can only be updated by the Platform Order Orchestrator.
- Custom: These attributes are defined and configured by the Tenant depending on the use case. With these attributes, the Tenant can set up custom validations and mark them as indexed or non-indexed.
- Indexed: These are attributes that users can utilize to apply filters and retrieve specific data.
- Non-indexed: Users are not permitted to apply filters on these attributes and query the order data.
Category | Attribute Name | Data Type Expected | Description |
---|---|---|---|
Core | Tenant ID | String | The ID of the Tenant to whose realm the Order belongs. |
System | Order ID | UUID | System-generated order ID (unique across Tenants). |
Core | Client Name | VarChar |  |
Core | Client ID | VarChar | Client Participant ID. |
Core | Client Order ID | VarChar | This is the reference ID for the Order that was generated by the Client. This may not be unique in the Tenant’s universe. |
Core | Ready To Process | Boolean | By default, readyToProcess is set to true. If it is set to false, the order will be created but it blocks job creation. It can be updated from false to true only. True - Move from Created to In Progress state automatically (by orchestrator). False - Order will remain in the "Created" state and it will wait for an external command for moving it to In Progress state. |
Core | Customer/Consignee Contact | VarChar | Users have the option to provide either contact details or a Contact ID. If contact details are provided, the service will automatically generate and store a Contact ID, as contact details are considered personally identifiable information (PII). It's important to note that a contact phone number is expected to be a single phone number and not a list. The attributes "Name", "Phone", and "Email" are grouped together under the key "contact". |
Core | Customer/Consignee Location ID | UUID | Although the address will be passed in a standard address format for consumption Platform Order Service, it will be stored as a Location in Location Service. The corresponding Location ID will be stored here. |
Core | Work Orders Execution Flow Type | Enum | Specifies the order in which the multiple work orders of an order will be executed by the orchestrator. - START_TOGETHER - COMPLETE_TOGETHER - SEQUENTIAL (Default) |
Core | Cancellation Requested | Boolean | By default, this attribute will be false. However, it can be set to True by the cancel API. The result of the cancellation attempt (async process), will eventually get updated in the system attributes CancelationStatus and CancelationStatusTimestamp. - Cancellation requests should be rejected with a suitable error code if a cancellation request is already in process. - If a cancellation request leads to Cancellation Failure, this field should still retain its True status. - If a new cancellation request arrives after the previous request has been successful or failed, the request should be accepted and the Cancellation Status and Cancellation Status Timestamp need to be reset. |
System | Cancellation Requested On (optional) | Timestamp |  |
System | Cancellation Requested By (optional) | VarChar |  |
System | Cancellation Status (optional) | Enum | - NONE - default - PENDING - ATTEMPTING - SUCCESS - FAILED |
System | Cancellation Failure Reason Code (optional) | VarChar |  |
System | Cancellation Status Timestamp (optional) | Timestamp | If Order Canceled is True, this field indicates the Date/Time at which the order was canceled. |
Custom | Custom Attributes 1-to-n (indexed) | Key-value | Custom attributes for an 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 an Order without indexing. The tenant will be able to configure validations, if required, for these attributes. |
System | Work Order List (optional) | List | List of Work Order data. |
System | Current State (optional) | VarChar | Stores the state of the Order |
System | Current Sub-state (optional) | VarChar |  |
Core | orderSummary (optional) |  |  |
 | orderSummary>>InvoiceNumber (optional) | String | Invoice Number associated with the order. Could contain alphabets and numbers. minLength: 3 maxLength: 64 pattern: ^[a-zA-Z0-9:_-]$ |
 | orderSummary>>orderDescription | String | Description of the Order. Could contain details on the type of Order, its contents, etc. minLength: 1 maxLength: 256 pattern: ^([a-zA-Z])([a-zA-Z0-9,\s])$ |
 | orderSummary>>totalWeight (optional) |  | Total weight of the order information needed. |
 | orderSummary>>totalItems (optional) | Number | Total number of containers in the order. maximum: 1000 |
 | orderSummary>>totalOrderCost |  | The total cost of an Order |
System | Schema Version (optional) | Integer | The version of the order schema configuration (for custom attributes) that was active at the time of order creation. |
System | createdAt(optional) | Timestamp |  |
System | updatedAt (optional) | Timestamp |  |
System | Created By (optional) | VarChar |  |
System | Updated By (optional) | VarChar |  |
đŸ’¡Platform Order Orchestrator
The Platform Order Orchestrator allows tenants to pre-configure workflows for executing Work Orders. These workflows are based on the Work Order Type and are designed to create subsequent jobs necessary for fulfilling larger Work Orders. By utilizing the assigned workflow, current status, and external plugins, the Platform Order Orchestrator determines the next action required for seamless execution.

To create a Platform Order Custom Attribute, call the POST /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 the validations that can be applied to Order attributes. |  |  |
indexed | Specifies whether the Attribute is indexed. Filter or search operation based on a custom attribute is only allowed if this field is set as TRUE. |  | boolean |
Note: Some of the core Platform Order attributes can be updated. These attributes are listed below:
- DropDetails
- contact
- location
- OrderSummary
- invoiceNumber
- orderDescription
- totalWeight
- totalItems
- totalOrderCost
- readytoprocess(false to true only)
The following sample payload shows how to create Platform Order Custom Attributes namedstringValidations and intValidations:
A Platform Order has the following lifecycle states and sub-states:
- Initiated - Order created request has been accepted.
- Created - Order has been created in the system (i.e. WorkOrder & Container are created).
- InProgress:Scheduled - A job is created for a work-order of that 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 - Tenant wants to restrict any further actions to be taken by the operations (For ex. Payment Issues for an order / Damage Issue for an Order).
- Executed:Success - All instruction of the work-order has been successfully completed, now order is remaining for non-operational activities (for ex. billing).
- Executed:Partial - Instruction of the work-order has been partially completed, now order is remaining for non-operational activities (for ex. billing).
- Executed:Failed - All instruction of the work-order has been failed, now order is remaining for non-operational activities (for ex. billing).
- Executed:Canceled - Cancellation request has been processed, now order is remaining for non-operational activities (for ex. billing).
- Closed:success - All instruction of the work-order has been successfully completed & no further activities pending.
- Closed:Partial - Instruction of the work-order has been partially completed, no further activities pending.
- Closed:Failed - All instruction of the work-order has been failed, no further activities pending.
- Closed:Canceled - Cancellation request raised by a Client is processed, no further activities pending.
Platform Order Service provides the Tenant with an option to configure sub-states under any of the six lifecycle states and the rules governing the corresponding state and sub-state transition.