Questions on capabilities compared to the deprecated Steps for Apps

[I-Dont-Remember]

Hello, I'm the developer of Workflow Buddy - the missing utilities for Workflow Builder, which is being impacted by the deprecation of Steps for Apps. I'm currently learning & exploring to see which utilities might be able to be ported to the new automation platform and have some questions.

• Q: For outgoingDomains, is there a way to allow a broad range of domains, or would every one need to be manually specified for the app?
  • One of our most popular steps is HTTP Request/Outgoing Webhook, for teams that wanted a way to hit any API from their Workflows - so the domain is defined as part of the Workflow. In my testing it appears that their is no way to "allow all" in the manifest.ts list of allowed domains.
  • Deno lets you call any hostname with deno run --allow-net fetch.js (so i tried using fetch.js in my manifest domains and nada), so I'm guessing that the block is happening in Slack's platform.
• Q: Are their plans to expose (or something I missed) anything similar stepCompleted/stepFailed actions?
  • It was quite powerful to be able to save the workflow_execution_id, do a bunch of long-running work, and then continue once it had finished. The 15 second timeout makes me think no.

[filmaj]

Hey @I-Dont-Remember ! Will do my best to answer your questions.

Q: For outgoingDomains, is there a way to allow a broad range of domains, or would every one need to be manually specified for the app?

Not currently, and the reason for this is to facilitate admin controls in a locked-down Slack workspace (e.g. an IT admin in a large corporation wanting to make sure no malicious or corporate-policy-violating apps/steps are installed in their Slack workspace). I think it's a good use case you bring up and I'll make sure to circulate this internally. Perhaps there are ways to "lower" the abstraction level this field exists at; instead of at the app manifest level, it exists at a workflow or function level to ease dynamic configuration of this field. However, the goal of this constraint is to give administrators control, too, so whatever change we consider, I think, has to take that into consideration.

Q: Are their plans to expose (or something I missed) anything similar stepCompleted/stepFailed actions?

Hmm, I'm not sure if I follow. Are you asking from the perspective of a new-automation-platform custom function? I don't think that would make sense in that situation, as the custom function receives a "function_executed" event, which it is up to the function to determine what the outcome is (whether it fails or completes, by returning specifically-crafted function outputs - see the return values listed in this doc).

Or are you asking from the perspective of a regular ol' bot-token-based app that you create via api.slack.com/apps? In this case, we are planning to invest more in this area so that these kinds of apps can hook into the new Workflow Builder UI in Slack (essentially by exposing the "function_executed" event to these apps), though we have yet to formalize our plans in this area.

[I-Dont-Remember]

Adding context on what we are trying to accomplish explicitly, but I think you've pretty much answered it - sounds like the custom functions are not intended to be 1-1 replacement of previous Steps, so I'll keep an eye out for future development with Workflows hooking into regular bots.

Context on use-case

When I was building Workflows, I missed having the ability to step through a program (or Workflow) and see the inputs/outputs to understand why it's not working like I expected, so we added a debugger to all of our Steps from Apps since Workflow Builder didn't have anything comparable.

How it worked:

1. Workflow Step execution event comes in. We pull out the execution_id that slack_api.stepsCompleted/Failed, then send it to the user in a Slack message button, along with the inputs the Step received for debugging 🐛.
2. Step execution code finishes, and explicitly does NOT call Complete/Fail, thereby leaving the Workflow In Progress🔂.
3. User can wait an arbitrary amount of time before clicking the button (in my testing it worked even days later).
4. When the user clicks the button, it finally sends the execution_id to the server, which will send the outputs to the user for debugging 🐛, then call Complete/Fail, letting the Workflow continue on as expected.

Example