Tier Parameters

Updated: May 12, 2021


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:

  • Vendor requires certain data point to identify / register the reseller in their systems
  • Vendors requires attributes to associate requests with certain marketing (or similar) programs related to resellers

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:

  • Tier-0 or “End-Customer” (required) – represents the beneficiary of subscriptions.
  • Tier-1 or “Reseller” (required) – represents the tier of the supply chain one step above End-Customer in the hierarchy. Depending on the configuration of the Commerce management system, this could be the Distributor, the Reseller or the Marketplace entity.
  • Tier-2 or “Reseller” (optional) – represents the tier of the supply chain two steps above End-Customer in the hierarchy. Depending on the configuration of the Commerce management system, this could be the Distributor, the Reseller or the Marketplace entity.

Tier Parameters Definition

When defining parameters of a product, each Parameter can be assigned to one of the following 3 scopes:


  • Subscription – assigns parameter to the Tier-0 (see the above paragraph for the explanation)
  • Tier-1 – assigns parameter to the Tier-1 (see the above paragraph for the explanation)
  • Tier-2 – assigns parameter to the Tier-2 (see the above paragraph for the explanation)

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.

Subscription and Tier Configurations

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.

Fulfillment of Requests with Tier Parameters

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:

  • Approve request (specifying a particular activation template)
  • Ask for changes or store parameter values for the “fulfillment” type
  • Reject request

Once tier configuration request is approved, the fulfillment request will move from the “Tiers Setup” status to “Pending”.

Tier Configurations and the Commerce Management

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:

  1. Request a change of the values for all parameters that are assigned to the Ordering phase.
    • Note that reseller can only request changes for the parameters that has a value. In case vendor has a hidden parameter, it will only be visible to the reseller in case value is assigned to it. Vendor can inquire for hidden parameters in order to ask reseller to populate those.
  2. Access the activation tile attached to the particular tier configuration.
  3. Trigger actions defined by vendor for the tier configuration.
Is this page helpful?
Translate with Google
Copied to clipboard