Integrations & Templates2 illustrations

Connections and Credentials

Authorize external services once, reuse them across every workflow, and keep the secrets out of the canvas.

These images are illustrations of the concept, not screenshots of the actual product.

Overview

Connections and Credentials covers how FluidGrids holds the keys to the outside world. Every connector node — posting a message, creating a contact, reading a payment — needs an authorized link to a service. The concept keeps those links as workspace-level records rather than node-level settings, so a service is authorized once and then selected by name wherever it is needed.

That separation solves several problems at the same time. Secrets stop being copied into workflow definitions, which means a workflow can be duplicated, exported or shared without carrying an access token with it. Rotation becomes a single edit instead of a hunt through every graph. And expiry stops being invisible: instead of a run failing deep inside a node, the connection itself shows as expired with a reconnect action next to it.

The two illustrations show the pair of surfaces this needs. The first is the workspace inventory: a table of authorized services with the provider, whether it uses delegated authorization or a key, which account or environment it points at, a connection status and when it was last used, sorted by most recent use so the least recently touched settle at the foot of the list for review. One sample row is marked expired and offers a reconnect link, and a standing note at the foot restates the rule that secrets are encrypted and resolved on the server at run time, never exposed to the node on the canvas.

The second is the guided add flow, split into choosing a provider and configuring the connection. A searchable, paged grid of provider tiles covers messaging, productivity, developer, database, warehouse and communications services; picking one opens a configuration pane that offers delegated authorization as the recommended path or a key as the alternative. When delegated authorization is chosen, the design lists the exact permissions being requested with a plain-language explanation of each, states that the browser will hand off to the provider to authorize, and notes that access can be revoked from the provider at any time.

From there the connection is available in node configuration, in template imports that list which connections a blueprint still needs, and in the assistant's reminder to bind connections before activating a generated draft — making this the quiet dependency underneath most of the rest of the product.

What this concept shows

  • A workspace-level connections table listing provider, authorization type, connected account or environment, status and last use
  • A provider filter and a single action to create a new connection
  • Status badges that separate healthy connections from expired ones, with a reconnect action placed on the failing row
  • A last-used column sorted by recency, so rarely used connections settle at the bottom for review
  • A two-step add flow that separates choosing a provider from configuring the connection
  • A searchable, paged provider grid spanning messaging, productivity, developer, database, warehouse and communications services
  • A choice between delegated authorization, marked as recommended, and key-based configuration
  • An explicit list of the permissions being requested, each with a plain-language explanation, before the hand-off to the provider
  • A repeated assurance that secrets are stored encrypted and resolved on the server at run time rather than in the workflow

How it works

  1. Open the workspace connections list and review what is already authorized, filtering by provider if the list is long.
  2. Scan the status column for anything expired and use the reconnect action on that row to restore it.
  3. Start a new connection and choose the service from the searchable provider grid.
  4. Pick delegated authorization or a key, then read the permissions being requested and what each one allows.
  5. Complete the authorization with the provider, then return to see the connection listed with its account and status.
  6. Select the connection by name inside node configuration, or bind it when importing a template or activating a draft workflow.

Who it's for

  • Automation builders wiring connector nodes to real services
  • Workspace administrators who own which third-party accounts are authorized
  • Security and IT reviewers checking what permissions an automation platform requests
  • Agency and consulting teams keeping one workspace of connections per client

Illustrations

2 illustrations of this concept. Select one to view it full size.

Workspace Connections With Status and Reconnect

Authorized services in one table, with an expired connection offering a reconnect action.

This illustration shows the workspace connections page inside the standard shell, with the left navigation and a monthly usage meter beside the main table. The header names the page and describes it as credentialed links to external services, with a provider filter and a button to create a new connection. The table columns cover provider, authorization type, connected account, status, last used and a row actions menu. Sample rows mix delegated-authorization and key-based entries across messaging, payment, marketing, developer and productivity services, each with a connected badge and a relative last-used time, ordered from most to least recently used; the final sample row is marked expired and shows a reconnect link. A banner at the foot of the page restates that secrets are encrypted and resolved on the server at run time, so nodes never see raw credentials.

Guided Add Connection With Permission Review

Choose a provider, then review exactly which permissions the connection will request.

The design splits creating a connection into two numbered steps inside one dialog. On the left, a searchable grid of provider tiles covers messaging, productivity, developer, customer, database, warehouse and communications services, with the selected tile check-marked and pagination dots indicating further pages. On the right, a configuration pane offers delegated authorization as the recommended method or a key as an alternative tab. With the first selected, the pane names the service being connected, then lists the permissions being requested as rows — sending messages as the user, reading basic channel information, reading basic user information — each with an information control. A line explains that the browser will be redirected to the provider to authorize, a prominent authorize button follows, and a note says access can be revoked from the provider at any time. A footer repeats that secrets are stored encrypted, never in the workflow.

Topics

  • workflow connections
  • credential management
  • OAuth connection setup
  • API key connection
  • reconnect expired credential
  • connector authorization scopes
  • secrets never stored in workflows
  • integration provider list
  • workspace credential inventory
  • connect Slack Stripe HubSpot

We use cookies for essential site functions and, with your consent, for analytics to improve FluidGrids. We don't use advertising or cross-site tracking cookies. See our Cookie Policy.

Preferences