Note: Nintex Apps data centers are located in West US and Australia (AUS). In-region processing of Nintex Apps data is only available in these regions.

Authentication Providers and Connections

Create an Authentication Provider

If Nintex Apps must cross a bridge to get to the data it needs, then an authentication provider is its access card once it gets there. Because of this, creating a connection to an external system often starts with configuring an authentication provider. Creating an authentication provider typically involves tweaking a few properties relevant to your service, but the steps are usually the same.

In the Nintex Apps UI

1. Navigate to Configure > Connections > Authentication Providers.
2. Click fa-plus-circle New Authentication Provider.
3. Fill out the necessary fields for your external system. These are detailed in each connector's topic.
4. Click Save.
5. If using Nintex Apps for Salesforce, click OK if asked to create a Remote Site Setting.

Note:  Most connector topics will include instructions on how to create authentication providers that connect to the system using the OAuth 2.0 protocol, but this is not the only way to authenticate to your systems. If you are an advanced builder and wish to learn more, see Authentication.

Create a Connection

Pre-configured connectors

Each pre-configured connector features a configuration wizard tailored to that connection's unique requirements. Nintex Apps handles much of the heavy lifting—figuring out fields and easily determining permissions scopes—wherever it can. But there are some common steps.

In the Nintex Apps UI

1. Navigate to Configure > Connections > Connections.
2. Click fa-plus-circle New Connection.
3. Select the appropriate connector.
4. Name the connection, preferably something unique and easily identifiable.
5. Click Next Step.

After these initial steps, the specific configuration properties will vary per connector. Refer to the documentation regarding the specific connector you wish to use for more information.

REST and OData

In contrast to pre-configured connectors, which do a lot of the "talking" for Nintex Apps, the REST and OData connectors require much more configuration at the page level. For information, see the REST and OData topics.

Default Conditions

You may notice that some connections will automatically generate one or more model conditions when created. Nintex Apps does this to account for necessary values needed to access certain connections, such as ID fields. These default model conditions will vary from connection to connection.

Many of these default conditions have standard uses within their respective connections—often saving you the need to create the condition yourself. Certain connections allow you to delete these default conditions, however others will not; this protects the model's functionality.

Connector actions

Nintex Apps's pre-configured connectors may also incorporate specific functionality from their respective services. These connector actions simplify complex external data requests into a declarative option within action flows.

To utilize a connector action within a Nintex Apps page:

1. Create an action (row, global, mass, model action, etc.).
2. Set its Action Type to Run Multiple Actions.
3. Give it an appropriate Action Label.
4. Click the Actions tab.
5. Click the + button to add a new action.
6. Set the Action Type to Run Connector action.
7. For Connection, select one of your configured Nintex Apps connections
8. From the picklist, select a specific connector action for your particular connection.

For more information on how to use connector actions, see the relevant sections within each connector topic or the Action Framework topic.

Additional Concepts

To gain a fuller understanding of how connected to external data works, and the moving pieces within it, read these conceptual, introductory articles:

• Authentication
• callback-urls-redirect-uris

Proxy Configuration

Using the Proxy

Important:  Due to security reasons, most systems expect external requests to be sent through a proxy as opposed to direct connections. Because of this, using the proxy is recommended for most connections. Many external systems will actually return errors if they receive a request over direct connection. Unless you are certain that the external system you are accessing accepts direct connections, use the proxy.

When setting up a new connection, you can choose whether or not to use the Proxy, whether that be Nintex Apps's own proxy within Nintex Apps or the Apex Proxy within Nintex Apps for Salesforce.

When using the proxy, any requests sent from the web browser (or client) to your service will first go through another server, and then on to your service. From the perspective of your service, requests will be coming from—and going back to—either the proxy servers used by Nintex Apps or servers in Salesforce's data center. Once these servers receive the services' response, they will relay the response back to the client. To visualize this process:

Benefits of using the Proxy

1. Storing Credentials Securely: Nintex Apps can keep all credentials needed for authentication on the Server, and never send them to the Client where they could possibly be stolen or otherwise compromised through an XSS attack other issue.
2. HTTP Connections Allowed and No Problems with Same Origin Policy: All requests go through Nintex Apps's proxy servers or Salesforce. This means that, from the perspective of the web browser (client), responses from the service are coming from the same domain that the page was served from. For browsers that enforce a "Same Origin Policy," using the proxy meets the requirements of this policy. Because of this, services that provide data over HTTP (instead of HTTPS) or from different domains will work without any additional configuration.

Drawbacks of using the Proxy

1. Services must be accessible to Proxy Servers: Since requests come from a server besides the end user's current network, services behind a firewall will be inaccessible using the proxy. This means that services must (in some way) be open to the public internet. IP restrictions and authentication can still allow these services to be locked down, but they cannot be behind a firewall.

2. Subject to Apex and Salesforce Limits: Because all data that your service returns must pass through Apex, it is subject to Salesforce limits (such as the Apex Heap Size). Payloads of sizes close to (or over) 6MB will fail because of these limitations. To resolve, you must uncheck Use Proxy but note that doing so poses a security risk.

   Note:  This drawback does not apply on Nintex Apps.

Making a direct client connection (No Proxy)

Alternatively, Nintex Apps connections can be set up to make a direct connection from your end user's browser straight to the service. This means that you can set up a connection to services that are inside of an internal network and behind a firewall. As long as your user is on a network connection (usually a VPN) that is on the same network, they can access the service directly. The data never goes to the public cloud.

Benefits of Making a Direct Connection

1. Speed: Direct connections to services do not require the extra step of a proxy. Combined with the fact that the services are usually on the same network as the client, they can be very fast.

2. No Apex Limits: Pull in large payloads without running into any Salesforce limits.

   Note:  This does not apply on Nintex Apps.

3. Make connections behind a firewall: Data from these services never go out to the public cloud.

Drawbacks of Making a Direct Connection

1. Credentials must be sent to the client: Because the end user's web browser is actually making the connection to your connection, it must have the credentials to make the request. This means that credentials are stored in memory in the user's browser and vulnerable to various attacks.
2. HTTPS connections are required: Browsers that serve pages over HTTPS require any connections made from that page to be HTTPS as well.
3. Same Origin Policy Restrictions: Because of the "Same Origin Policy," services accessed directly from the browser must return an "Access-Control-Allow-Origin" (CORS) header that allows requests to be made from a page served from a Nintex Apps or Salesforce domain.

Troubleshooting