Is there any doc about the required fields that each class of CI must have as best practice?

[Jose Santos Alv]

I wanna make sure that I am setting up the correct required fields for each CMDB Class but I would like to know too if there are some best practices about this

[EricDohr]

I am not aware of an official document, but here are a few recommendations that came to my mind that may help out

Start with what you know

Use the dictionary table to filter by mandatory and CI tables to see what is required out of the box.

Why does it matter

Start with this question.  Why does it matter that this field is required?  Who do I expect to populate the field, and do they know why and how?  If you can tell a story such as "This field is important as the Incident process uses this group field to help with the automatic assignment of incidents when a CI is picked," it drives adoption more than "this is an important field."

Involve the right people

This is where it becomes vital to have Class owners that can review the needs of a required field.  When you get into CSDM, there are specific tables where you have multiple processes utilizing records, which increases the need for alignment across teams. 

Data Governance

Use the CMDB Health Dashboard to your benefit to quantify quality with required and recommended fields.  Potentially start with what is out of the box and fields you are considering being required to be listed as recommended as part of your CMDB Health.  This approach should give you value from a governance standpoint to know how many records are considered quality.  In addition, it may help you find out where there could be challenges that may be overcome with OCM

Just because a field should be required on one table does not mean it should be necessary on parent tables

In one consultation, I found that many required fields were set at the cmdb_ci table level.  This finding impacted certain automation and scripts as the record could not be created because the required fields were not populated as part of the script.

Right size – use the platform

What may be a required field in certain scenarios may not be a required field in all scenarios.  For example, depending on the lifecycle of a CI, you may not know all things.  Consider using functionality such as business rules to enforce required fields at the right time.

What fields are to be populated because of discovery versus manually maintained

Look at how the fields are populated and the process.  If you know a field will most likely be populated via discovery, is there value in making it required?

Make sure your decisions are reflected in form updates

Make sure if you do decide a field is required, that you update your list layout and views so end users / data managers can easily access that information.  If you make a field required but fail to add it to a form, this will lead to challenges.