Slack feed agent returns "Access denied" despite valid, connected workspace

Q&A
, ,
1

Problem: Slack notifications do not appear in the Activity Feed. The background feed agent fails every cycle with “Access denied” when calling Slack APIs, even though the Slack connector is properly authorized and shows as “Connected” with 37 tools in Settings.

What fails:

  • The feed agent (background scheduled task) calls search_messages and gets: Quick Suite invokeAction failed (400): Access denied during the operation. Please check your permissions

  • This happens every 15-minute cycle, resulting in zero Slack notifications in the feed

  • A recurring “Slack monitoring temporarily unavailable” alert appears in the feed instead

What I’ve tried:

  • Uninstalled and re-authorized Slack connection (multiple times)

  • Verified connector shows as Connected in Settings > Capabilities > Connections

  • Confirmed connector_preferences.SLACK in the feed agent config points to the correct workspace ID

  • Used switch_slack_workspace in an interactive session (fixes chat, does not fix the feed agent)

  • Reset Slack trigger state and triggered a manual test run (still fails)

Diagnostic details:

  • Two Slack connectors registered: “Devices Slack” (old) and “Devices Slack V2” (current/active)

  • A stale workspace pointer (b7781413-...) was cached as the default active workspace. This ID does not match either registered connector.

  • The feed agent config has the correct connector pinned, but the runtime session does not honor it at the invokeAction layer

Expected behavior: The feed agent’s runtime session should authenticate against the pinned Slack connector the same way interactive sessions do.

Impact: Complete loss of Slack visibility in the Activity Feed and context customization.. No DM notifications, no mention alerts, no monitoring.

2

Hi @shradsm and welcome to the Quick Community!

Thank you for the detailed diagnostics. The official troubleshooting path for connector authentication failures is to disconnect the service in Settings > Capabilities > Connectors, then reconnect by completing the authentication flow again. Given that you have two Slack connectors registered (“Devices Slack” and “Devices Slack V2”), I’d disconnect both, fully quit and restart Quick, and reconnect with just one clean connector to rule out any ambiguity in which connector the runtime is authenticating against.

If that doesn’t resolve it, the behavior you’re describing goes beyond what the action connector troubleshooting docs cover, I’d recommend opening an AWS Support case.

3

Hi @JacobR , thank for support. I did reconnection and manual reset from settings options. It temporarily makes connection and I can ping slack via individual chat, but activity feed monitoring is not working despite multiple manual reset. I changed team recently which changed my Slack workspace (Operations to Devices) and I am suspecting its not my local settings but connector still pointing to old workspace which is indeed access denied state due to my org change in system.
I will open AWS ticket to get this investigated. Thanks for quick help! :slight_smile: