Idea ID: 2762969

Make Complex_Type usable in write/read as an Object/entity

Status : Declined
over 1 year ago

Hi Team,

We've been trying to use Complex_type CPUS in DEVICE to write/read but unless we force all the JSON object in the field, there is no way we can write in these fields using BR

The idea is to handle these fields as objects in write and read mode:

entity.cpus.<element rank>.CPU_Clock_Speed='4.2'



  • While the specific use case described in the initial post is indeed not aligned with the strategic direction of native SACM (federation with UCMDB), there are numerous other reasons why it should be possible to access individual elements of complex structure fields.

    Other use cases not conflicting with native SACM include:

    • Business rule conditions based on complex field properties.
      E.g. only execute a rule if a server has at least one IPv4 address, or less than 4 CPUs.
    • Use the value of a specific complex field property as a data source for an action rule.
      E.g. send a notification that includes the Authorative DNS name matching the first IPv4 address of a server, or use an IP Address in an automated OO task.


    As of now, the only complex field that is known to be readable is the comments field, and even in that case, there is no documentation about the list of available fields. The only way to figure out what can be done is by looking through standard business rules and see what is done there, or by using the Browser's debug feature (F12 key) to analyze the data being transmitted in a UI session.

    As of now, complex property fields like CPUs, IpAddresses, etc. are just a cosmetic feature, solely limited to presenting some data in the UI, and unless the customer implements UCMDB and native SACM, the data has to be entered manually, which is so cumbersome that hardly anyone will ever want to do that.

    There is no way to use that data in integrations, nor in business rule. So, why would anyone even care using those fields?

    Sorry for the tone of this post, but your expedited decline has been very frustrating to me.


  • In the (near) future these complex attributes of CIs will be federated from UCMDB.  This request does not seem to be aligned with this approach, so I am going to decline this Idea.  If you think this is still valid feel free to reach out to me to discuss or add more comments here.