locked
Multi-tier Customer Hierarchy ("Parent, Children, Grandchildren, etc.") [CRM 2011] RRS feed

  • Question

  • Suppose my company has a relationship with the Corporate Office (aka Parent Account), the Regional Office (aka Child Account), and the Service Center (aka Grandchild Account). While on the Parent Account record, I want to see the Child and Grandchild records the in the "sub-accounts" area.

    We tried this (http://blogs.msdn.com/b/crm/archive/2012/04/16/deep-queries-for-subgrids.aspx) but in the example they are "daisy-chaining" different entities, not the same entity of different positions in the hierarchy.

    Wednesday, June 19, 2013 8:16 PM

Answers

  • Not ideal, but functional.

    Add a 1:N relationship Account:Account called (something like) "Corporate Parent".

    Use workflow or plugin to update this when a new Account is created or re-parented by copying it from the parent Account record of the new one, or if parent Account has no "corporate parent" it must be the corporate office, so just copy Parent Account (I would do this all in the update record step of a workflow, with multiple items in the field update slug, like: Corporate Parent (Parent Account);Parent Account(Account)

    Expose this relationship on the left navigation above the usual "sub-Account", call it something like "All Offices", and rename Sub-Accounts" link to "Service Centres. Use a script to only show the new link for corporate offices, identified with a specific field, or simply because they are the only records with no Parent. Likewise leave sub-accounts visible only for ones which have a parent, as they must be Regions, and sub-accounts will show all their service centres anyway through this.

    So when you create a Regional Office (or link it to the corporate office parent) it will pick up the corporate parent. When you create a Service Centre it will fetch this from the Regional Office. When you look at a Corporate Office record, the "All Offices" view will show all Regional Offices and Service Centres with this one as their parent or grandparent, or great-great grandparent for that matter.

    Weakness of this method is if you re-parent a Regional Office (say) to a new Corporate Account (but why would you?), then all the grandchildren are broken. A plug-in fired on changed of "Corporate Parent" can fix this by updating all children to match (so when you reparent the Region, the usual workflow or plugin fires to change the Corporate Parent", this triggers the second plugin to update all children, their updates trigger the update for their children etc. If this is rare enough, maybe just an onDemand trigger that the user can run against all the Service Centres (sub-Accounts) for the region would be sufficient.

    This approach is probably workable for your strict three-level hierarchy, and sort-of works for deeper ones, although the whole "family" would only be visible from the top parent. To apply retrospectively, simply run onDemand against all Accounts, twice. (if you can identify the differences, run against all regions once, then against all service centres).


    Hope this helps.
    Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011
    Blog: Getting IT Right

    • Marked as answer by M. Jaxon Saturday, August 10, 2013 9:58 PM
    Monday, June 24, 2013 11:49 AM

All replies

  • Not ideal, but functional.

    Add a 1:N relationship Account:Account called (something like) "Corporate Parent".

    Use workflow or plugin to update this when a new Account is created or re-parented by copying it from the parent Account record of the new one, or if parent Account has no "corporate parent" it must be the corporate office, so just copy Parent Account (I would do this all in the update record step of a workflow, with multiple items in the field update slug, like: Corporate Parent (Parent Account);Parent Account(Account)

    Expose this relationship on the left navigation above the usual "sub-Account", call it something like "All Offices", and rename Sub-Accounts" link to "Service Centres. Use a script to only show the new link for corporate offices, identified with a specific field, or simply because they are the only records with no Parent. Likewise leave sub-accounts visible only for ones which have a parent, as they must be Regions, and sub-accounts will show all their service centres anyway through this.

    So when you create a Regional Office (or link it to the corporate office parent) it will pick up the corporate parent. When you create a Service Centre it will fetch this from the Regional Office. When you look at a Corporate Office record, the "All Offices" view will show all Regional Offices and Service Centres with this one as their parent or grandparent, or great-great grandparent for that matter.

    Weakness of this method is if you re-parent a Regional Office (say) to a new Corporate Account (but why would you?), then all the grandchildren are broken. A plug-in fired on changed of "Corporate Parent" can fix this by updating all children to match (so when you reparent the Region, the usual workflow or plugin fires to change the Corporate Parent", this triggers the second plugin to update all children, their updates trigger the update for their children etc. If this is rare enough, maybe just an onDemand trigger that the user can run against all the Service Centres (sub-Accounts) for the region would be sufficient.

    This approach is probably workable for your strict three-level hierarchy, and sort-of works for deeper ones, although the whole "family" would only be visible from the top parent. To apply retrospectively, simply run onDemand against all Accounts, twice. (if you can identify the differences, run against all regions once, then against all service centres).


    Hope this helps.
    Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011
    Blog: Getting IT Right

    • Marked as answer by M. Jaxon Saturday, August 10, 2013 9:58 PM
    Monday, June 24, 2013 11:49 AM
  • Many thanks as always, Adam.
    Saturday, August 10, 2013 9:58 PM
  • For posterity, here's a way to dynamically toggle the left-side navigation:

    http://madcomputerist.blogspot.com/2012/06/hiding-left-navigation-menu-items-in.html

    Saturday, August 10, 2013 10:00 PM