ServiceNow¶
Clarity Transform reads Business Applications and Application Services from the ServiceNow CMDB, so an existing application catalogue is used as a starting point rather than rebuilt from scratch.
Where to find it¶
Go to Discover → Integrations, then select the ServiceNow card. The card's category label is SaaS. The integration's page has the Endpoints and History tabs; Integrations describes the page, its grid and its row actions.
Why we do this¶
Where a customer runs ServiceNow, an application catalogue already exists and somebody has already done the work of naming things. Ignoring it and inferring a fresh set of applications from traffic produces a second, differently named portfolio that nobody recognises, and the reconciliation afterwards is worse than the discovery.
That matters more for adoption than for accuracy: an application map on Discover → Application Mapping labelled with the customer's own application names gets reviewed, and one labelled with inferred names does not.
What we collect¶
- Business Applications from the CMDB
- Application Services, and their relationship to those applications
Read-only against the CMDB tables. Nothing is written back, so a Clarity finding never modifies the customer's own catalogue.
What it adds¶
Names and ownership, which discovery cannot produce.
It is a starting point, not an answer
A ServiceNow catalogue is frequently incomplete or out of date, and the gap between it and what discovery finds is itself a useful output: applications in the CMDB with no running infrastructure, and running infrastructure that belongs to no recorded application.
What is deliberately not inferred¶
- Nothing is written to ServiceNow. Clarity does not create, update or close any record.
- No incidents, changes, requests or knowledge articles. The CMDB application tables only.
- Precedence between the catalogue and discovery is not fixed. It is governed by each integration's Integration Priority (the merge priority), shown in the Table view of Integrations: higher numbers win when several integrations populate the same CMDB fields, and a change applies to future runs.
- No dependency is inferred from a CMDB relationship alone unless it is corroborated by discovered evidence.
What we require¶
A ServiceNow user with read access to the CMDB application tables and permission to use the Table API. No write access of any kind is needed.
- Interface: the ServiceNow Table REST API
- Connectivity: HTTPS on TCP 443 from Clarity to the instance
- Account: a dedicated integration user, restricted to read on the CMDB tables in scope
A dedicated user rather than a personal or shared one, so the access is trivial to revoke at the end of the engagement and the audit trail in ServiceNow stays readable.
Verification before handover¶
- Confirm the account can call the Table API. Request one record from a CMDB application table as the account. Some instances grant table read through a role but withhold API access separately, and that gap presents as an authentication-shaped failure rather than a permission one.
- Confirm the rows returned are the rows expected. ServiceNow access controls can filter rows rather than refuse the table, so a successful read of a subset looks identical to a successful read of everything. Compare the count against what an administrator sees.
Configuring the endpoint¶
On the integration's Endpoints tab, select the add icon (Create New Integration Endpoints). The Create new entry form opens with these fields, in this order:
| Field | Value |
|---|---|
| Name | A name for the endpoint |
| End Point | The ServiceNow instance address |
| Credential | The stored credential for the integration user |
| Job Schedule | A five-field cron expression, for example 0 2 * * 0 (weekly). A CMDB catalogue changes on a change-management cadence, not continuously |
| Enabled | Ticked. The box is unticked when the form opens |
The help texts: End Point "FQDN or IP Address of management system for technology e.g. vCenter, Nutanix Prism"; Credential "Credentials can be configured under Settings/Identity and Access Management/Credentials."; Job Schedule "Cron schedule – Use five fields: 〈mm〉 〈hh〉 〈day-of-month〉 〈month〉 〈weekday〉".
The Credential list offers the credentials stored under Settings → Identity & Access Management → Credentials, so create the credential there first.
No field is marked as required. Technology is set by the card and is hidden in the form. Select Save to create the endpoint, or Cancel to close the form. The edit icon opens the same fields as Edit entry.
Removing the access¶
Deactivate the integration user in ServiceNow. Then, in Clarity, remove the endpoint (select its row on the Endpoints tab, then Remove selected) or clear its Enabled box, and remove the credential under Settings → Identity & Access Management → Credentials. Nothing was written, so there is nothing to undo in the customer's CMDB.
Troubleshooting¶
| Symptom | Cause |
|---|---|
| Authentication appears to fail although the credential is correct | API access is granted separately from table read on some instances. Test the Table API specifically rather than the portal login. |
| Fewer applications than expected | An access control is filtering rows rather than refusing the table. Compare the count against an administrator's view. |