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

[Lucky1]

Hello Nishant,

Understood.

But If I create an Attestation policy, then Tasks will be generated and assigns to the Support group that we have configured.

But I don't want tasks to be generated, and I am looking to allow support group members to attest from the list view of Configuration Items.

So, I am thinking to ask them like, what all attributes of the CI they want to attest, and for only those fields I allow them to edit by creating an ACL. Rest of other fields I will create another ACL, and make them read-only. 

And using a BR, I will populate the Attested date.

Is this ok? or Please guide me if there is any other way.

Regards,

Lucky

[Nishant8]

Hello @Lucky1 , In my view, a Certification Policy is the right choice here. You can choose exactly which attributes to certify, ensuring no other attributes are visible to the task assignee. The assignee sees only those selected attributes and can modify them during the review process, provided "Allow field update" is enabled. This gives you complete control and allows you to select different attributes for different CI classes.
While you can achieve many requirements through customization, this technical debt becomes a burden over time. Of course, you know your system best, but I wonder how you would achieve this requirement using ACLs. Which tables would you write these ACLs against? Not all attributes are available in the base cmdb_ci table. For example, RAM and CPU count belong to the Computer class. Likewise, you might have many different classes to consider.

as a follow up, do you want to restrict users from updating unintended CI attributes, or is it too time-consuming for them to review the entire CI and update only the desired attributes?

Regards,

Nishant

[Palak Gupta]

Hello @Lucky1,

I would recommend not creating an Attestation Policy for this requirement. OOB CMDB Attestation is primarily intended for periodic CI verification through attestation tasks, not for attribute-level validation or controlled field updates.

Your requirement is more aligned with attribute ownership and controlled CI data maintenance.

A better approach would be to:

• Identify the CI attributes that should be maintained by the CI’s Support Group.

• Use field-level write ACLs to allow only Support Group members to update those fields.

• Keep fields managed by Discovery or other authoritative sources read-only.

• Use the List Editor for direct updates where appropriate.

• If an audit/confirmation of the review is required, create dedicated review/verification fields rather than repurposing OOB fields such as Attested By, Attested Date, or Attestation Status.

Also, confirm the target CI table/class before implementing this. Applying ACLs directly on cmdb_ci can have a broad impact because it is a parent table for multiple CI classes. Implement the controls at the appropriate CI class level wherever possible.