Connection templates allow you to pre-populate input values for common connections used by you and your customers. For example, you can create an OAuth 2.0 connection template for Salesforce that pre-populate your OAuth client ID and client secret. When you (or your customers in embedded designer) create a Salesforce connection, they can select your Salesforce connection template and will not need to set up a client ID and secret themselves.

We're proud to introduce a new instance configuration option - User-Level Configuration (ULC).

What is ULC? ULC helps when multiple users of a single customer all need an integration. It allows you to configure a single instance of an integration for a customer, but collect configuration from multiple users and execute using user-specific configuration.

Why use ULC? ULC is handy if your integration requires user-specific config variables and credentials. For example, suppose your app needs to write data to several users' private Dropbox folders. With ULC, you can collect connection information for several users within a customer, and integrate with each of their individual Dropbox accounts.

How does ULC work? At a high level, a single instance of an integration is deployed to a customer, and is configured with some customer-wide config variables. Individual users within the customer, then, go through a ULC config wizard and supply user-specific credentials and config variables. When the instance runs, it pulls in user-specific configuration depending on some rules you set.

Read more about ULC in our docs.

We've revamped the way that components connect to third-party apps and services. The new concept is called connections, and they make authentication simpler, more flexible, and easier to support.

We'll be updating our built-in components to use connections in the coming weeks, and credentials will eventually be phased out in favor of connections (but don't worry - credentials won't be sunset immediately!).

For a full run-down how connections improve integration development and support and customer self-deployment, check out our blog announcement. Here's a quick summary:

• Component developers have more flexibility when declaring what information their components need to connect to a third party. They can define custom connections that include any number of fields, like username, password, API key, tenant ID, endpoint URL or other fields that are unique to the service they're integrating with.
• The OAuth 2.0 flow got much simpler and cleaner for both integration builders and customers who deploy the integration - customers see a single button to click when they need to authenticate with OAuth.
• Authorization got simpler in general - connections live within the integration designer or a deployed instance. You don't need to create credentials from the organization or customer settings pages, nor juggle credential types. Components know what connections they're compatible with, and can only be paired with those connection config variables.
• Connections are easier to support. You can now configure alert monitors to notify you when connections (OAuth or otherwise) expire or fail to authenticate in an integration.

You can now configure authorization settings per action (as opposed to per component). This is helpful if you are building a component with multiple actions and only some of your actions require authorization.

Read about how to upgrade your component to use per-action authorization on our Spectral 3.x Upgrade Guide.