Multi-Tier Order Approval

Introduction

The multi-tier order approval process allows for a collaborative approval process for orders. It involves several approving partners who are part of a contract chain. Thanks to this feature, you can make sure that orders are completed only when all the required approvals are obtained.

Select partners can use the multi-tier order approval feature to control, review and approve orders in a multi-partner setup. This can be especially useful when many partners in a service supply chain depend on each other in terms of providing services and products to their customers as reviewing and approving customer orders give partners more financial control.

If there are more than one approving partner in a contract chain, for example, a distributor and seller, they both have to approve an order. The Pending Approval order status will remain until all partners in the contract chain have approved the order. If at least one of the approving organizations rejects order through the Order API then order is rejected entirely. This is the multi-tier component of this feature.

What do you need to use this feature?

To use multi-tier order approval, you need:

• To be a partner for who this feature has been activated (this is a partner-specific implementation).
• An active AppXite account with admin permissions (as a distributor or reseller).
• Access to API and details related to our API endpoint and API calls for this feature
• Access to the AppXite settings window with the Credit Limit tab.

In this article:

• Overview of the multi-tier order approval process
• Multi-tier order approval in the UI
• Order Approval Process
• Use cases
• Additional information

Overview of the multi-tier order approval process

The approval process in the multi-tier order setup begins when a customer, or a seller on their behalf, creates a new order or modifies an existing subscription:

1. When a customer or a seller places an order, the order receives the Pending Approval status. This status remains until all approving partners approve the order.
2. Depending on the configuration, the AppXite platform can send an approval webhook to the approving partners (distributors and sellers).
3. Each approving partner in the chain can review the webhook that contains details related to the order.
4. Approving partners react to the notification through the API (they can either approve or reject the order).
5. If any of the approving partners rejects the order, the order cannot be completed. Then the customer receives a rejection message. Note that all partners in the chain need to approve the order so that it can be finalized.
6. If all the partners approve the order, the product can be provisioned.
7. A new subscription (or the existing subscription is updated) is created for the customer.
8. When the provisioning process is successful, the platform sends a webhook notifying the approving partners. The webhook contains the details of the final order.
   
   

Note that if any of the approving partners rejected the order through the API, the order is rejected completely.

Below, you can see what the flow of the multi-order approval process looks like:

Multi-tier order approval in the UI

You can find options related to the multi-tier order approval process located under the Credit Limit tab that is located in the Currency & Payments section of Settings:

Settings > Currency & Payments > Credit Limit

The Credit Limit tab allows you to manage credit risk and order approval settings.

Under the tab, you can access the information related to:

• Credit risk group management
• Credit risk group details
• Organizations management
• Policy configuration
• Order approval process
  
  

Credit risk group management tab

Under the Credit Tab, you can see a table listing credit risk groups.

The table contains the following columns:

• Credit risk group – this is the name of a specific credit risk group.
• Organizations – it shows the number of organizations within each credit risk group.
• Updated on – this is the date when the credit risk group was last mosified.
• Updated by – this is the name of the person who last modified the group.
• Primary – this field indicates if a credit risk group is set as the primary credit risk group. Remember that only one group at a can be set as primary.

Credit risk group details page

If you click on a specific credit risk group, you can access its detailed view.

The detailed view of a credit risk group includes:

• Policy scope – it's a list of policies within the selected credit risk group. It allows for sorting based on the control level of offers.
  • Created on – this field shows the date when a specific policy was created.
  • The Create New Group button – it lets you create a new credit risk group by defining the name and scope of a new group (the scope may include all offers, selected offers, or just offers from a specific vendor).
•  

Organizations management page

On the Organizations management page, you can select a specific organization to see organizations that are assigned to a specific risk group.

The table on the Organizations management page contains the following columns:

• Status – it indicates if an organization is active or inactive.
• Organization – The name of an organization. You can use this column to sort and filter the table.
• External ID – It's the ERP (Enterprise Resource Planning) ID number of an organization.
• Country – This column shows the country in which the organization is located.
• Tier – It shows if the organization is Direct or Indirect (for example, a second-tier reseller).
• Credit Risk Group – This column displays the information about the assigned credit risk group. You can change or remove it directly from the table.

Policy configuration slider

You can add a new policy in a credit risk group by selecting a specific vendor or all vendors.

Note that when you choose a specific vendor, you can narrow the scope to specific offers. This means that you can manage risk by evaluating individual products and groups when you select many offers for a single vendor.

Order approval process

The Orders tab shows you which orders are approved and which are still pending approval. Approved orders trigger the service provisioning process while the pending orders are paused and remain in the Pending Approval status.

When the multi-tier order is properly configured, you can send notifications to let all the approving partners know that an order has been placed by an entity in a specific credit risk group.

Use cases

We can distinguish three distribution models (or distribution use cases):

• 2-Tier Distribution Model
• 1-Tier Distribution Model
• Hybrid Distribution Model

2-Tier Distribution Model

1. Distributor A creates a Credit Risk Group (called, for example, 'CR-A') on their own platform to manage and monitor credit risk at the distributor level.
2. Distributor A adds Second-Tier Reseller B to 'CR-A' and defines the specific credit risk scope for this reseller.
3. Customer B, on Platform B (managed by Second-Tier Reseller B), places an order.
4. The order triggers an approval flow based on the Credit Risk Group 'CR-A'.
5. The order goes into the Pending Approval status.
6. Distributor A receives a Pending Approval webhook with details of the credit risk amount that is specific to the distributor level.
7. Distributor A reviews and approves the order through the approval API.
8. After the approval, the order goes through the standard order completion process.
9. Once the order item is provisioned, Distributor A receives an OfferProvisioned webhook as confirmation.
10. The implementation is triggered to get the final credit risk assessment for the order item (specific to Distributor A’s credit risk level).

1-Tier Distribution Model

1. First-Tier Seller C creates a risk group (called, for example, 'CR-C') on their platform to track and manage credit risk for their customers.
2. First-Tier Seller C adds Customer C to this group and sets specific credit risk limits for them.
3. Customer C places an order on Platform C which the First-Tier Seller C manages.
4. The order goes through the approval process based on the 'CR-C' rules and is marked as Pending Approval.
5. First-Tier Seller C gets notified about the Pending Approval status. The notification includes the credit risk amount for the seller to review.
6. First-Tier Seller C reviews and approves (or rejects) the order through this custom implementation.
7. Once it is approved, the order goes through the standard approval steps.
8. After the order is set up, the First-Tier Seller C receives a notification that the offer has been provided.
9. The implementation makes a final check to confirm the credit risk for the completed order at the First-Tier Seller C's level.

Hybrid Distribution Model

1. Distributor A creates a Credit Risk Group (called, for example, 'CR-A') on their Platform A.
2. Second-Tier Reseller B (a reseller associated with Distributor A) creates their own Credit Risk Group (called, for example, 'CR-B') on their Platform B.
3. Distributor A adds Reseller B to the 'CR-A' group and defines the scope of credit risk management.
4. Reseller B adds Customer B to the 'CR-B' group and defines the scope of credit risk management.
5. Customer B places an order on Platform B that is associated with Reseller B.
6. The order goes to the approval process and is pending approval based on the credit risk settings of both 'CR-A' and 'CR-B'.
7. Distributor A receives a pending approval notification (webhook) with the credit risk amount at Distributor A's level.
8. Second-Tier Reseller B also receives a pending approval notification (webhook) with the credit risk amount at their own level.
9. Distributor A approves the order using the approval API.
10. Reseller B also approves the order using the approval API.
11. The order goes through the regular order processing steps.
12. Once the order item is provisioned, Distributor A receives an OfferProvisioned notification (webhook).
13. The implementation triggers an API call to get the credit risk details for each order item at Distributor A's level.
14. After provisioning, Reseller B receives an OfferProvisioned notification.
15. The implementation triggers another API call to get the credit risk details for order item at Reseller B's level.

Additional Information

Note that setting a primary group displays a warning informing users that newly added organizations are by default added to that primary group. If you try to remove the primary group, you can see a warning message stating that organizations assigned to that primary group will now be unassigned.

Some statuses restrict the possibility of adding an organization to credit risk group. For example, if an organization is marked as Suspended or Blocked, you cannot add it to a credit risk group. If an organization has received such a status, you can see an inactive button and a tooltip that informs you why you cannot add that specific organization to a credit risk group.

Summary

If you are a partner who has this feature enabled, you can find the multi-tier order approval under the Credit Limit tab. The feature gives you options to change credit limits, manage credit risk groups, assign organizations to them, configure policies, and determine an order approval process that is suitable for your setup.