Connecting Accounts

OAuth-based extensions (GitHub, Google, Microsoft, …) distinguish two things:

1. The extension itself — installed and configured by an organization admin under Settings → Platform → Extensions. This stores the org-level OAuth client credentials (Client ID / Client Secret) and creates a connection for what it provides. An extension showing Active here means the org has it configured and enabled — it does not mean your personal account is linked yet.
2. Your personal account — the OAuth account you authorize against that extension. A workflow block does not offer a selector to choose between accounts; it automatically uses whichever account the identity running the workflow (you, or the service account it runs as) has connected for that provided item.

API-key connections and regional AI resources

The Connections → Add connection form uses the extension's credential definition, including its key label and configuration fields. Azure AI Foundry asks for its resource API key and Foundry endpoints. Microsoft OAuth products ask for a Client ID and Client Secret. If an extension offers several authentication methods, choose the method in the form. Products with an explicit credential requirement receive only compatible credentials.

For multiple Foundry resources, install the extension once and add named connections such as North Europe, Sweden Central, and West Europe. Give each connection its own resource key and endpoints, and choose its environment scope. Editing a connection shown as covering several products updates that group's configuration together.

In Settings → Platform → Extensions → Models & defaults, choose All environments to edit the shared default, or an organization environment such as Development or Production to override it. Personal configures Personal workspaces, whose internal environment identifier remains main. The selector does not switch your active workspace.

Open a capability's searchable dropdown to load models across every eligible connection:

• All environments includes connections configured for all environments.
• A specific environment includes its own connections plus shared connections, subject to the organization's wildcard connection policy.
• Entries are grouped by vendor and connection. Identical model names on different Azure resources remain separate choices; choosing one pins that connection and model.
• Automatic chooses an eligible vendor/model at execution time. An Automatic override replaces an inherited pin. Use shared default removes the override.

The catalog is organization-wide, so you can configure Development or Production while working in Personal. The dropdown only offers eligible model choices; models explicitly reported as unavailable or unverified are omitted. Workspace permissions and clearance still apply when a workflow runs. Production-only credentials are never borrowed by Development or Staging.

Existing saved connection pins remain pinned, including older organization-wide defaults that named an environment-specific connection. If a connection is removed, disabled, or inaccessible, execution reports an unavailable configuration until you choose a replacement. A concurrent policy update rejects a stale save instead of overwriting another environment's settings. Reload the policy before retrying.

Azure Speech routes through the configured Foundry resource endpoint; no separate Azure Speech Region field is needed for routing. Set Azure Region on each Foundry connection so the catalog can filter built-in Speech models by Microsoft's regional support. Azure region (for example, northeurope) is separate from application environment (Development, Production, or All environments); it cannot be inferred from a resource's user-chosen name.

The STT catalog includes MAI Transcribe 2, MAI Transcribe 1.5, Azure Speech Fast Transcription, and Azure AI Speech — live transcription with speaker labels, alongside discovered deployments. MAI and Fast Transcription use Microsoft's Speech transcription API, without an OpenAI deployment. MAI accepts WAV, MP3, or FLAC audio. MAI's HTTP transcription operation is not a Speech SDK streaming session.

Built-in service entries use the connection's configured Azure region to filter known unsupported models. Built-in Speech models with an unknown region are also omitted until regional support is confirmed. Set Azure Region to the resource's actual region and reopen the selector to refresh its choices; connection names such as Default or Sweden Central do not establish the region. The selector lists choices without an availability badge. If none are available for a capability in the selected environment, the row explains this instead of showing a dropdown. Install and configure extensions from the Installed tab. Catalog support does not prove that a specific resource can execute a model. Opening the selector does not send billable test audio; Azure validates access when transcription is requested.

Microsoft's region table lists ordinary realtime Speech in North Europe, Sweden Central and West Europe, while its LLM/MAI transcription service table includes North Europe but not the other two. Check MAI model availability for the actual resource. Adding a connection does not provision models or enable them in every region.

If choices cannot load, use Try again and check the selected environment and connection.

Sign-in providers are different

The Providers section under Settings → Profile → Security links an authentication provider to your Scrydon identity. It is separate from the extension accounts described on this page and uses the deployment's social-login configuration.

Only providers configured by your Scrydon operator appear there. If the Providers section is absent, the deployment has no social-login provider available for account linking; use the enabled sign-in methods or contact your operator. Installing GitHub, Google, or Microsoft under Settings → Platform → Extensions does not enable the corresponding authentication provider.

Where to connect an account

You can connect a personal account from either place — both end in the same vendor OAuth consent screen:

• Settings → Connected Accounts: pick the provider and click Connect.
• Directly from a block: a block whose Identity field shows it has no account yet for that product shows a single Connect <product> button — no dropdown, no account to pick. Clicking it sends you straight to the provider; there is nothing to confirm first. When you return, the block reads as ready with your new account automatically — there is no separate selection step.

Accounts are connected against the extension's Default connection — the connection the platform creates automatically when an admin installs the extension. If your organization uses additional named connections (for example per environment), use Re-authorize on the specific connection in the admin connections panel instead.

Reading the admin connections panel

Settings → Platform → Extensions → <extension> → Connections lists one row per credential, not one per product. A credential that serves several of an extension's products appears once, and the Applies to column names the products it covers — "Outlook", or "7 products" when the list is long.

That matters most for model providers. Installing Azure AI Foundry, for example, provisions the same API key for each of its products (LLM, Embeddings, Speech-to-Text and the rest); the panel shows that as one Default connection applying to seven products, rather than seven identical rows.

Two consequences worth knowing:

• Adding a connection covers every product of the extension. You enter the credential once instead of repeating the form per product.
• Deleting one removes it from every product it covers. The confirmation names them before you commit.

Vendors whose products each need their own grant — Microsoft, where Outlook and Excel are separate OAuth consents — still show one row per product, because those are genuinely different credentials.

One account per product, not per vendor

A connected account belongs to one product, not to the vendor as a whole. An account you connect for Outlook cannot be used by a Teams block, and vice versa — even though both sign you in with the same Microsoft identity. The connect control therefore lists one entry per product ("Microsoft — Outlook", "Microsoft — Teams"), and a block only ever reads the account connected for its own product — it cannot use one connected for a different product of the same vendor.

This is also why each connect asks for a different permission set: the consent screen requests exactly what that product needs. In practice you will usually see the consent screen once per vendor — most identity providers return every permission you have already approved for the same application, so connecting a second product for the same vendor often completes without another prompt.

Who owns a connected account

Every connected account has an owner in Scrydon, separate from the person who clicked Connect. The owner decides what happens to the credential when people come and go:

The Microsoft sign-in behind an automation mailbox is still a real user account at the vendor; ownership is about who holds it in Scrydon, not about the kind of account at the vendor.

Where you connect from decides the owner. Connecting from your own settings gives you a member-owned account. Connecting from a service account's Credentials panel — Connect account / Connect another account — gives that service account the credential straight away, even though a human signs in at the vendor to authorize it. There is no reassignment step to remember, and no window in which an automation credential belongs to a person.

An organization admin can still change the owner of an existing credential from the same panel with Reassign to this service account — use it to adopt a mailbox somebody connected personally before. Reassigning is an ownership change only: the existing sign-in and its permissions are kept, so nobody has to consent again.

Whoever signed in at the vendor is recorded separately as the credential's creator. That record never changes hands, and it is not the owner.

Service accounts and environments

A service account's credential is linked per connection. If a product has a Dev and a Prod connection, link the service account on each — they are two different vendor apps holding two different sign-ins, so a Dev link never carries over to Prod. When a workflow that runs as a service account is promoted to an environment where nothing is linked yet, the run stops at that step with RUN_AS_IDENTITY_MISSING, naming the connection to fix.

Granting missing permissions

An account can be connected and healthy yet still lack a permission a particular block needs — for example an account connected before your organization enabled shared-mailbox actions.

When that happens Scrydon names the missing permissions instead of failing when the workflow runs:

• In the block's Identity field — an amber notice lists the missing permissions with an Update access button.
• Under Settings → Connected Accounts — the account shows a Missing permissions badge and a Grant access button.

Either one sends you back to the provider's consent screen for that product only. When you return, the notice clears itself. Nothing else about the account changes — the same account row is reused, so any workspace sharing and any block already pointing at it keep working.

Making an account available to a workspace

A personal account you own is usable in every workspace you belong to automatically — there is no assignment step, because a block never selects an account for you to opt into sharing.

To make your account usable by other members of a workspace, a workspace owner or administrator shares it explicitly from Settings → Workspaces → Extension credentials, and can revoke that sharing from the same panel later, without disconnecting your provider account. A workflow block itself never triggers this — sharing is always an admin action, not a side effect of configuring a block.

Microsoft Teams authorizes the target required by each action. Chat actions such as Write Chat Message select a Chat and do not require a Team. Channel actions require a Team plus their channel input. If a retained pre-production workflow shows a reselect warning, choose the account again; legacy encoded credential strings are intentionally not inferred.

Troubleshooting a failing connect

The connect dialog stays open and shows the error when the authorization URL cannot be built:

After a successful connect you are redirected back to where you started. Under Settings → Connected Accounts the new account appears in your connected-accounts list; on a block, its Identity field automatically reads as ready with the new account — there is nothing further to select.

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 extension's Tenant ID to the tenant GUID rather than common.

Once tenant-wide consent is in place, users connect without any approval screen. If non-admin users still see "Need admin approval" even though the Entra portal shows every permission as granted, you are on a Scrydon version that forced a re-consent prompt on every connect (fixed in July 2026) — upgrade, since Entra requires the signed-in user to personally re-approve admin-restricted scopes on a forced prompt, which a non-admin can never do.

Saving a default model

Selecting an entry in Models & defaults saves it immediately. Shared defaults apply to environments without an override. Existing saved choices without a pinned connection keep their original connection-resolution behavior; selecting a replacement pins its connection.

If saving fails, the pending choice remains visible. Use Retry to save it again or Cancel to restore the saved value.