Set CMDB fields updated by Discovery to read-only.

[Patricia9]

I have the following requirement for all cmdb_ci records, including child tables: all fields updated by Discovery should be set to read-only. We want this to avoid users editing fields that are updated by Discovery.

Example: If the Disk Size of a Server is updated by Discovery, the Disk Size should not be editable by any user.

However, there are some cases where the disk size is updated by a user, possibly because Discovery could not retrieve this information. In these cases, the Disk Size should remain editable. This means that I don't have a specific list of fields, it depends on the record.
 

Current Solution: The only solution I have found so far involves the following steps:

• Using History/Audit data to identify the last user who updated the field.
• A Client script on load sets the field read-only if the field was updated by Discovery.
• Additionally, I have implemented a business rule to mirror the client script functionality on the server side.

I would like to know if there are any other approaches to achieve the same result. Most of our principal CMDB classes are already audited, but I will need to maintain this configuration to extend this to additional tables in the future.

Thank you!

[Selva Arun]

Hi @Patricia9 ,

In our organization, we have used Access Control Lists (ACLs) to restrict write access to fields or tables. Write permissions are granted only to admins, support group members, and CMDB Governance members. For the ITIL role, users are granted both read and write access, but for fields that need to be read-only, we implement scripts to control write access.

For making fields read-only across different tables, we often manage this at the sys dictionary level, where we can set the fields as read-only without needing client scripts or business rules. If you're interested in extending this approach to more fields in the future, you could use the same model.

You can refer to the ServiceNow knowledge article on ACLs and field-level access for more details: https://docs.servicenow.com/bundle/rome-servicenow-platform/page/administer/security/concept/c_Acces...

If you believe the solution provided has adequately addressed your query, could you please **mark it as 'Helpful'** and **'Accept it as a Solution'**? This will help other community members who might have the same question find the answer more easily.

Thank you for your consideration.

Selva Arun