Troubleshooting

Invalid input errors or empty data sources when verifying access

You encounter an Invalid Input error within the platform's Organization Settings, find that external SharePoint folder or site configuration pages load entirely blank, or face complete connection failures when attempting to grant platform access.

Cause

This behavior stems from missing required API permissions inside your Microsoft Azure App Registration. This typically occurs during integration reconfiguration cycles, such as updating folder-level access privileges. Administrators frequently focus exclusively on newly introduced Microsoft Graph permissions highlighted in update logs, inadvertently removing or failing to re-verify mandatory legacy SharePoint-specific API scopes.

Resolution

1. Audit the Azure app registration: Navigate to your Azure Portal and locate the specific App Registration configured for Responsive.

2. Verify global scopes: Ensure that all required Microsoft Graph core permissions (such as Files.Read.All and Sites.Read.All) are active and verified.

3. Restore SharePoint permissions: Explicitly verify that the following critical permission scope is enabled under the SharePoint API section:

   • API / Scope Name: SharePoint $\rightarrow$ AllSites.Read

4. Cycle the integration handshake: Once your Azure configurations are saved and updated, log back into Responsive to re-synchronize the secure connection:

   1. Go to Organization Settings and disconnect the active SharePoint integration.

   2. Re-initiate the integration connection from scratch.

   3. Click Update Access, complete the standard administrative OAuth re-authentication workflow, and verify site structural visibility.

See the Microsoft SharePoint integration guide and Connecting to SharePoint in Responsive with a Client ID and Secret Key for more information.

Important: When adding newly highlighted permissions from version update logs, ensure that existing baseline permissions (such as AllSites.Read) are retained unless explicitly instructed otherwise. Dropping mandatory baseline scopes will immediately compromise structural validation engines, breaking data discovery. For a full review of mandatory scopes, see the Microsoft SharePoint integration guide.

SharePoint sites are not visible in Organizational Settings

After completing a successful integration handshake, a specific target SharePoint site (such as a Compliance or departmental site) fails to appear under Organization Settings > SharePoint Sites even though other organizational repositories display normally.

Cause

The Responsive SharePoint connection layer is architected natively around modern SharePoint APIs and structural site metadata frameworks. Classic SharePoint sites operate on a legacy architecture framework that does not expose the required modern API endpoints and structural metadata necessary for Responsive to discover, list, or navigate site hierarchies.

Resolution

• Verify the framework architecture of your target site within your Microsoft 365 cloud environment.

• Ensure the target repository is provisioned using the Modern SharePoint experience.
  Note: Simply being cloud-hosted (Microsoft 365) does not automatically denote a modern framework; legacy Classic SharePoint Sites can't be discovered or supported by this integration infrastructure.

Inability to access SharePoint documents

If you're having trouble accessing SharePoint documents:

• Check if you have the correct permissions to view the documents.
  Note: The folder- and file-level permissions set in SharePoint carry over to Responsive, adding more control over who can see and use the information.

• Disconnect your SharePoint account and reconnect it.
  Note: All configurations, indexed folders, files and permissions are removed when you remove the SharePoint integration so the data can’t be used by Responsive AI.

Using the Connect Using Admin Account Instead of Individual User Account option

When configuring the SharePoint integration in Responsive Organization Settings, administrators may notice the Connect using admin account instead of Individual user account checkbox. This can lead to questions about whether enabling this option is required (it's not) and when it should be used.

Cause

This setting is optional and is intended to support different SharePoint authentication models. Enabling the setting causes the SharePoint integration to authenticate using a centrally configured administrator account; leaving it disabled allows each user to authenticate using their own Microsoft/SharePoint credentials.

The appropriate configuration depends on your organization's security, governance, and access management requirements.

Resolution

The Connect using admin account instead of Individual user account option is not mandatory.

• Enable this option if your organization prefers a centralized SharePoint connection using a dedicated administrator or service account for all users.

• Leave this option disabled if users should authenticate to SharePoint using their individual Microsoft accounts, allowing access to be governed by each user's existing SharePoint permissions.

Choose the option that best aligns with your organization's security policies and SharePoint access management strategy. Individual user authentication is generally recommended when organizations want to maintain user-specific access controls and auditing, while the administrator account option is suitable for organizations that require a centrally managed integration. See Configuring SharePoint in Responsive using a SharePoint URL section of the Microsoft SharePoint Integration guide or Connecting to SharePoint in Responsive with a Client ID and Secret Key for more information.

Ask returns results from SharePoint external sources for some users but Not others

In the Responsive Production instance, the SharePoint external sources are configured correctly, and Ask successfully returns SharePoint search results for some users (for example, a Responsive Super Admin). However, other users don't receive any SharePoint search results for the same query, despite having Admin privileges with all available permissions in Responsive and/or the necessary permissions to access the relevant documents directly within SharePoint.

Cause

The SharePoint folder and site permissions are not being indexed correctly into the external_permissions metadata used by the SharePoint external sources. Although the affected user is a member of the SharePoint site, the corresponding site membership permissions were not reflected in the indexed permission data. As a result, Ask is unable to determine that the user is authorized to access the indexed SharePoint content.

Resolution

Verify that the SharePoint site and folder permissions are correctly configured and successfully indexed into the external_permissions metadata. You may have to create a new SharePoint site and reapply the appropriate site permissions to resolve the indexing issue. Once the permissions are re-indexed successfully, affected users can retrieve SharePoint content through Ask as expected.