Best Practice for Keeping Data Up-to-date?

[dbcandle]

We're looking to migrate some data to the various CSDM tables.  I'm wondering how to keep it updated?

I'm probably not in the right sub-forum, but am starting here because we really do want to make better use of CSDM.

More to the point though, what is "best practice" for keeping data up-to-date?  Our instances are global-only; no "scoped applications".  What I'd like, for a few of the CSDM tables is to:

1) Initially populate a few of the tables via import sets and transform-maps.

2) Update/create forms as needed for the tables in step 1.

3) For the tables in step 1, reference user or group tables for each record, to indicate who is responsible for keeping each row of each table in step 1 updated.

4) Send notifications (perhaps quarterly) to the users/groups in step 3, requiring that they update their data.

I'm fairly new to ServiceNow, but would appreciate any "best practices" (cookbooks?) that indicate how to do steps 1-4 above.

I'm a programmer from "way back" (late 70's), but I'm wondering where I can read-up on the best way to do the above the "ServiceNow" way!

[marcguegueniat]

Hello,

An interesting point you raise,

I would add

- Regarding imports : automate as much as you can, using Discovery and/or IntegrationHub ETL. Make sure to clearly identify/understand the unique identifier for each table (identification rule)

- Regarding ownership fields: mark them as required or recommended, so that this data will be tracked into CDMB Health dashboards

- Regarding notification : actually there is the "Data Certification" module that is available OOB and meant to handle this use case. see https://docs.servicenow.com/bundle/vancouver-servicenow-platform/page/product/data-certification/con... 

Regards,

nb: for those who aren't sure about the identification rule/CMDB Health stuff, I recommend NowLearning's CMDB courses, they really help

[spollock]

We had a few fields set as required/recommended at the table level so we could take advantage of the CMDB Health dashboards.  Fast forward to Service Graph Connectors for SCCM and Intune - SCCM and Intune did not have the fields we flagged as required and the integrations failed.  In these SGC connectors you cannot ignore the required fields for the specific connector like you can with import sets.  So, we have removed those as being required at the table level and will be modifying the views to set them as required and use the CMDB data manager policy and tasks to gather the data.  

What is the best practice here ?

[Kim Rasmussen]

Hi,

When defining restricted field one should be aware of how CI's get created. I know it sounds trivial but it is important.

I see 3 viable options.

1) remove the unmatched required fields

2) Change some of the Required field to Recommended, then you can report on them but it will not lock the import process.

3) Modify the Service Graph connector to include a "dummy"/NA type of value.

But if the fields are required for your processes. You do need to build a new process to find and assign value to the fields in question.

Hope it helps

Kim