Potential Step actions to add (partially based off of existing popular no-code flow tools)

[I-Dont-Remember]

Potential ideas seen in the wild for other automation use-cases (Zapier and n8n are good sources).

🤷‍♀️ = not really sure if this would be useful. Leave it here so there's a record.

• Wait/delay state
  • Workflow Builder does not have a convenient way to add a pause step - Workflows are long-running, so it should be no problem to have some wait action that doesn't run complete() until the duration has passed. The best solution for this may vary by hosting provider, or by integrating with a 3rd-party service.
• Filter/conditional stop
  • If a certain condition is not met, stop the workflow. Handy if you only want it to fire on certain conditions and the trigger isn't granular enough.
• Send email and/or SMS
  • Might be hard if they want it sent from their own address vs a generic SendGrid-type account.
• Calendar invites/sending with a link?
  • This seems like it's mostly covered through the Send a message built-in.
• ✅ JSON Extractor
• ✅ Pick random members from a conversation
• Suggested Slack actions based on Zapier
  • Add reminder
  • Invite user to channel - conversations.invite - bot must be part of channel to invite 1-1000 people.
  • ✅Send channel message (slack built-in)
  • ✅Send direct message (slack built-in)
  • ✅Create channel
  • ✅ Set channel topic (supposed to not work with bot token, but it has been?)
  • Update profile
  • Set status
  • Find/get message
    • User has to provide the channel ID as well as the message ts - see "retrieving Slack messages with conversations.history"
  • 🤷‍♀️ Search messages - wrap the query endpoint - seems hard to make UX good though.
  • 🤷‍♀️ Find user by ID
  • 🤷‍♀️ Find user by name
  • 🤷‍♀️ Find user by username

[I-Dont-Remember]

Idea: Allow querying SQL databases

This could create a lot of headache in 1) having necessary packages to support it, 2) people running into issues with with their query output as variables later in Workflow - either it's too big, not in the shape they expect, etc. Needs some thought before adding.

[I-Dont-Remember]

Idea: connect to OpenAI/ Stable Diffusion / etc

AI is big right now - people want to use it. Make it dead simple to do so?

🧠hypothetically the Outgoing Webhook step should be able to do this already, maybe we just need an example to show it off.

---

Current step hits API just fine! Issues:

• Don't have an easy way to parse out pieces of JSON into variables for workflows - that seems quite handy.
• Currently need to have your secure secret token just sitting in plaintext in the Headers section of Workflow Step - that means if you export/share the Workflow, it will leak that token. Also anyone that is a collaborator would be able to see it. Not necessarily a show-stopper for now, but important to stay aware of it.

[I-Dont-Remember]

✅ Idea: JSON extractor

Done in #41

When we get a response body from the Outgoing Webhook step (or wherever else JSON could come from), right now we just have a variable for the raw response, but don't have a way to easily let people parse out specific variables.

This might be useful as an option in the webhook step, as well as potentially a standalone. Letting people define a JSONPATH for a variable they want parsed out.

We are able to get creative with specifying outputs - we do this already by changing which "Action" is happening for our Step, we just need a simple way for user to specify a variable number of variables (ha! :D) they want parsed and what they want them called.

---

• At the save step step, we define the inputs and outputs that will happen during execution. Users could give us JSONPath expression and the variable name they want it called, then we can extract it and pass it as an output.

[I-Dont-Remember]

Slack API wrappers

There are some Slack API methods that seem like they make sense to expose through Workflow builder - I would hope Slack will eventually get to them, but for now may as well track if we build out any as measures to bridge the gap when/if that time comes to pass.

• ✅ Create a channel
• ✅ schedule message
• archive/unarchive a channel
  • This should be a relatively straightfoward one to add, since we already have channels:manage scope.
• chat.postEphemeral
• ✅ Add a reaction to a message (example: emoji triggered; then adds one after completion of doing X?)
• usergroups.users.update
  Update the list of users for a User Group (example: new user joins channel, add them to an existing usergroup)
  • Input: need a usergroup_id to call usergroups.users.list(), append our new user(s), then submit comma-separated list to usergroups.users.update().
  • Makes the most sense to let user find usergroup by name - but then we gotta use the list endpoint and search. This then becomes 3 API calls to list & search for ID, pull current users, and update with new user.
• users.getPresence
  Gets user presence information. (example: check if they are online before doing X)

---

• Convert channel into a comma separated list of user_ids like some Slack API calls expect - such as conversations.invite. Not really a wrapper, more just a handy utility.

[I-Dont-Remember]

Find Message

Slack's built-in Send a message doesn't return a ts variable or permalink to it, so if you want to use that message, you need to search for it. Some users are using Zapier's Find message functionality as a workaround to get the link of that recent message, but we should be able to handle it well within a Slack tool.

Get Message

This would be if you have ts, but really need the contents of the message for whatever you're doing. User has to provide the channel ID as well as the message ts - see "retrieving Slack messages with conversations.history"

[I-Dont-Remember]

Wait for Webhook

Extending the already in place Wait for manual completion step - workflow sits until some processing tool, like Zapier, has finished whatever it needs to do, then sends a webhook back to Buddy so it can continue the Slack workflow. Wouldn't need to save any state for execution, because we can require the execution_id to come in the request. We will need to come up with a simple way to tie the incoming request to the correct Slack bot_token, since we won't have that handled by Bolt.

⚠ In the longer-term, we should add some sort of secret key or similar that is required to use the execution_id to finish Workflow, but that would require storing state, and I'd like to keep Workflow Buddy Actions as stateless as possible.