CMDB Attestation fields Question

[Lucky1]

Hello all,

On the Configuration Items (cmdb_ci) list view, I see these fields:
Attestation Status,

Attributes,

Attested,

Attested by,

Attested date.

So, I want to allow only Support group of the CI to attest few fields but not all.

So, can someone tell me how these above-mentioned fields will work and what action to be taken if only support group has to attest few attributes.

Regards,

Lucky

[Rafael Batistot]

Hi @Lucky1 

May you use Certification Schedules:

Go to Data Certification > Schedule Definition > Schedules.

Set the target CI table and select only the specific attributes you want verified.

Set Assign to field to ⁠support_group⁠. When the task is completed, ServiceNow automatically updates the attestation fields.

https://www.servicenow.com/docs/r/zurich/servicenow-platform/configuration-management-database-cmdb/...

[Lucky1]

Hello Rafael,

Thanks for your response.

Actually, I am looking for Attestation but not Certification.

Secondly, I don't see the module 'Data Certification'.

So, can you let me know how I can do?

I am thinking of creating ACLs on this fields, but Not understanding if the user select the Attestation Status as Attested, then what Attributes the user Attested and how the Attested Date will populate.

Regards,

Lucky

[lpruit2]

Greetings . Wishing you the best in your Attestation efforts. 

I understand you are less interested in having tasks created for your Attestation exercise and want the attesters to manually update the out-of-the-box Attestation fields in list-view. In my opinion, this actually reads more like a combination of reinventing the wheel in addition to being more complicated than the out-of-the-box CMDB Workspace experience. 

Some issues with updating the target records from list-view:

1. You will have to solve for your ACL issues instead of relying what is out-of-the-box

2. Do you know WHO will be expected to Attest the target records?

3. There is no clear start and stop periods for performing Attestation. You have one target table and are expecting a group of people to work through all the records without having any clear deadline. 

4. There will be a significant recurring manual effort in between Attestation exercises. Best case scenario, you will have a high response rate to the FIRST Attestation exercise, then you will have to go into the Target record and manually flip all the Attestation Status value from Attested/Rejected back to Not Reviewed so they can be Attested again for the next cycle. 

Why I recommend using the CMDB Workspace / Service Graph Workspace:

1. You build one Data Management policy for Attestation 

2. You scope out the exact records you wish to Attest

3. You pick which User or Group you wish these Attestation tasks are assigned to

4. You can set a consistent Due Date to improve process expectations in additional to Service Level Agreement (SLA) if you desire.

5. It's much easier to trigger Notifications that will provide meaningful information to the assignees

6. You don't have to manually update the Attestation Status on the target records as that is handled out of the box

7. You can better track Target records that are receiving no response in addition to records that have been Rejected

8. When a record has been Rejected, you can build additional logic on how to handle post-Attestation-rejection 

[Nishant8]

Hello @Lucky1 ,  Fields to be verified are selected during a Data Certification policy. In contrast, an Attestation policy applies to the entire CI, where the attester simply verifies the existence of the complete item instead of attest only a few attributes.

Attestation Status - Attested

Attested - false/true (I've noticed that this field remains false even if a CI is attested and task is completed)

Attested by - Attester (Assignee of the task)

Attested date - When the CI is attested

Attributes - This is not related to policy. I think, this was used for storing the large data/information

Regards,

Nishant