[BUG] Unable to pass team_id to built-in Slack function Schema.slack.functions.CreateChannel

[celso-vts]

Question

I'm trying to use Schema.slack.functions.CreateChannel in a new Deno workflow, and I want to know how I should pass the team_id parameter. It's something similar to how it's done with the Slack API client.

API client

client.conversations.create({
         name: "some-name",
         is_private: false,
         team_id: "myteamid",
});

Slack function CreateChannel as workflow steps does not accept team_id

createIncidentWorkflow.addStep(
  Schema.slack.functions.CreateChannel,
  {
    channel_name: "some-name",
    is_private: false,
    // team_id: "myteamid" <== this breaks the workflow
  },
)

Context

slack run works as expected, but when trying to create a channel, my workflow gets stuck. I believe it's due to restricted workspace permissions. I'm working on a "development" workspace, where I'm admin, so I want to make sure the function above creates a channel in the correct workspace.

Environment

cat import_map.json | grep deno-slack
    "deno-slack-sdk/": "https://deno.land/x/[email protected]/",
    "deno-slack-api/": "https://deno.land/x/[email protected]/",
    "deno-slack-hub/": "https://deno.land/x/[email protected]/",

deno --version
  deno 1.33.3 (release, aarch64-apple-darwin)
  v8 11.4.183.2
  typescript 5.0.4

sw_vers && uname -v
ProductName:            macOS
ProductVersion:         13.6.3
BuildVersion:           22G436
Darwin Kernel Version 22.6.0: Tue Nov  7 21:40:08 PST 2023; root:xnu-8796.141.3.702.9~2/RELEASE_ARM64_T6000

[filmaj]

Hello, indeed this is a problem in Enterprise workspaces. I will escalate internally to see how we can address this. My intuition is that triggers should probably include team_id and enterprise_id context data that can be passed to workflows and then to individual workflow steps. I will keep this issue thread posted with progress.

[filmaj]

As a temporary workaround, you could create a custom function that passes team_id to the conversations.create HTTP API. team_id and enterprise_id are passed as parameters to all custom function invocations.

[filmaj]

Interestingly this issue does not exist when creating a workflow using Workflow Builder, I believe because the form for the Create Channel step in WFB detects that the executing context is within a grid/enterprise workspace, and thus requires workflow creators to select a specific workspace within the enterprise. Of course that kind of guidance is not provided in the coded experience.

[celso-vts]

For the record, I was using the workaround you mentioned #267 (comment), which works.

[filmaj]

An update here: the team is working on addressing the bug with CreateChannel. We expect a resolution in the coming days. Once we release a fix (it will require a new release of this SDK), I'll update this issue.

[philblanchard]

I am new to Slack API/workflow apps and am working through the same issue described here when testing in my developer sandbox (enterprise grid). I assume this issue would not exist if I were running this in a "business" tier sub?

As a temporary workaround, you could create a custom function that passes team_id to the conversations.create HTTP API. team_id and enterprise_id are passed as parameters to all custom function invocations.

I might be missing something obvious, but when I declare team_id context prop in my custom function, and reference this for team_id value in conversations.create API, I am getting team_access_not_granted error. The team_id context var is like EXXXX. However, if I navigate to this workspace and grab the "team id" value that starts with T and hardcode that into my function it works as expected.

Any insight would be appreciated

[filmaj]

@philblanchard is your app installed to the org, or to a workspace within the org? That might explain the difference in the first letter in the team_id context variable; EXXX is an enterprise, or org, ID, while TXXX is a team/workspace ID.

In either case, you receiving the enterprise ID as team_id is a problem, but let me know and I'll look into it further.

[philblanchard]

@filmaj -- I would suspect it is only installed to a workspace within the org, as that is the option I've selected through the Slack CLI. Another thing to note is that when I log the enterprise_id context var value there is no value present, while the team_id is the enterprise ID.

During the slack run step to run this app locally, when I am installing it to a specific workspace, the team ID is shown next to the workspace I select.

I guess also FWIW if you do a slack auth list the Enterprise ID of the org you'd auth'd into is shown as a "Team ID", which it seems is not the same thing

[filmaj]

Yes, I did some further testing here myself. I believe there is a problem with how the backend sends the team ID (or rather: how it does not send the team ID) for certain events to workflow apps. The same team_id and enterprise_id mixup seems to exist on different kinds of events: block actions, view submission/closed as well as function_executed.

Not sure what execution context / event you are seeing your issue in, but in case it is from a block action or view event, you can find the relevant team ID under body.view or body.message (for view and block events, respectively). Unfortunately it seems like for the function-executed event, we do not send the team ID in any form. I will raise this internally to see if we can get that fixed.

[ChrisMcKee]

Is there any timeframe on when they'll fix the api so it starts to either pass it, or at the very least so the CLI starts to set the correct team-id

My sandbox workspace config ends up like

{
  "E0776TLA88G": {
    "app_id": "xxx",
    "enterprise_id": "E0776TLA88G",
    "IsDev": true,
    "team_domain": "cm-xxxx",
    "team_id": "E0776TLA88G",
    "user_id": "U076F75ED6Z"
  }
}

But the app-install response correctly states

App successfully reinstalled
[2024-06-05 16:49:19] received: {"envelope_id":"2e43fb60-4cb0-4239-9365-1aa8f8034a03","payload":{"type":"block_actions","team":null,"enterprise":{"id":"E0776TLA88G","name":"cmbotsandbox"},"user":{"id":"U076F75ED6Z","name":"sd0776tdeq7j_user","team_id":"T076J49RGKC"}

The BaseRuntimeFunctionContext team_id is the same as the enterprise_id instead of being set to the team_id. Having to get around it using team_id: env["TEAM_ID"] || team_id || undefined,

[filmaj]

I've moved the discussion around how to get a reference to a correct team_id in an org context over here: slackapi/deno-slack-runtime#65

This way we can keep this issue for exposing team_id as a parameter to the CreateChannel function, the original issue filed here.

[filmaj]

This issue is resolved now that CreateChannel accepts team_id as parameter.