Slack Adapter: Support fetching Slack user email (`users:read.email`)

[Seventy7dot2]

Problem Statement

Currently the Chat SDK does not expose the email address of a Slack user in the event payload (e.g., message.author). This makes it difficult to implement domain-based authentication flows similar to integrations like the Google Drive Slack app.

In Slack integrations, apps can request the users:read.email OAuth scope and fetch a user's email using the Slack Web API (users.info). This is commonly used to map Slack users to accounts in an external system based on their email domain.

For example, the Google Drive Slack app allows workspace admins to connect a Google Workspace domain. Once configured, Slack users whose email belongs to that domain are automatically authenticated without needing to individually connect their accounts.

However, the current Chat SDK abstraction does not expose the user's email anywhere in the event context (e.g., message.author, event.user, or similar fields), which prevents implementing similar domain-wide authentication patterns.

Expected Behavior

If the Slack app has the required scopes:
users:read
users:read.email

the SDK should expose the user's email in a convenient location such as:
message.author.email

Proposed Solution

• Fetch email internally via users.info when resolving the Slack user.
• Optionally expose it when the users:read.email scope is present.
• Add the email field to existing user representations such as:
  message.author.email

Alternatives Considered

Currently I used a separate slack WebClient from @slack/web-api to implement this

Use Case

This would enable features such as:

Domain-based authentication

Auto-linking Slack users to external accounts

Enterprise SSO-like flows

Reduced friction for integrations requiring user identity mapping

Without this capability, developers must manually call the Slack Web API (users.info) outside the SDK, which defeats part of the abstraction provided by the Chat SDK.

Priority

Important

Contribution

• I am willing to help implement this feature

Additional Context

No response