Riversoft
Log in

Documentation

Connect Cascade to your platforms

These guides walk through adding each platform connection in Cascade. Follow the steps in order for the systems you use, then import objects so they are available in workflows.

Only admins can create or update connections. License tiers also limit how many connections your tenant can hold.

Before you start

  1. Open Cascade and go to Log in.
  2. Sign in with your email and password.
  3. Complete MFA if prompted. Cascade requires multi-factor authentication for every role. If you have not enrolled an authenticator yet, you will be guided through set-up before you can continue.
  4. Select your tenant if you belong to more than one.
  5. In the left sidebar, open the platform under Connections that you want to configure (for example Fabric, Qlik or Databricks).

Tenant roles

Every user belongs to a tenant with one role. Roles control what you can configure and run inside Cascade. Multi-factor authentication is required for all roles.

Tenant owners have the same day-to-day permissions as admins. Owner accounts are provisioned by Cascade operations; admins, creators, and executors are managed from Settings → Users.

Admin

Full access to the tenant. Admins manage the platforms Cascade connects to and can build and run workflows.

  • Create, update, and delete platform connections; import objects; rotate secrets
  • Generate and revoke tenant API keys; change tenant settings
  • Create, edit, delete, and run workflows, including schedules and failure alerts
  • Invite creators and executors; change their roles or remove them from the tenant

Creator

Build and operate workflows without touching tenant-wide connection or API key settings. Creators can design automation but cannot expose or rotate platform credentials.

  • Create, edit, delete, and run workflows, including schedules and failure alerts
  • View connections and imported objects so jobs can be wired into workflows
  • Open the workflow editor with full edit access
  • Cannot create or update connections, rotate secrets, or manage API keys and tenant settings

Executor

Run workflows on demand with read-only access to workflow definitions. Executors are suited to operators who need to trigger or monitor runs without changing automation logic.

  • Open workflows in read-only mode and manually start or cancel runs
  • View schedules and run history
  • Cannot save workflow changes, create or delete workflows, or manage connections, secrets, or API keys

Fabric

Connect Microsoft Fabric with a Microsoft Entra application (service principal). From the same page you can also register Fabric capacities for scale-up and scale-down in workflows.

App registration roles and access

Cascade authenticates with client credentials (application permissions). Create a single-tenant app registration in Microsoft Entra ID, add a client secret, and grant the access below so Cascade can list workspaces, run Fabric pipelines and refresh Power BI semantic models.

  • Entra app type: single-tenant application with a client secret (service principal)
  • API permissions (Application, not Delegated): Power BI Service → Tenant.ReadWrite.All, then Grant admin consent
  • Fabric / Power BI Admin portal → Tenant settings: enable “Service principals can use Fabric APIs” (and Power BI APIs) for a security group that includes this app
  • Workspace role: add the service principal to every Fabric / Power BI workspace Cascade will use as Contributor (Member can work for some read paths; Contributor is required to run pipelines and refresh semantic models reliably)
  • Capacity scale (optional): Azure RBAC Contributor (or equivalent) on the Microsoft.Fabric capacity resource in the Azure subscription

Add a Fabric connection

  1. Open Fabric in the Connections sidebar.
  2. Choose Add Fabric connection.
  3. Fill in:
    • Connection name
    • Entra tenant ID
    • Client ID
    • Client secret
  4. Choose Save Fabric connection.
  5. On the connection row, choose Test to confirm access.
  6. Choose Import workspaces, then open a workspace and Import objects so they can be used in workflows.

Add a Fabric capacity (optional)

Capacities are configured on the Fabric page after at least one connection exists. The same service principal must hold Azure RBAC on the capacity (Contributor is the usual choice) so Cascade can pause, resume and scale SKU via Azure Resource Manager.

  1. Choose Add Fabric capacity.
  2. Fill in:
    • Fabric connection
    • Display name
    • Azure subscription ID
    • Resource group
    • Capacity name
    • Azure region (optional)
  3. Save, then use Test on the capacity row.

Qlik

Connect Qlik Cloud with OAuth client credentials, or with an API key as a fallback.

  1. Open Qlik in the Connections sidebar.
  2. Choose Add Qlik connection.
  3. Fill in:
    • Connection name
    • Qlik host (for example https://your-tenant.eu.qlikcloud.com)
    • Client ID (recommended)
    • Client secret (recommended)
    • API key (optional fallback)
  4. Choose Save Qlik connection.
  5. Choose Test on the connection row.
  6. Choose Import spaces, then Import objects for the spaces you need.

QTC

Connect QTC with a personal access token or a service account.

  1. Open QTC in the Connections sidebar.
  2. Choose Add QTC connection.
  3. Enter a Connection name and your Tenant URL.
  4. Choose authentication:
    • Personal access token: paste the token
    • Service account: Client ID and Client secret
  5. Choose Save connection.
  6. Choose Test, then Import pipeline projects.

Databricks

Connect a Databricks workspace with a personal access token. An optional account ID supports multi-workspace import.

  1. Open Databricks in the Connections sidebar.
  2. Choose Add Databricks connection.
  3. Fill in:
    • Connection name
    • Workspace URL (full browser URL, for example *.azuredatabricks.net)
    • Personal access token
    • Databricks account ID (optional; leave empty for a single workspace)
  4. Choose Save Databricks connection.
  5. Choose Test, then Import workspaces, then Import jobs & pipelines.

Snowflake

Connect Snowflake with your account URL and a bearer token (JWT is recommended for the SQL API).

  1. Open Snowflake in the Connections sidebar.
  2. Choose Add Snowflake connection.
  3. Fill in:
    • Connection name
    • Account URL (https://<account_identifier>.snowflakecomputing.com)
    • Bearer token (JWT)
  4. Choose Save Snowflake connection.
  5. Choose Test, then Import databases, then Import tasks (and notebooks where applicable).

Allow Cascade through a Snowflake network policy

If your Snowflake account uses a network policy (or you plan to add one), Cascade must be able to reach Snowflake from its outbound (egress) IP addresses. Without those addresses on an allow list, Test connection, import and workflow runs fail even when the JWT is valid.

Ask your Cascade contact for the current Cascade egress IP allow list before you change production network policy. Include your own administrators' IP addresses (or CIDR ranges) in the same allow list so you are not locked out of Snowsight or the SQL worksheet when the policy becomes active.

  1. Sign in to Snowflake as a user with the SECURITYADMIN role (or another role that can manage network policies).
  2. Create an ingress network rule for Cascade's IPv4 addresses (replace the placeholders with the IPs you were given; CIDR ranges are supported):
    CREATE NETWORK RULE cascade_egress_ips
  TYPE = IPV4
  MODE = INGRESS
  VALUE_LIST = ('203.0.113.10', '203.0.113.0/24')
  COMMENT = 'Cascade application egress';
  3. Create a network policy that allows that rule (and any rules you already use for office or VPN access):
    CREATE NETWORK POLICY cascade_access_policy
  ALLOWED_NETWORK_RULE_LIST = ('cascade_egress_ips' /* , 'office_ips', ... */)
  COMMENT = 'Allow Cascade and approved networks';
  4. Attach the policy to the account, or only to the service user Cascade uses. Account level:
    ALTER ACCOUNT SET NETWORK_POLICY = cascade_access_policy;
    User level (recommended if you want to restrict only the Cascade service user):
    ALTER USER <cascade_service_user> SET NETWORK_POLICY = cascade_access_policy;
  5. In Cascade, run Test on the Snowflake connection again. If it still fails with network or authentication errors, confirm the allow list matches the latest Cascade egress IPs and that the policy is attached to the user that owns the JWT.

Power Automate

Connect Power Automate with Microsoft Entra client credentials so Cascade can import environments, list flows and trigger runs.

App registration roles and access

Cascade uses client credentials against Power Platform and Power Automate APIs. Register a single-tenant Entra application with a client secret, then grant the service principal access inside each Power Platform environment you will use.

  • Entra app type: single-tenant application with a client secret (service principal)
  • Power Platform admin centre → Environment → Settings → Users + permissions → Application users: create an application user for this app in every environment Cascade will use
  • Environment security roles on that application user: System Administrator (recommended for import and run polling) or at minimum Environment Maker plus rights to the flows Cascade must run
  • Flow ownership: set the application user as Owner of each flow Cascade will trigger (Microsoft does not allow a service principal as co-owner)
  • HTTP trigger authentication: “Any user in my tenant”, or “Specific users” with the app’s Enterprise application Object ID (not the Application / client ID)
  • Power Platform API access: assign the service principal a Power Platform RBAC role that can read environments (for example Environment Admin or a broader admin role) so Import environments succeeds

Add a Power Automate connection

  1. Open Power Automate in the Connections sidebar.
  2. Choose Add Power Automate connection.
  3. Fill in:
    • Connection name
    • Entra tenant ID
    • Client ID
    • Client secret
  4. Choose Save Power Automate connection.
  5. Choose Test, then Import environments, then Import flows.

dbt Cloud

Connect dbt Cloud with your API host, account ID and a service account token.

  1. Open dbt Cloud in the Connections sidebar.
  2. Choose Add dbt Cloud connection.
  3. Fill in:
    • Connection name
    • API host (default https://cloud.getdbt.com, or your cell URL)
    • Account ID
    • Service account token
  4. Choose Save dbt Cloud connection.
  5. Choose Test, then Import projects, then Import jobs.

Fivetran

Connect Fivetran with an API key and secret from Account settings → API keys.

  1. Open Fivetran in the Connections sidebar.
  2. Choose Add Fivetran connection.
  3. Fill in:
    • Connection name
    • API key
    • API secret
  4. Choose Save connection.
  5. Choose Test, then Import groups, then Import syncs.

Starburst

Connect Starburst Galaxy with OAuth client credentials. To run SQL on the cluster you also need Galaxy user and Trino (service account) password credentials.

  1. Open Starburst in the Connections sidebar.
  2. Choose Add Starburst Galaxy connection.
  3. Fill in:
    • Connection name
    • Account domain (account host, not a Trino cluster URL)
    • Client ID
    • Client secret
    • Galaxy user for runs (optional on create; email from Access → Users)
    • Trino / service account password (optional on create)
  4. Choose Save connection.
  5. If you did not set run credentials on create, use Edit run credentials before you need to run SQL.
  6. Choose Test, then Import SQL jobs.

Google

Connect Google BigQuery-related capabilities (Dataform, data transfers and notebooks) with a service account JSON key. Enable at least one capability when you create the connection.

  1. Open Google in the Connections sidebar.
  2. Choose Add Google connection.
  3. Fill in:
    • Connection name
    • GCP project ID
    • GCP region (for example europe-west2 or us-central1)
    • Capabilities: Dataform, Data transfers and/or Notebooks (at least one)
    • Dataform repository ID (if Dataform is enabled)
    • Colab runtime template and GCS output URI (if Notebooks are enabled)
    • Service account JSON key
  4. Choose Save Google connection.
  5. Choose Test, then run the import actions for the capabilities you enabled.

API keys

Tenant API keys are not platform connections. They let external systems trigger workflows with Bearer authentication. API triggering requires a license that includes it (Professional and above).

  1. Open Settings in the app.
  2. Find the API keys card.
  3. Optionally enter a Name (for example Zapier / Prod webhook).
  4. Choose Generate API key.
  5. Copy the key immediately. It is shown once and stored only as a hash.

Trigger a workflow

External systems start a Cascade workflow with a single HTTP request. Generate a tenant API key first (see API keys), then call the trigger endpoint with Bearer authentication.

Endpoint

Use POST against the www host. Calling the apex domain (rs-cascade.com without www) returns a permanent redirect that some tools, including Power Automate, do not follow on POST.

POST https://www.rs-cascade.com/api/workflows/trigger

Headers

  • Authorization: Bearer orca_… (your tenant API key)
  • Content-Type: application/json

Body

  • tenantSlug (required): tenant slug from the app URL, for example /app/acme-corp/…
  • workflowId (required): UUID of the workflow to run
  • asyncOnly (optional): true returns immediately and starts the run in the background; false waits for execution in the same request and returns the resulting status
{
  "tenantSlug": "acme-corp",
  "workflowId": "11111111-2222-3333-4444-555555555555",
  "asyncOnly": true
}

Example

curl -X POST https://www.rs-cascade.com/api/workflows/trigger \
  -H "Authorization: Bearer orca_YOUR_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d '{
    "tenantSlug": "acme-corp",
    "workflowId": "11111111-2222-3333-4444-555555555555",
    "asyncOnly": true
  }'

Response

A successful call returns JSON with ok: true, a runId, a status, and the workflow name. With asyncOnly: true, status is typically queued while Cascade starts the run after responding. With asyncOnly: false, status reflects progress or completion from that request, and may include errorMessage.

{
  "ok": true,
  "runId": "…",
  "status": "queued",
  "workflowName": "Nightly refresh"
}

The Vault

Cascade protects credentials in two layers. Platform API keys, tokens and client secrets (Fabric, Qlik, Databricks, Snowflake and the rest) are written into The Vault, which encrypts each secret before it is stored. Cascade's own tenant API keys (used to call the workflow trigger) are never encrypted for later recovery. They are destroyed as plaintext immediately after creation and replaced with a one-way cryptographic hash. In both cases the usable secret is not kept in ordinary application columns.

1. Platform API keys and connection secrets

When an admin saves or updates a connection, Cascade calls the encryption module inside the database. Credentials are protected with authenticated encryption with associated data (AEAD) via libsodium, using the XChaCha20-Poly1305 construction: a modern, widely adopted standard that both encrypts the secret and authenticates it so ciphertext cannot be forged or swapped unnoticed. Only ciphertext is stored in The Vault. Cascade connection tables keep a reference to that vault row, never the secret text itself.

After the write completes, the plaintext you typed is not retained by the Cascade UI or by the connection row. Stored platform credentials cannot be retrieved through the user interface or public APIs after they have been saved. Rotation works by creating a new vault secret, pointing the connection at the new id, and discarding the previous vault entry. If you need the value later, you must keep your own copy outside Cascade; Cascade cannot hand it back.

  • Encryption standard: AEAD with XChaCha20-Poly1305 (libsodium); encrypts and authenticates each secret at rest
  • During a workflow run, Cascade unlocks a secret only inside its secure server process to call the platform API; the secret is never sent to the browser or returned on a public endpoint
  • Creators and executors can run workflows that use a connection, but cannot create, rotate or read platform secrets
  • Being a tenant member is not enough to manage secrets; only admins can create or rotate them
  • Key management: encryption keys are managed by Supabase Vault and are separate from application data; Cascade does not embed or persist encryption keys within its application database or source code

2. Tenant API keys: hashed, not encrypted

Encryption implies a key that can reverse ciphertext back to plaintext. Cascade does not do that for tenant API keys. On generate, the server draws 32 random bytes (crypto.randomBytes), encodes them as a URL-safe string, and prefixes orca_. That full string is shown once in the create response. Immediately afterwards Cascade computes SHA-256 (a NIST-approved cryptographic hash standard) of the key and stores only the hex digest in tenant_api_keys.key_hash, plus a short hint (the last six characters) for recognition in Settings.

A hash is a one-way function. There is no vault ciphertext and no decryption key that can recreate the original orca_… string. Not Cascade operators, not admins, not a database export of key_hash values. SHA-256 is not designed to be inverted; recovering the key from the digest is computationally infeasible. If the plaintext is lost, the only option is to revoke that key and generate a new one.

  • Generation: cryptographically secure random bytes, not derived from passwords or tenant identifiers
  • Persistence: SHA-256 digest only; the plaintext key is never written to the database
  • Verification at trigger time: Cascade hashes the incoming Bearer token and compares digests; it never decrypts a stored key
  • Maximum of two active keys per tenant; revoke before creating a replacement if you are at the limit
  • Only admins can generate, revoke or delete keys; API triggering must be enabled on the tenant licence

3. How the trigger API authenticates

External callers start a workflow with POST /api/workflows/trigger, sending Authorization: Bearer <orca_…> and a body that names the tenant slug and workflow id.

  1. Cascade hashes the Bearer token with the same SHA-256 procedure used at creation and looks for a matching active (non-revoked) key belonging to that tenant.
  2. The key is bound to the tenant in the request. A key from tenant A cannot trigger workflows in tenant B, even if someone knows another tenant's slug and workflow ids.
  3. There is no shared global trigger secret. Scheduler credentials used for Cascade's own cron ticks are separate and are not accepted as workflow trigger authentication, so an ops cron secret cannot start another customer's workflows.
  4. The named workflow must belong to that tenant. Licence checks still apply (api_triggering).

4. What Cascade does not do

  • Does not email or log the full tenant API key after the creation response
  • Does not allow stored platform credentials to be retrieved through the user interface or public APIs after they have been saved
  • Does not allow creators or executors to mint API keys or rotate connection secrets
  • Does not accept a single organisation-wide password that can trigger any tenant
  • Does not update an API key in place; rotation means revoke (and optionally delete) then generate a new key
  • Does not store a reversible encryption of tenant API keys; once saved as a hash, decryption is impossible by design

5. Practical hygiene

Treat platform secrets and Cascade API keys like production credentials. Prefer short-lived tokens in the source platforms where available, rotate after staff changes, and revoke a Cascade API key immediately if it may have been exposed. Store the plaintext key only in your own secrets manager. Cascade cannot re-display it after save.

Update credentials

When a secret rotates in the source platform, update it in Cascade without rebuilding workflows.

  1. Open the platform page for that connection.
  2. On the connection row, choose Update credentials (Starburst also has Update OAuth secret and Edit run credentials).
  3. Enter the new secret or token for that platform.
  4. Save, then run Test again.

What you replace depends on the platform:

  • Fabric / Power Automate: new client secret
  • Qlik: new API key, or new client secret
  • QTC: new personal access token, or new client secret
  • Databricks: new personal access token
  • Snowflake: new access token
  • dbt Cloud: new service token
  • Fivetran: new API key and API secret
  • Starburst: new OAuth client secret; separately Galaxy user and Trino password
  • Google: new service account JSON

Next steps

After connections are tested and objects are imported, open Workflows to design sequences across platforms, schedule runs, or trigger them from the API.

See Tenant roles for what admins, creators, and executors can do in the app.

Log inAbout CascadeRequest trial