Slack机器人跨工作区模态提交后发DM报channel_not_found

跨工作区调用报channel_not_found的本质原因非常明确：

• 现有代码硬编码了应用创建源工作区的Bot User OAuth Token，所有请求都共用这一个凭证，完全不符合Slack多工作区的授权隔离规则。
• Slack的用户ID、DM通道都是和所属工作区强绑定的，源工作区的bot权限无法识别其他工作区内的用户ID，自然定位不到对应的DM通道，直接返回通道不存在的报错。

这套方案不需要依赖Slack应用目录上架，完全适配当前至少两个工作区并行使用的场景：

• 搭建多工作区凭证持久化能力
  走Slack标准OAuth授权流程，当其他工作区管理员完成应用安装时，引导完成授权跳转，拿到每个工作区专属的workspace_id、对应的Bot User OAuth Token，把两组值存入自有业务数据库，以workspace_id作为唯一匹配主键。
• 按请求匹配对应工作区的凭证
  收到任意工作区的Modal提交回调时，先从回调payload中提取当前请求携带的team.id（即对应工作区ID），从数据库匹配出该工作区专属的Bot Token，替换掉代码里硬编码的全局token。
• 校验授权范围完整性
  安装应用时确保申请的权限覆盖chat:write、commands、users:read，这三个权限已经满足bot向对应工作区用户发送私信的要求，不需要额外申请多余权限。
• 改造后的核心代码逻辑

response = JSON.parse(params[:payload])
# 提取当前请求所属工作区ID
current_workspace_id = response["team"]["id"]
# 提取私信接收方的用户ID
target_user_id = response["user"]["id"]
# 从自有权限库匹配对应工作区的专属token
matched_bot_token = WorkspaceAuth.where(workspace_id: current_workspace_id).pluck(:bot_token).first

args = { channel: target_user_id, text: "A message" }
HTTParty.post("https://slack.com/api/chat.postMessage",
  {
    body: args.to_json,
    headers: {
      'Content-Type' => 'application/json',
      'Authorization' => "Bearer #{matched_bot_token}"
    }
  })

核心注意点：绝对不能跨工作区混用用户ID和Bot Token，Slack对跨工作区的资源访问有严格隔离，一旦凭证和当前请求的工作区上下文不匹配，就会触发资源找不到的报错。

这套实现逻辑完全贴合Slack开放接口的设计规范，后续如果需要上架Slack应用目录，整套凭证管理、请求匹配的核心逻辑不需要改动，可以平滑升级。

内容的提问来源于stack exchange，提问作者shiva