Introduction to credentials, connections, and aliases

All application integrations in ServiceNow require connection information, credentials, and aliases to their respective applications to access resources.

Before you can execute an application integration in ServiceNow, you must create and configure the corresponding connection information and credentials.
A connection is an integration with a system, such as an IP address or endpoint with protocols. It contains specific details, such as database particulars, when integrating with a database.
The credential is the authentication data required to make the connection.
Connection information and credentials can vary between QA/Development/Production environments for the same integration. The tight coupling between this data and application metadata, such as workflow or job scheduling, make application metadata obsolete when you change environments. An alias alleviates this problem, for connections and credentials, by decoupling this data from application metadata.
Connection and Credential Alias
This alias associates a credential to a connection, which resolves during runtime.
Credential Alias
This alias associates to credential data only, and resolves during runtime.
In addition to the alias data model, you can also use a scriptable API which can get connection and credential data during runtime. Additionally, there are business rules that enforce certain constraints on these aliases. Names should contain alphabets, numbers, and underscores but cannot have special characters. The alias must be unique in a scope. If you have multiple active connections, you can have more than one active connection in the same domain. If you do not choose this option, you can have only one active connection in per domain.
Note: If you enable multiple active connections, when the connection records resolve, your application picks one connection based on an established order. The order of the connections depends on the API you use to retrieve connection data.
You can add additional connection attributes to an alias, which are available in connection data during runtime. Variables overridden by connection administration during run time should not affect the alias.

Benefits to using Connections, Credentials, and Aliases

  • Central location to store and manage credentials to an external service
  • Define once and reuse for multiple platform features
  • Minimize configuration of other platform features
  • Allow non-administrators to use predefined connections and credentials
  • Increased security

Features using Connections, Credentials, and Aliases

  • Cloud Management
  • Discovery
  • Flow Designer
  • IntegrationHub
  • Orchestration
  • Service Mapping

Upgrading credential tags

In the Kingston release, the upgrade process migrates credential tags to credential aliases. All credential tags in the Credentials table have a corresponding credential alias, made of:
  • Name: alias name
  • Scope: global
  • ID: alias name
The credential tag field type changes from string to GlideList in the Credential table and the credential alias field refers to the created alias records.

Credential synchronization with MID Servers

Each MID server on your network synchronizes with your instance keeps what is essentially a copy of every credential that you create. This synchronization is done to speed up the reading of credentials when applications like Discovery or Service Mapping need to access multiple devices on the network. The MID Servers synch when they find a credentials_reload job in the ECC Queue. The reload job instructs the MID Server to make a SOAP call to the instance to get the entire list of credentials, including all the field values, in the Credentials [discovery_credentials] table.

The SOAP response that your instance sends to each MID Server also includes custom fields that you added to any credential form that you customized. If you added reference fields, the data in the referenced table is also sent as part of the SOAP response.