Building Admin-Approved Apps
Putting Message Buttons to use on a new Slack feature
So! We’ve just released Admin-Approved Apps. This setting not only helps admins manage the use of Slack Apps on their team — it also makes it far easier for users to find and request apps (like yours) from the Slack App Directory if their team has restricted app installs.
Admin-Approved Apps is the first native Slack feature to incorporate another brand new platform product, Message Buttons. Let’s take a look at this new way of managing Slack apps, and (hopefully) show you how Message Buttons can simplify routine workflows in Slack.
Start with the Job to be Done
Imagine a Slack team. Got it? Great. They look happy, don’t they? Now imagine that the owners of this team have chosen to restrict the installation of third-party apps to just team admins. Fair enough! But how might that choice impact people on that Slack team?
Now on this team, imagine one team member wanting to use an app they’ve found in the Slack App Directory. Let’s call him Ulysses User.
Ulysses isn’t the only character in this story though. An admin — let’s call her Amy Admin — also needs to be able to respond to Ulysses’s request: either approving or denying app installation.
That gives us two primary jobs to consider:
- A user requesting usage of an app
- An admin responding to that request
Packaging this into a workflow
We know Ulysses, our valiant user, is going to start at the Slack App Directory, so the first step in this workflow is to give him a button to click that requests permission to install an app.
But we also know our trusty admin, Amy, has a job to do, so the next step in this workflow is to send her a notification about the request with the option to take action. This is where Message Buttons come into play. A user requesting to install an app from the App Directory triggers Slack to post a message to the team’s administrators in a channel or DM (via Slackbot), with Message Buttons attached, ready to be clicked.
Take this one step further, and we can close the loop between the request Ulysses has made and the decision taken by his admin. If Amy decides to approve the app by clicking the green “Approve for Team” button, Slack updates the administrator’s message:
But that’s not all. Ulysses — the team member that originally sent the request — is also notified of the happy result and is prompted to install. Ulysses is delighted, because he’s got the app he needs to do his work. And Amy’s pleased, because she knows what apps are being installed and has the information she needs to keep her team working securely. Everyone’s happy.
Creating this feature with Message Buttons
By now you’re probably wondering how we actually did all this using Message Buttons, so let’s get on to the technical work behind Admin-Approved Apps.
We began with the “approval request message”, as our workflow here heavily depends on this component and it has the most pieces:
First, Slackbot message “text” introduces the request, and includes some basic message formatting that names the requesting person and provides the admin with a link to “View all pending requests,” you know, in case there’s a request (or two) they haven’t responded to yet.
Next comes the message attachment where the admin gets some much-needed context to help them understand the reason why a user wants to install the application. To make this message feel more personalized, we used the “author_name” and “author_icon” fields to display the requestor’s avatar and name. (ProTip here, but if you want to retrieve this information about a team member in another way, you can also use the users.info API method or Sign in with Slack).
Finally, we tell the admin about the application being requested, using “title”, “title_link” and “text” fields, and give the admin two “actions” with message buttons:
- “Approve for Team” is marked with the action’s “style” field as “primary” because it’s the choice we want to encourage. We’ve also assigned this button a “value” our servers will understand as an affirmative approval.
- “Restrict for Team” is a simple default style button. The assigned “value” indicates this app should not be installable for users on this team.
You probably noticed here that we chose not to include a “Do nothing” button. Well, as we saw it, there’s always the option to do nothing at all, and we didn’t want to actively encourage admins to ignore these messages.
So we’ve got some buttons…
Now, an admin will be left to just pressing buttons unless there’s an Action URL that actually does something based on their choice. We send the Action URL contextual information about the channel, the original message, and the ID of the user who took action, along with details about which Message Button was clicked. In this case upon click we check that the user is an admin allowed to approve apps, and then move forward if they are, or send an error message back if they are not. For third-party apps this context should be compared against records to check if a user has already linked their account to your app. An app with more information can better customize experience to users.
Upon an admin’s click and confirmation with the Action URL, our server responds to the request with an updated message, using the “replace_original” attribute to indicate that we want to update the original message with our response. This indicates to the admin that their choice has been made official and their work is done. From here we fire off another short series of actions to complete the workflow.
First, we update a database table indicating which apps are approved or restricted for the team. We assign this operation to a queue so that we don’t delay updating the original request message.
Next, to send the Slackbot message update to the team member who first asked to use the app, we use chat.postMessage. If the application was approved, we also include a link where they can install the now-unrestricted application. No time like the present!
Finally, and in case we need to make any further updates to the original message we sent to the administrator, we can use the action’s “response_url” or the chat.update API method to transition the message into any other states. In this case we usually do not update the message any further. If you are building with more complex workflow in Slack, this method allows you to continue updating the message as tasks are completed.
If you want to add message buttons to your app, you can read all about making messages interactive with message buttons. We are also always available on Twitter @slackapi and love to hear from you!
