The following presents and describes all available statuses of Tier Configuration and Tier Requests on the CloudBlue Connect platform.
Available tier configuration statuses are schematically illustrates and described below.
Once a new tier configuration object is created, the system assigns the Processing status to this object. Alternatively, this status indicates that a tier configuration was updated by Vendors or Distributors. Therefore, Vendors are required to process this tier configuration by approving or rejecting its corresponding tier configuration request.
The system assigns the Draft status to a new tier configuration object in case the dynamic validation capability is enabled. Thus, the Connect platform enables Distributors implement the real-time validation of tier configuration requests. Once a tier request is successfully validated, the system transfers this configuration to the Processing state. Otherwise, this draft tier configuration is permanently deleted.
This status indicates that Vendors approved a pending tier configuration request and tier configuration is successfully activated. Once the tier configuration is activated, its interconnected fulfillment request is assigned to the Pending state.
Furthermore, note that the system also assigns the Active status to a tier configuration instance in case a generated tier request is rejected by Vendors. Thus, active tier configurations are also associated with failed tier requests and failed fulfillment request.
Available tier request states are schematically illustrated and described below.
The system assigns the Draft state to a new tier request in case the dynamic validation capability is enabled. Therefore, the Connect platform enables Distributors implement the real-time validation of tier configuration requests. Once a tier request is successfully validated, the system transfers this request to the Pending state. Otherwise, this draft request is deleted.
In case parameter value should be specified by tiers or provided parameter data in a tier request is not valid, the system can assign the Inquiring status to this request. Therefore, the Connect platform sends an email with a specific form to provided tier contacts. Once this form is successfully filled out, the platform applies provided data and transfers the request to the Pending state.
Note that it is also possible to reject inquiring request and transfer them to the Failed state. In addition, the system enables to manually set tier requests to the Pending state.
The system displays the Tier Setup status for a T1-level request in case its interconnected T2-level request is not processed by Vendors. Thus, Vendors are required to locate and approve T2-level request. Once this request is successfully approved, the system transfers the T1-level request from Tier Setup to the Pending state. Alternatively, in case the parameter value is inquired, the system transfers T1-level request to the Inquiring state.
Once the system assigns the Pending status to tier requests, Vendors are required to process these pending requests. Depending on the Vendors actions, the system transfers these requests to the Approved state or the Failed state. Furthermore, note that Vendors can also inquire parameter data and consequently transfer a pending request to the Inquiring state.
Once Vendors approve a pending tier request, the Connect platform assigns the Approved status to this request. Therefore, its associated tier configuration will be successfully activated by the system. A fulfillment request that required in the Tier Setup state will be also assigned to the Pending status. Note that the Approved status represents a terminal state, meaning no actions with approved requests are available or required.
In case reject Vendors or Distributors a tier request, the system assigns the Failed status to this request. Therefore, its interconnected fulfillment request is assigned to the Failed status. Provided changes within a failed update tier request will also not be implemented. Note that this status represents a terminal state, meaning no actions with failed requests are available or required.
