Tier parameters allow vendors to collect data from resellers involved into the supply chain of the request. This feature may be needed in a number of business scenarios, including but not limited to the following:
Tier parameters work in a way very similar to the subscription parameters (see this article). Key difference between subscription parameters and tier parameters is the actor involved. Subscription parameters are attached to subscriptions while tier parameters are related to the reseller. Please note that Connect supports hierarchy of Tiers (up to 2) as illustrated by the following diagram:
Note that Tiers count starts from the End-Customer (effectively “Tier Zero”) and goes up the supply chain to the Reseller and Reseller of the Reseller if needed. Connect associates each request with the following Tiers, where Tier-2 is optional:
When defining parameters of a product, each Parameter can be assigned to one of the following 3 scopes:
Namely:
When a request for a product that has tier parameters is created, connect checks if Tier Configuration object already exists for each tier involved into that sale (request). If not and there are tier parameters of type ordering that are required, Connect inquires the reseller, using the technical contact details provided in the request in order to obtain the necessary values. This inquiring is done in the scope of a Tier Request, in other words a type of request that only involves a given tier and has similar life cycle as a fulfillment request.
This process can be schematically illustrated with the following diagram:
Once vendor approves the tier request, the customer request can move forward through the standard fulfillment flow. Following requests that involve the same tier will refer to the same Tier Configuration, i.e. it is only required to supply tier-related information once.
Vendors can also define fulfillment tier parameters. this is quite useful when vendor must provision the reseller in their systems and store certain unique identifiers in Connect Required by the following requests of the same tier.
Note that tier parameters are calculated relative to the effective tier, i.e. the same reseller may act as both tier-2 and tier-1 in different scenarios while selling subscriptions to different end-customers.
In Connect, subscriptions are created and modified using regular requests of the fulfillment queue of the following types:
Tier Configurations are created and modified using tier-requests, the key difference with the standard fulfillment queue is that tier-requests are not associated with the product items. The following tier-request types are supported.
Since Tier configurations are required to fulfill a subscription request, requests might get into the special “Tiers Setup” status that is used to park all fulfillment requests that involve a given tier while tier configuration is not complete. This introduces the following new status in the requests state transition diagram:
At the same time, tier requests themselves could get into that status, while awaiting configuration of the higher tier. In the most complex case of a 2-tier environment, activation of the first subscription for the particular tier-1 and tier-2 can be illustrated by the following diagram:
Tier requests are approved using a particular tier template, this templates are created and maintained similarly to the standard “Activation tiles” but shown only to the particular tier in the commerce platform. This provides vendors with a way to communicate to resellers information of how product can be managed by them, for example. Additionally, tier configurations may have actions associated with them. Those actions can be used to help reseller accessing reseller console provided to them by the vendor through single sign on. Definition of actions for tiers is done the same way as actions for subscriptions.
When a new request with tier parameters is created, Connect checks either associates it with existing tier configurations or creates new ones. In case tier configuration exists, it will be shown in the Parameters tab of the request details:
From there, user can see complete information of the tier parameters and additional tier configuration details by using the “Show Tier” action. In case Tier Configuration does not exist yet, request is assigned to the special “Tiers Setup” status:
Fulfillment queue has a separate filter that shows tier configuration request separately from the rest of the fulfillment queue:
Tier requests follow the state machine documented earlier in this article. Vendors must process requests in the “Pending” status. While processing, it is possible to perform one of the following actions:
Once tier configuration request is approved, the fulfillment request will move from the “Tiers Setup” status to “Pending”.
CloudBlue and Odin Automation provide user interfaces to the resellers (tiers) to review and manage configurations created for them in the scope of a given product. Using these user interfaces resellers can:
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Portuguese
Russian
Spanish