Forum Stats

  • 3,734,348 Users
  • 2,246,954 Discussions


Multilevel Hierarchical Value Lists using Service Cloud

How do we build and use multi level Hierarchical Value Lists in OPA using Service Cloud object so that selections can be controlled based on parent child relationship?

eg:- If we have 2 lists in Service Cloud



How do we ensure when the Country selected is US, only valid US states are available in the state attribute to be picked. I want to avoid having to control that using visibility conditions in values under drop down?


  • Richard Napier
    Richard Napier Member Posts: 208 Silver Badge


    The metadata received from Service Cloud imposes certain restrictions based on the way the connector handles data types and considers a value list name as a data type. Perhaps something like this would be an option

    1) Export Country and State standard value lists

    2) Edit the XML files to change the names of both lists, and add the child-value-list setting to the Country XML file, and add the relevant values of the states for the parent "US" and the other countries. I appreciate that this might be an onerous task.

    3) Reimport them both into OPM, now you have a two-level hierarchical list identical to the ones coming in from Service Cloud just with different names. Of course your new lists are no longer connected to Service Cloud and will need to be maintained manually

    4) Set up separate attributes to hold the mapped in value, the mapped out value and manually entered values, using the standard value list for the input and output mapped and your value lists for the manually entered values. The data that is sent back to Service Cloud will still need to be mapped to the standard State and Country lists otherwise you will get a Type error due to the metadata on the value list name not being the expected Service Cloud value list.

    5) Set the default values of the two manually entered ones to be the same as the inbound values and add logic so that the outbound value is either the manually selected one (if the value has changed) or the inbound one (no change).

    So in the case in the image below (not all fields should be shown to the user of course)

    Country was mapped in from Service Cloud and mapped out with no change in this case.

    Value mapped in was Kentucky from Service Cloud into the "inbound state" attribute that uses the standard value list . Mapped out attribute value is Hawaii (again mapped to the standard value list) because that is the new value chosen by the user (from your hierarchical list of states in the US). A Word rule or table can copy the value over. The manually chosen state attribute is mapped to your new hierarchical state list, and you would have the same setup for the Country.

    So the two controls highlighted in red are the ones you display to the user, the green are the mapped in and the yellow the mapped out. Six attributes instead of 2.

    That way you can continue to use the standard Value Lists but leverage your hierarchical ones for the UX. This does have drawbacks as I said - the new hierarchcal lists are no longer updated by Service Cloud, you need to keep your hierarchies in sync and so on but it might work.

    Perhaps someone will come up with a better idea, in which case I am all ears!

    Hope that helps


Sign In or Register to comment.