Data Certification for Business Applications in CMDB

[Pranavaas]

I am looking to configure the Data Certification process for Business Applications in the CMDB and I have a few doubts:

1. For audit tracking, we need two additional fields on Business Applications:

   • Attestation/Certification Date

   • Attested/Certified By
     If these fields are read-only, what’s the best practice to ensure they are automatically updated when the certification process completes?

2. How to add approvers?
3. If I tried ceritify I am getting error - The selected records include fields without values. This task’s policy doesn’t allow certification of records with empty fields. Populate the empty fields or mark as failed. how to resolve it?

4. How can I configure or add approvers to the Data Certification process for Business Applications?

5. When I try to certify, I get the error:
   “The selected records include fields without values. This task’s policy doesn’t allow certification of records with empty fields. Populate the empty fields or mark as failed.”

   • How can this be resolved? Is there a way to configure which fields are mandatory for certification?

Has anyone implemented this before and can share best practices or recommendations?

Thanks in advance!

[Bobby Campbell · Accepted solution]

@Pranavaas we are in the midst of certifying our Business Apps as well.  I can't say we are doing it the absolute best way, but it seems to be working, so I'll share what we've done so far.

1.  We added u_certified (date field) and u_certified_by (user reference) to our Business Apps, then added a business rule that updates these whenever the person working the certification task marks a CI as Certified.  I can share details about the code if you'd like.  This helps us for reporting and accountability purposes, since we plan to have a monthly certification task, but only want to include CIs that haven't been certified in the past 12 months.

2./4. We assign the certification tasks to the Owner Group.  Then any member of that team can "pick up the task" and start working it.  However, only one person at a time can work the task.  If another person on the team wants to take over, they will need to use the Reassign button and Assign to Me.

3./5. When you set up the certification policy, there's a checkbox to allow empty values. In our case, we've chosen to not certify any fields that could be empty, so that box isn't checked.  When you choose fields to certify, those are the ones that will need to be Certified or Failed.

A couple things we learned the hard way:

Certify a specific class at a time. For example, we have 9 Principal Classes under cmdb_ci_server, e.g., Windows, Linux, ESX, etc.  We thought we were being smart by setting the certification policy on the cmdb_ci_server table. We didn't realize that each certifier requires write access on that root table.  Since we don't grant that level of higher access, no one was able to see their records to certify. To fix it, we had to set a separate policy on each specific class of servers. Not fun, but I understand the reason for it. We wasted a few hours trying to figure this out.

Some field types - list for example - can be harder to manage in certifications because they cannot be updated in list view. To make changes, the CI approver will need to go into the CI record, which takes many additional clicks and can really be inconvenient when they are working to certify hundreds or thousands of CIs.

Over communicate that you really want them to fix incorrect data rather than Fail the CI. Some of our approvers were diligent about working their certification tasks, hitting 100% rather quickly. Then we found that they were not making corrections to bad data. Instead, they were just marking the CIs as Failed. They didn't realize (and we didn't effectively communicate) that they were just creating obligations for their future selves to go through the entire list of CIs again, until they are all correct and marked Certified.

There are more things we're learning as we continue to work through this process. But I hope this helps you in some way.  Feel free to reply with additional questions.

[Pratiksha]

Why you are creating this from scratch? Why not use the oob?

Go through this : https://www.youtube.com/watch?v=j3IsnmrJU60

[Bobby Campbell · Accepted solution]

@Pranavaas we are in the midst of certifying our Business Apps as well.  I can't say we are doing it the absolute best way, but it seems to be working, so I'll share what we've done so far.

1.  We added u_certified (date field) and u_certified_by (user reference) to our Business Apps, then added a business rule that updates these whenever the person working the certification task marks a CI as Certified.  I can share details about the code if you'd like.  This helps us for reporting and accountability purposes, since we plan to have a monthly certification task, but only want to include CIs that haven't been certified in the past 12 months.

2./4. We assign the certification tasks to the Owner Group.  Then any member of that team can "pick up the task" and start working it.  However, only one person at a time can work the task.  If another person on the team wants to take over, they will need to use the Reassign button and Assign to Me.

3./5. When you set up the certification policy, there's a checkbox to allow empty values. In our case, we've chosen to not certify any fields that could be empty, so that box isn't checked.  When you choose fields to certify, those are the ones that will need to be Certified or Failed.

A couple things we learned the hard way:

Certify a specific class at a time. For example, we have 9 Principal Classes under cmdb_ci_server, e.g., Windows, Linux, ESX, etc.  We thought we were being smart by setting the certification policy on the cmdb_ci_server table. We didn't realize that each certifier requires write access on that root table.  Since we don't grant that level of higher access, no one was able to see their records to certify. To fix it, we had to set a separate policy on each specific class of servers. Not fun, but I understand the reason for it. We wasted a few hours trying to figure this out.

Some field types - list for example - can be harder to manage in certifications because they cannot be updated in list view. To make changes, the CI approver will need to go into the CI record, which takes many additional clicks and can really be inconvenient when they are working to certify hundreds or thousands of CIs.

Over communicate that you really want them to fix incorrect data rather than Fail the CI. Some of our approvers were diligent about working their certification tasks, hitting 100% rather quickly. Then we found that they were not making corrections to bad data. Instead, they were just marking the CIs as Failed. They didn't realize (and we didn't effectively communicate) that they were just creating obligations for their future selves to go through the entire list of CIs again, until they are all correct and marked Certified.

There are more things we're learning as we continue to work through this process. But I hope this helps you in some way.  Feel free to reply with additional questions.

[Pranavaas]

Hi @Bobby Campbell,

Thanks for sharing this update. The approach sounds very useful. Could you please share the script details for the Business Rule as well? That would help us understand the implementation better.

[Bobby Campbell · Accepted solution]

@Pranavaas , this BR runs before update on the sn_cmdb_ws_dm_certification_task_to_document table when the Status is Certified.  If all fields on the CI have been marked certified (i.e., none are still marked as Pending or Failed) it will update u_certified with the current date and u_certified_by with the name of the person who Certified it.  This allows us to query any class of CI by the status of u_certified. We usually want certifications once a year, so our dashboard might compare CIs where u_certified on or after 365 days ago against all Operational CIs to give us a percentage of Principal Class CIs that are Certified.

(function executeRule(current, previous /*null when async*/) {

var certTaskGr = new GlideRecord('sn_cmdb_ws_dm_certification_task_to_document');

certTaskGr.addQuery('cmdb_data_management_task', current.cmdb_data_management_task);

certTaskGr.addQuery('ci', current.ci);

certTaskGr.addEncodedQuery('statusINpending,failed');

certTaskGr.query();

if (certTaskGr.getRowCount() == 1) {

var ciGr = new GlideRecord('cmdb_ci');

if (ciGr.get(current.ci)) {

var userGr = new GlideRecord('sys_user');

if (userGr.get('user_name', current.sys_updated_by)) {

ciGr.u_certified = current.sys_updated_on;

ciGr.u_certified_by = userGr.sys_id;

ciGr.update();

}

}

}

})(current, previous);