Account Hierarchies

Author(s): Devon Sparks, Trimble Distinguished Engineer

Peer Reviewers(s):

• Bryce Stout, Director of Product, Customer Digital Experience
• Gokul Somasundaram, Engineering Director, DX
• John Platt, Salesforce Data Architect Director
• Paul Sexton, Sr. Dir. of Engineering, Trimble Distinguished Engineer
• Sivakumar Soundarapandian, Trimble Distinguished Engineer

Last Reviewed: May 2024

The Platform Organization set an organizational commitment in 2024 to define Trimble’s account structure, implement this structure in Core Services, and drive its adoption within AXP. This has been reinforced by the ongoing Account Data Strategy Initiative, officially supported by the Trimble Engineering Board.

To accelerate progress, key Account data domain subject matter experts and leaders organized in April 2024 around two “key design decisions” (KDDs) related to the general topic of “account hierarchies.” Two rose to the surface, recognizing that what stakeholders (typically Salesforce or Oracle) often call an “account” is at least two distinct concepts:

1. The first KDD related to the legal “ownership” hierarchy of Organizations - the formal business structures that define the “B” in B2B relationships.

   Problem Statement Business organizations tend to be structured as hierarchies (e.g., Tekla is owned by Trimble EU, is owned by Trimble, Inc.) These ownership hierarchies may be used for (Sales/CX) Account Management, Account Based Marketing, analytics and lead prospecting.

   KDD 1 What Organization ownership hierarchy, if any, is useful to expose within Trimble services?

2. The second KDD is related to a specific hierarchy of Accounts, where Accounts are containers for transactions (sales motions, entitlements, product provisioning, etc).

   Problem Statement Accounts are “containers for transactions”. Individuals and businesses can - and do - have more than one Trimble Account. Their entitlements, orders, and workflows may be separated across these accounts, which can create confusion as they work within Trimble products.

   KDD 2 What Account containment hierarchy, if any, is useful to expose within Trimble services?

After collating and evaluating all options (see sources for KDD 1 and KDD 2), the team arrived at the following decisions:

1. KDD 1: Organizations will be formally modeled as fixed, three-level depth ownership hierarchies (Site, Domestic Ultimate, Global Ultimate). This ensures stronger data integrity and predictability by standardizing the shape and semantics of the organizational hierarchy and supports efficient enrichment of organizational data from third party sources that use the same model (Dun & Bradstreet, Leadspace, Zoominfo).

2. KDD 2: Accounts may be organized into a hierarchy of containment, where any assets held by a child account are accessible to the parent account. This solution solves several problems related to customer-driven account management at once and provides a simple approach for account merging.

In short, alignment on these two decisions significantly improves Trimble’s readiness to tackle account data quality exercises such as deduplication, which are necessary for us to improve our goals of building better ‘Customer 360s’.

The outcomes of these KDDs will now be used to drive technical execution delivery:

1. The IAM Platform team will implement these KDDs in the go-forward Trimble Account service.
2. The DX Platform team will ensure any missing account attribute data hosted in DX Salesforce is required to support these KDDs in Platform systems (e.g., Organizational Domestic Ultimate and Global Ultimate) and are added to the DX middleware layers.
3. These KDDs have been incorporated into a simple utility (video and repository) that will be used by the IAM product team to validate the business logic and usage patterns of accounts within Trimble. This utility was not developed to address enterprise non-functional requirements; the production-grade solution may use different technology choices.