Connecting Accounts
How personal OAuth accounts are connected — from Settings or directly from a workflow block — and how to troubleshoot a connect that fails
OAuth-based integrations (GitHub, Google, Microsoft, …) distinguish two things:
- The integration itself — installed and configured by an organization admin under Settings → Integrations. This stores the org-level OAuth client credentials (Client ID / Client Secret) and creates a connection for the product. An integration showing Active here means the org has it configured and enabled — it does not mean your personal account is linked yet.
- Your personal account — the OAuth account you authorize against that integration. This is what a workflow block's account selector (e.g. "Select GitHub account") lists.
Where to connect an account
You can connect a personal account from either place — both end in the same vendor OAuth consent screen:
- Settings → Integrations (account tab): pick the provider and click Connect.
- Directly from a block: open the block's account dropdown and choose Connect <provider> account. A dialog shows the permissions that will be requested; Connect sends you to the provider. When you return, the new account is selected automatically.
Accounts are connected against the integration's Default connection — the connection the platform creates automatically when an admin installs the integration. If your organization uses additional named connections (for example per environment), use Re-authorize on the specific connection in the admin connections panel instead.
The account dropdown lists accounts you connected in this organization. A credential selected by a collaborator shows as "Saved by collaborator" — you don't need their account to run the workflow, but you can connect your own at any time.
Troubleshooting a failing connect
The connect dialog stays open and shows the error when the authorization URL cannot be built:
| Error | Meaning | Fix |
|---|---|---|
No Default connection found. Install the integration first. | The integration is not installed (or was removed) for this organization. | An org admin installs/enables the integration under Settings → Integrations. |
OAuth client credentials are misconfigured for provider … | The org-level Client ID is malformed — e.g. an email address was pasted into the Client ID field. | An org admin corrects the Client ID / Client Secret on the integration's credential form. |
OAuth client credentials are not configured for provider … | The integration is enabled but no Client ID / Secret were saved. | An org admin completes the credential form. |
Provider shows a redirect_uri warning | The OAuth app registered at the vendor doesn't list your deployment's callback URL. | Register https://<your-host>/api/auth/integrations/account/callback/<provider> on the vendor's OAuth app. |
After a successful connect you are redirected back to where you started, and the account appears in the dropdown (and is auto-selected if nothing was selected before).
Microsoft: "Need admin approval"
Microsoft 365 / Teams connects can be interrupted by an Azure prompt:
Need admin approval — Scrydon needs permission to access resources in your organization that only an admin can grant.
This is an Azure Entra (Azure AD) tenant policy, not a Scrydon error: your organization restricts which apps users may consent to, so the Microsoft scopes Scrydon requests require a one-time approval by a tenant administrator. Until that approval is granted, no account is stored — and a Teams block then reports that the Microsoft account is not connected (previously this surfaced as an opaque InvalidAuthenticationToken / IDX14100 401).
To fix it, a Microsoft tenant admin grants consent for the Scrydon app once — either by completing the admin-consent prompt, or via the Entra admin center (Enterprise applications → Consent and permissions). After that, reconnect your account under Settings → Connected Accounts; for a single-tenant organization the admin should also set the integration's Tenant ID to the tenant GUID rather than common.