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.

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.

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.

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

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.

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

@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.

@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

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.