Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field
| There is a newer version available for this content: "Instance Scan data model (San Diego)" |
Hi there,
Keen on getting started with Instance Scan? Adding some configuration or doing some customization, doing some automation, etcetera. Great! What might help you a bit on this… having a nice overview of the data model involved with Instance Scan.
In this article I'll update the data model which I shared six months ago which was based on the Quebec release. This article is based on the Rome release!
Data Model
Let's immediately look at the big picture. Here is the Instance Scan data model for the Rome release:
When looking at the out-of-the-box Application Menu, you might think Instance Scan doesn't involve so much. Though looking at this picture, it does. And I didn't even mention everything!
Rome release
No major changes were done on Instance Scan with the Rome release. Most noticeable: the addition of Reactive scanning. Reactive scanning is also the only factor that made the data model change a bit:
- Table "Scan Trigger" [scan_trigger] added.
- Field "Triggers" added to existing table "Suite check" [triggers].
Additional explanation
Additional explanation on this picture:
- I left out system generated fields like "Created", "Created by", "Updated", "Updated by", "Updates". These are mentioned with "…". "Sys ID" I did mention.
- I left out fields inherited from the extended table mentioned. These are mentioned with "...".
- The fields colored green are references to other Instance Scan tables.
- Fields colored blue are references to non-Instance Scan tables like "Application File", "Package", "Scheduled Job", "User", or are of field type Document ID and could theoretically reference any table. I left these tables out of the picture.
"I've got more tables on my instance!"
That could be right! You could have more tables (and fields) on your instance. This is due to if your instance has been upgraded from Orlando/Paris, or that you are on a fresh Rome Patch 1 instance. For example, if you upgraded from a Paris instance, you would also have a table "Check Attributes".
The picture of the data model is based on Rome Patch 1.
"What about the red marked fields in the picture?"
In red, fields (and also one table) which are not visible on any list lay-out or form layout, and are undocumented. In one case ("Scorecard")… even has a read Access Control for role "maint"! Undocumented meaning no official ServiceNow documentation, when searching for the undocumented you might find some of my other Instance Scan articles 😀.
---
And that's it actually. Hope you like it. If any questions or remarks, let me know!
| C |
If this content helped you, I would appreciate it if you hit bookmark or mark it as helpful.
Interested in more Articles, Blogs, Videos, Podcasts, Share projects I shared/participated in? |
Kind regards,
Mark Roethof
ServiceNow Technical Platform Architect @ Quint Technology
2x ServiceNow Developer MVP
2x ServiceNow Community MVP
---
.png){kind=link}