Closed sukekyo26 closed 10 months ago
filmaj
commented
1 year ago Hello! Sorry that you ran into this. Can you tell me what kind of workspace you are in? Single, standalone workspace, or part of a larger enterprise / org / grid? And can you confirm that non-guest users in the workspace can run the workflow OK?
filmaj
commented
1 year ago May be relevant to standalone workspaces: assuming you have Admin access to your workspace, under App Management Settings (<your-slack-domain>.slack.com/apps/manage/settings), there is a "Multi-Channel Guests can only use default slash commands and shortcuts" option. Can you validate that this option is OFF?
sukekyo26
commented
1 year ago Thanks for the reply!!
The workspace I'm in is part of a larger enterprise / org / grid. Non-guest users of the workspace can execute the workflow without problems. I'm not the workspace administrator, so I will ask the administrator if that option is turned off. I would appreciate any other options you can think of.
sukekyo26
commented
1 year ago I'm trying to solve this problem in a workspace that is part of a larger enterprise / org / grid but I tried subscribing to the pro plan on my own slack account to see if the same problem with a Single, standalone workspace. When I execute a workflow deployed with the Next-Gen Platform as a guest user, I get the message "This workflow can't be run by external teams".(※1) The option "Multi-Channel Guests can only use default slash commands and shortcuts" is OFF. The workflow created by the Workflow Builder runs fine.(※2) Please note that I'm trying this with single channel guests due to the price of the slack pro plan.
※1 execute workfrow created by Next-Gen Platform App
※2 execute workfrow created by Workflow Builder
filmaj
commented
1 year ago I did some digging internally and indeed, this is something that we are currently limiting due to feedback we received from larger enterprise administrators. Initially, guests had access to run workflows, but admins got nervous, so we felt it was safer for our customers to turn this off.
We are working on a 'trusted team' / 'trusted user' feature that should address this issue.
sukekyo26
commented
1 year ago Thanks for looking into this. I understand the background. I look forward to the day when that feature is implemented!
filmaj
commented
11 months ago @sukekyo26 can you provide details as to what steps are in each workflow? You said the same workflow, but one built with code vs. the other built in workflow builder, have different runtime permission behaviour. That seems odd to me. Can you tell me what steps are used in each? And if a custom function is used in either, what scopes that function requires? I want to be 100% sure that the workflow-builder-built vs. coded workflows are identical.
FYI we also released a tweak to behaviour here for guest users running coded workflows last week, to align workflow builder-built and coded workflows better. Perhaps give this another shot in case that fixes things for your specific use case?
Note that this particular area - the specific runtime permissions for guest and away users for workflows using 'risky' scopes - is in active development, as we've identified potential areas of abuse in this space. I would expect further future communications in this area as I believe we can expect changes incoming for this general use case.
sukekyo26
commented
11 months ago @filmaj
can you provide details as to what steps are in each workflow? You said the same workflow, but one built with code vs. the other built in workflow builder, have different runtime permission behaviour. That seems odd to me. Can you tell me what steps are used in each? And if a custom function is used in either, what scopes that function requires? I want to be 100% sure that the workflow-builder-built vs. coded workflows are identical.
Sorry for the misunderstanding. the workflow-builder-built vs. coded workflows is not the same thing. I indicated that workflow-builder-built workflows can be executed by guest users as opposed to coded workflows. However, I now feel that this contrast is misleading. My apologies. Also, a few days after I opened this issue, I have confirmed that coded workflows without custom function can be executed by guest users.
FMI, My coded workflow steps are as follows. BotScope: commands, chat:write, chat:write.public, chat:write.customize Trigger: Link trigger Workflowstep1: custom function(Modal operation) →Client in use: views.open, views.update Workflowstep2: custom function(Send message) →Client in use: chat.postMessage Workflowstep3: custom function(Send thread message and modal operation) →Client in use: chat.postMessage, views.open, chat.update
FYI we also released a tweak to behaviour here for guest users running coded workflows last week, to align workflow builder-built and coded workflows better. Perhaps give this another shot in case that fixes things for your specific use case?
Thank you very much! I will try it.
filmaj
commented
10 months ago Hello ! Update here: guests should have the ability to execute workflows using 'risky' steps once more. We are still working on solidifying which exact scopes we consider risky for Guest users, so we have not documented specifically which scopes would be considered risky at this time. However, I can say that your workflow as listed above should now be executable by guest users.
I will close this issue but if you have further questions or problems feel free to re-open or file a new issue.
Hi When a multi-channel-guest user in a workspace runs an app (shortcut trigger) created in the next-gen platform, they get the message This workflow can't be run by external teams". I checked the command reference but couldn't find a solution. Is there any way to work around this and have the guest user start and run it?