How Can I Credit Multi-Dimensional Hierarchies (Advanced)?

How Can I Credit Multi-Dimensional Hierarchies (Advanced)?


This article applies if you've configured teams to represent a single hierarchy, but ran into issues because you want to use different hierarchies to credit users or teams depending on the plan or scenario.

Let's say that you have configured a single hierarchy like this:



You want your plans to implement crediting rollups like this:



However, a single team hierarchy does not quite work because, depending on the plan, you want to use a different (parallel) hierarchy.

You could certainly create other team hierarchies, and use tags on team to identify each tree. However, this can become cumbersome and repetitive.

For those scenarios, it's often best to flatten things. For example, you could define on each user a custom variable which describes multiple crediting hierarchies:



In the example above, it looks like there are 2 ways we can credit parents entities. Plan A may use @@CreditTo1 to credit teams or reps based on a geographical hierarchy. Plan B may use @@CreditTo2 to credit teams or reps based on a sector hierarchy. We are flattening things by enumerating all the entities which should be credited (within each parallel hierarchy).

In the example above, we would then add aliases to users or teams, so they can be credited for keywords such as "GA". We would also configure a dynamic crediting formula on our plan. The following dynamic crediting formula below reads the "Rep" field from each transaction, and checks if it can find a matching user or team. If so, we pull custom variable "CreditTo1" from this user or team, which will be a text value such as "Atlanta;GA;SW;USA". As a result, we can credit all entities having those aliases.



Of course, we would also select this option to allow crediting of multiple entities. In the example below, we assign full credit to each credited team (ex: "Altanta", "GA", "SW", and "USA"). Payout formulas can calculate payouts based on the team's name, depth, tags, custom variables, etc.



As you can see, this approach is extremely flexible. Because custom variables are time-dependent, you could even make each hierarchy evolve independently. You can even combine approaches and use both team hierarchies and custom variables to deliver multi-dimensional hierarchical crediting.

Please keep in mind that this is an advanced scenario. We recommend reaching out to our technical team to design the best possible solution.

    • Related Articles

    • How Can I Deal With Ever Changing Hierarchies (Advanced)?

      This article applies if you've configured teams to represent a single hierarchy, but ran into issues because your team hierarchy is changing all the time. Let's say that you have configured a fixed hierarchy like this: One option to deal with change ...
    • How Can I Specify A Dynamic Crediting Formula (Advanced)

      Sometimes, you want to credit users or teams based on dynamic crediting rules. Do You Need A Crediting Formula? In most cases, it's sufficient to rely on aliases and system mapped transaction fields to credit users or teams. The following crediting ...
    • Checking If Transactions Can Be Credited To a Team (Advanced)

      Applicability This topic is applicable to the following scenario: You are creating a new incentive plan You want to measure sales performance by individual Sales transactions have one of the following issue They do not include "Owner / Sold By" data ...
    • Checking If Transactions Can Be Credited To a User (Advanced)

      Applicability This topic is applicable to the following scenario: You are creating a new incentive plan You want to measure sales performance by team / territory Sales transactions have one of the following issue They do not include a team / ...
    • How Can I Specify A Dynamic Transaction Filtering Formula (Advanced)

      Sometimes, you want to filter transactions based on dynamic rules. Do You Need A Filtering Formula? In most cases, it's sufficient to rely on saved queries to filter transactions. For example, you could define a transaction filter such as this: And ...