Hierarchy Validation Rules
Hierarchy validation rules ensure that newly created or updated hierarchies are properly structured. These rules are run each time you create or modify hierarchies.
All hierarchy types, including the predefined hierarchy types: Party Hierarchy, Dun and Bradstreet Hierarchy, and Customer Hierarchy, enforce the following validation rules in active versions of customer hierarchies.
-
A hierarchy can't contain a merged party.
-
A hierarchy can contain parties with only certain party usages such as sales account, sales prospect, (internal) legal entity, external legal entity, and buying customer. A buying customer is also considered as an external legal entity.
-
If a party is an external legal entity, its parent can only be an external legal entity.
-
If a party is an (internal) legal entity, its parent can only be a (internal) legal entity.
-
If a party isn't an external legal entity or (internal) legal entity, its parent can only be an eligible customer. For example, a sales prospect, sales account, external legal entity, (internal) legal entity or a buying customer.
-
A party can be present in only one active tree across all trees in the customer hierarchy.
-
If there are sales accounts organized in a customer hierarchy, all nodes in that hierarchy must be sales accounts. Sales accounts that appear within larger sales accounts are called in-between sales account nodes.
-
A Named Sales Account can only have named sales accounts as ancestors.
These validation rules are enforced in the Hierarchy UI as much as possible while users select nodes to add to the hierarchy. Also, a background audit job implements these rules to ensure that all hierarchies that don't pass the validation are marked inactive.