# Connections A Connection is a property of an Integration. You must have a Connection set up to allow messages to be sent and received for your Integration. The Connection stores all the authentication details of the Integration specific to a single environment. You can setup many Connections so you can easily switch between environments as necessary. ## Activation The Integration is controlled by the Connections. Making a Connection active will make it’s Integration active (and vice versa). {% hint style="info" %} Although you can have multiple Connections per Integration, only one Connection can be active for an Integration at a time. Activating a different Connection will deactivate other Connections (for the Integration). {% endhint %} ## Environment You can assign a Connection to a specific environment to make it easy to see what you are connecting to. Available environment choices are: * Production * Pre-Production * Test * Development * Sandbox ## Inbound Connectivity The Connection is the link between the ServiceNow endpoint that is receiving messages and the Integration that is used to process them. If you want to receive messages from a remote system, you must specify an Inbound user which the remote system will use to authenticate with. ## Outbound Connectivity In order for a Connection to send messages to remote systems, you must provide an Endpoint URL and the method of authentication. ### Authentication Connections support several types of authentication: Basic, Mutual and OAuth. #### Basic Basic authentication is achieved by providing a username and password. #### Mutual Mutual Authentication (MAuth) using SSL certificates is available by selecting the Mutual auth checkbox and configuring certificates on a ServiceNow Protocol Profile record. #### OAuth 2.0 You can connect using OAuth by configuring a ServiceNow OAuth Entity Profile. ### MID Server If the system you are connecting to is behind a firewall (such as an internal service) you can specify a MID Server for the integration to communicate over. ## Fields The following table is a summary of the fields to be configured for the Connection record: | Field | Type | Description | | -------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------- | | Environment | Reference | The environment this connection applies to. | | Integration | Reference | The integration this record belongs to. | | Application | Reference | The application containing this record. | | Active | Boolean | Use this connection for the integration when true. | | Description | String | Document variable usage, connection nuances etc. Used in auto documentation generation. | | Inbound user | Reference | The user profile used by the external system for authentication. An active connection must be found for the user to gain access. | | Endpoint URL | URL | The external system’s access URL. | | Authentication | String | The authentication method to use for this connection. | | User | String | The username used in basic authentication. | | Password | Password2 | The password used in basic authentication. | | OAuth profile\* | Reference | The OAuth Entity Profile to authenticate with. | | MID server | Reference | The MID server this connection will use to send messages. | | Mutual auth | Boolean | Use mutual authentication with each request sent to this connection when true. | | Protocol profile\*\* | Reference | The protocol profile to use with this connection. | {% hint style="info" %} *\*OAuth profile:* This field is visible when ‘OAuth’ has been selected as the choice from the `Authentication` field. {% endhint %} {% hint style="info" %} *\*\*Protocol profile:* This field is visible when `Mutual auth` is checked/set to ‘true’. {% endhint %} ## Connection Variables A Connection Variable is simply a key-value pair. If you have multiple connection environments (e.g. Dev, Test, Prod) - each containing different data, or information that needs to be passed between environments but changes - then use Connection Variables to provide a consistent entry point in the code. They are accessed via the `variables` object and can be used in most scripts. See the [Variables](https://docs.sharelogic.com/unifi/2.2/scripting/variables) page for details. ### Example Use Cases They can be used to define static data as variables that can change between endpoints. The following example is from the Outbound Settings for a Message: ![](https://796541950-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQBk35gIi557UHt7QlJ%2F-MT62d0uiElTSEMx1SG4%2F-MT6EOVFZBX4wAM6fZT2%2Fimage.png?alt=media\&token=e75ac2cc-0e5c-4330-8114-4a9be7ed0183) They could also be used instead of scripting data values directly into the code of Poll Processor scripts. See the following Guides for examples: * [Incident Create Poller Guide](https://docs.sharelogic.com/unifi/2.2/integration-guides/incident-create-poller-guide/polling/connection-variables) * [Incident Parent & Child Poller Guide](https://docs.sharelogic.com/unifi/2.2/integration-guides/incident-parent-and-child-poller-guide/polling/connection-variables) * [Incident Attachment Poller Guide](https://docs.sharelogic.com/unifi/2.2/integration-guides/incident-attachment-poller-guide/polling/connection-variables) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.sharelogic.com/unifi/2.2/configuration/connections.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.