Edited on July 11th to reflect Slack’s new, upcoming feature effectively deprecating this app. Although this app will be deprecated, I learned immensely on how to distribute Slack apps.
Slack does not allow users to schedule a threaded message without using custom code, thus forcing users to either send a message at an inopportune time or remind themselves at a later time to send the message. The client wanted this functionality to use with their own clients and partners, and even wanted to distribute this app to those same clients and partners.
To bridge this product gap, I created the Schread - Schedule Threads Slack app that allows users to schedule a threaded message. Users would select a message to schedule a reply to, write their message, select a date and time, and submit! Users would then have a dashboard that shows them all pending messages (date and time, link to thread, and message content) and allows them to reschedule or cancel those messages.
Modal allowing users to schedule their threads
Lessons learned
- Passing data using either
metadata
orprivate_metadata
can only go so far. The following Schedule Message API bug made me pivot into using a database.- ⚠️ Messages scheduled with chat.scheduleMessage will not post if the metadata parameter is used.
- Depending on the tokens you use, Org-wide installations might not be feasible. When trying to use an authorized user’s User Token, if the user installed the app across the Enterprise Grid then the User Token could fail. At the time of writing this, Slack is aware of this issue.
- To get around this, we had to prevent Org-wide installations and instead focus on individual workspaces.
- Creating folders for each type of listener (actions, commands, events, messages, modals, shortcuts, and views) is imperative as it helps keep your folder structure clean. It adds a bit more work, but knowing where to find each file instantly is worth it.