We’ve said it in the past, we’ll say it now, and we’ll say it again in the future: good DCIM software needs to be flexible. In this blog (and video), we’ll check out some use cases that show why it’s important to have flexibility in creating custom fields as well as how they work in netTerrain DCIM.
In netTerrain, any node and link type can have unlimited custom fields. Users can assign objects or links with custom fields in the catalog — and they come in a variety of different flavors. Once they’re assigned, a user can easily see the custom fields simply by clicking on the objects in the diagram and then filling out the data. In the example below, there is an object (the building) with five custom fields in addition to the fields for name type and ID (included for any type of object).
A node (in this case, the building) has five custom fields
Any netTerrain user with catalog access can assign a new custom field: any new custom object field you create then replicates to all instances of that type. If, for example, you assigned a new custom field to a building object type, all other building types will then have that custom field as well. netTerrain is, essentially, a modeling tool that is class-based: the class would be, in this example, the building — with its properties (aka the custom fields) in addition to its behaviors, icons, and more.
Head over to the catalog and create a new custom field called “Contractor Name” for buildings.
Adding a field is simple
You can assign a default value and a font size that’s the size of the displayed field of the diagram (if select that field to be displayed). If you’d like, you may force the field to be mandatory and mark it as “displayed” — including the font and fill color.
Aside from just making a field mandatory or assigning a default value, there are a number of other attributes for custom fields you can control. You can choose whether a field is the one displayed on the hierarchy tree and also turn that into a dropdown or a combo box which can also include visual overrides. The status field, for example, is a visual override that takes two values: “OK” and “Pending”. If the value is “OK”, the building is blue. Otherwise, it’s black.
A “Pending” status is displayed as black; “OK” as blue
These overrides can propagate upwards: for example, you can make an object blink and then make the parent blink or even the parent / grandparent and all the way up to the top level.
It’s easy to make to overrides propagate upwards
In terms of list fields, you can lock it so that the only values that are acceptable are the ones specified by the power user and the list of items. You can force a field to be unique for the type or even unique for all types or, in other words, the value is unique across the entire database. There are also a number of visual cues that you can use with these custom fields when they are displayed: specification, font color, fill color, font size, and so on.
Beware of DCIM systems with hardcoded fields
If you were to now head over to the project and click on the building, the field “Contractor Name” that you added now appears: it only takes a few clicks. How many custom fields can you have? It’s unlimited! I would argue that a system does not allow or does not let you create an unlimited number of custom fields. While this may sound like an overstatement, it’s not: seriously, run for the hills.
The reason? It probably means the system has some hard-coded fields in the database, maybe named something like “Custom1” or “Custom2” and so on. Beware: this is a really bad structure. The way that netTerrain’s database structure is laid out is different: there are no hard-coded custom spaces or placeholders in any database for your custom fields. Instead, it’s meta data in a number of properly joined tables that allow for a very efficient, fast and flexible way of assigning fields.
Fields can be more than just text or combo boxes: you can also turn a field into a hyperlink. In fact, these are hyperlinks. You may turn a field into an IP address: so when you click on the IP address, perhaps you can ping the object or telnet it and the system will automatically parse any field that is an IP address and provide the options that an admin laid out for how IP fields should behave: remote desktop, trace route, and so on.
Turn a field into an IP address & click to ping or telnet the object
As you can see, there are many different types of fields that you can define and you really have a lot of flexibility in terms of how you can make them behave. You can turn them into visual overrides that make the objects change color or shape based on the values that those fields take and there are also special fields such as hyperlinks and IP addresses that can be easily configured in the system.
In sum, it’s likely that, when using DCIM software, you’ll need the ability to create custom fields. If you are test-driving a software that offers just a few custom fields, watch your step. Not only will you end up without the ability to create the custom fields you need, you’ll probably end up purchasing DCIM software that hasn’t really been designed to give its users the flexibility they need to ensure the tool doesn’t get in the way of the task at hand.