Configure Connectors for Salesforce Flow

CloudTools actions let Salesforce Flows work with Microsoft 365 resources. Before adding actions, configure a connector that can authenticate without an interactive user sign-in and make it the default for Flow automations.

For Microsoft 365 Flow automation, use OAuth Application (Client Credentials) and choose actions that support application permissions. Some actions require a signed-in Microsoft user and cannot be used in CloudTools Flows, even if they appear in Flow Builder.

Why Flow actions need application authentication

A Flow can run when a record changes, on a schedule, or in another background process. At that point, there may be no person available to open a Microsoft sign-in window, complete multifactor authentication, or approve access. Being signed in to Salesforce does not automatically authorize access to Microsoft 365.

OAuth Application (Client Credentials), stored as OAUTHCC, authenticates the integration as an application. CloudTools uses the app’s Client ID and Client Secret to request an access token. The token allows the app to perform the operations authorized by its Microsoft Graph application permissions. A Microsoft Entra administrator must grant consent for those permissions. No interactive Microsoft sign-in is needed when the Flow runs.

OAuth Delegated (Authorization Code), stored as OAUTHAC, obtains access on behalf of a signed-in Microsoft user. It depends on that user’s authorization and can require another sign-in later. An admin’s successful sign-in while testing a component does not make that connection suitable for unattended Flow execution. Use a separate delegated connector for interactive CloudTools components.

These requirements concern CloudTools’ Microsoft 365 automation, rather than every possible Salesforce Flow integration. An API Key connection can be appropriate for a service that supports it, but an API key cannot replace the application permissions required by Microsoft Graph. Microsoft explains the distinction in its application and delegated permissions guide.

1. Check that your actions support Flow automation

Review the permissions for each action you plan to use. The action must support Application permissions for the operation you intend to perform. Grant the required permissions to the Microsoft Entra app registration and obtain administrator consent. Adding delegated permissions to the app is not sufficient for client credentials authentication.

For example, reading Outlook messages through an application connection requires an appropriate application mail permission and a specific target mailbox. The app’s access can also be limited by Microsoft tenant policies. Choose permissions for the intended operation rather than granting every permission listed.

2. Create an application connector

1. Open Apptigent CloudTools from the App Launcher, then select CloudTools Connectors.
2. Click New, or edit the application connector you intend to use. Use a descriptive name such as Microsoft 365 – Flow Automation.
3. Set Connector Type to Microsoft 365.
4. Set Authorization Type to OAuth Application (Client Credentials).
5. For CloudTools-managed authentication, enter the Microsoft Entra Tenant/Instance ID, Client ID, and current Client Secret. Use the secret’s value, not its Secret ID.
6. Set Scopes to https://graph.microsoft.com/.default. This requests the app’s configured Microsoft Graph permissions; it does not grant permissions or replace administrator consent.
7. Leave Named Credential, API Key, Authorization URL, and Reply URL blank. Leave Use Proof Key for Code Exchange (PKCE) unchecked.
8. Enable Set as default for Flow automations and save.

For the complete field reference, see Integration Connectors. Microsoft’s application access guide explains the permissions and token exchange used by this authentication method.

If you use a Named Credential

You can let Salesforce manage the application credentials instead. Configure a Named Credential and External Credential for Microsoft Graph using client credentials authentication, enter the Named Credential’s exact API name on the connector, and keep Authorization Type set to OAuth Application (Client Credentials). Client ID, Client Secret, Authorization URL, Reply URL, and Scopes must all be blank on the connector because Salesforce supplies those settings.

Grant the Flow’s execution user access to the External Credential principal, and allow the Apptigent namespace to use the Named Credential. Use a credential targeting Microsoft Graph, not the Salesforce API example in Advanced Configuration. A Named Credential that requires per-user sign-in does not become an application connection simply because it is selected on a Flow-default connector.

3. Understand the default toggle

Set as default for Flow automations is stored in Flow_Enabled__c. It tells CloudTools which connector to prefer when an action requests a connection by connector type instead of specifying a particular record.

Configuration	How CloudTools selects the connector
One matching connector has the toggle enabled	CloudTools prefers that record for lookups by connector type.
Multiple matching connectors have it enabled	CloudTools selects the oldest matching enabled record. The toggle does not automatically uncheck the other records.
No matching connector has it enabled	CloudTools falls back to the oldest matching connector, which might be a delegated connection unsuitable for the Flow.
An action explicitly receives a connector record ID	The specified record takes precedence. Not all actions expose a Connector ID input.

Keep exactly one Flow default for each connector type. When replacing it, uncheck the previous default and enable the new one. Separate records for interactive and automated access make the intended behavior easier to manage.

Important: Salesforce prevents saving a record with this toggle enabled and Authorization Type set to OAuth Delegated (Authorization Code). That validation also applies when a Named Credential is present. The toggle does not grant external permissions, authenticate a user, or make an unsupported action compatible with Flow.

The preference applies to connector-type lookups outside Flow as well. Explicitly select the delegated connector in interactive components that need user authorization so they do not pick up the application default.

4. Add and test a Flow action

1. Open your Flow in Flow Builder, add an Action element, and search for the required CloudTools action.
2. Confirm that the action supports application permissions. Complete its inputs, including the target user’s ID or principal name when required.
3. If the action provides a Connector ID input, supply the application connector’s Salesforce record ID when you want explicit selection. Otherwise, use the default configured above.
4. Begin with a read-only operation. For example, MS Outlook – Messages – Get Messages can read messages for an explicitly supplied User Id or Principal Name, provided the app has the required application permission.
5. Test under the execution context the Flow will actually use. Check outputs and error handling before activating the Flow.

Application authentication has no signed-in Microsoft user, so a mailbox or user cannot be inferred from /me. Supply the Microsoft user identifier requested by the action, such as automation@example.com. A Salesforce user ID is not a Microsoft user ID. Microsoft’s authentication guidance explains why /me requires delegated access.

Actions that cannot be used in Flows

Actions that require per-user delegated authorization are not supported for CloudTools Flow automation. For example, MS Copilot – Chat – Create Chat (CreateMSCopilotChat) sends a message to a Copilot conversation on behalf of a signed-in user. Microsoft’s Copilot chat API does not support application permissions.

An action may appear in Flow Builder because it is exposed as an invocable action. Its presence in the action picker does not mean that the external service supports application authentication for it. Check the action’s current permission requirements before including it in a Flow.

Enabling the Flow default, granting more application permissions, supplying a user ID, or selecting a Named Credential does not remove this restriction. Use the CloudTools Copilot components with delegated sign-in for these interactions. Check other actions individually; support for one operation in a service does not guarantee support for all of its operations.

Troubleshooting

• The connector will not save: Check that Authorization Type is OAuth Application, PKCE is unchecked, and the required credentials are present. With a Named Credential, clear the conflicting OAuth fields on the connector.
• The Flow selects the wrong connection: Check for multiple defaults, a missing default, or an explicit Connector ID pointing to another record.
• Sign-in or reauthorization is requested: Confirm that the Flow is using the application connector and that the action supports application access.
• Access is denied: Check application permissions, administrator consent, secret expiration, target resource access, and any Named Credential principal permissions.
• A target user is missing: Supply the Microsoft user ID or principal name required for application access, even if that input is optional for delegated use.

For Remote Site Settings or stale CloudTools tokens, consult Advanced Configuration. Clearing the token cache cannot make a delegated-only API support application authentication.