Sometime between Fuji and Madrid, probably closer to Fuji, ServiceNow quietly changed how the Dictionary Entries were populated in the CMDB, introducing the concept of "cloned descendant elements". With cloned descendant elements, there are distinct dictionary entries but only the root dictionary entry is editable. However, as far as I can tell this pattern only exists in the CMDB. In other parts of the platform, attributes are implicitly inherited by subclasses without the cloned descendant elements being created. Some may not be aware of this, because when displaying the Table Column formatter in the Table form, it looks the same. All of the columns are visible on a subclass, whether derived from the parent class or added in the subclass. But you will notice the behavior is very different.
For example, if you open a table form for a CI class like cmdb_ci_server and click on the install_status (Status) column entry, it will take you to a page where the familiar message is displayed at the top of the form: This cloned descendant element is read-only, Click here to open editable first element (cmdb.install_status) in a new window.
On the other hand, if you go to the alm_hardware table form and click on install_status (State) column entry, you won't get this message. Instead, it opens up the root element which exists on the Asset (alm_asset) table. In both cases, the attribute is inherited by the subclass. But for the attribute on the CI class there is a cloned descendant element, i.e. a duplicate, non-editable dictionary entry.
The question I have about this is simple: when did this happen exactly, and why was it done? There do not seem to be any practical differences, just two different patterns, one in which the attributes are explicitly inherited, and the other in which the attributes are implicitly inherited. Dictionary overrides work the same regardless. I've always assumed the reason for this was for performance, such as with the Show Related Fields option in the Filters/Conditions, that having these attributes as ready-to-query Dictionary Entries was more performant in a large hierarchical data model like the CMDB than traversing the class hierarchy on the fly to enumerate all of the possible fields available on a class. But I'm not sure if this is the reason or if there are other considerations.
While it might seem like an unimportant question, it has impact both to the usability and intuitiveness of the platform and to any development that deals with the data model itself. I'm hoping someone out there has the context for this, as I haven't found any documentation on this design, and have often found that even very experienced ServiceNow administrators and developers aren't actually aware of the existence of this odd quirk in the ServiceNow data model.
