This is the fifth blog post of a five-part series.

Building a Slack app that integrates with Salesforce involves some challenges, such as knowing the right integration capability to use on each case, picking the right authorization flow, and implementing it securely. This is the fifth blog post of a series in which we cover the whole process of creating a Slack app that integrates with Salesforce from scratch. Learn along with us while we build Ready to Fly, our new sample app for submitting and approving travel requests in Salesforce without leaving Slack.

Note: some parts of this app have been live coded by my colleagues Mohith Shrivastava (@msrivastav13) and Kevin Poorman (@codefriar) in their codeLive video series: Building with Slack.

Check out the rest of the blogs in this series here:

• Part 1 – Architectural Overview
• Part 2 – Bolt
• Part 3 – Integrating with Salesforce
• Part 4 – Local Development and Debugging

The Slack-Salesforce toolbelt

Since Slack was acquired by Salesforce, both platforms have been making efforts to simplify the way in which they’re integrated. We’ve been working on substantial number of low-code and pro-code tools that will connect Slack and Salesforce seamlessly.

But as I am a developer, I want to tell you a bit more about the feature that will be a game-changer for Salesforce Developers: the Apex SDK for Slack!

Apex SDK for Slack (pilot)

To help you build apps that integrate Salesforce with Slack much easier, Salesforce is working on a native SDK for Salesforce Developers that’s currently in closed pilot for ISVs: the Apex SDK for Slack. We announced the pilot (when it was still codenamed Foyer) in September, and since then, it’s been evolving rapidly.

If we were to refactor Ready to Fly to use the new Apex SDK for Slack, the Node.js app that we used as middleware would completely disappear, making it much simpler to build the app and reducing delivery time.

One of the greatest benefits of the Apex SDK for Slack is that user mapping and authorization are implemented securely, out of the box. That means that we could get rid of all the Node.js custom code for authorization mechanisms that we implemented for Ready to Fly as explained in part 3 of this series (Integration with Salesforce). What a big win! User permissions, language, and localization settings will be enforced for the logged in user. Additionally, it’s on the roadmap of the SDK to be able to support multi-org connections — something that would be quite hard to implement with custom code.

Another major benefit is that you will be able to work with Slack APIs directly from Apex. You’ll be able to take advantage of your Salesforce developer skills to build Slack applications, making the learning curve much shorter. We’ll expand more about this in the next section.

The Apex SDK for Slack will also enable packaging and distribution of applications via the AppExchange and Slack App Directory. If you’re an ISV, this is what you were looking for.

Sneak peek of the SDK

Let’s get a sneak peek of the experience of building a Slack app with the Apex SDK for Slack. The regular workflow to create an app will be:

1. Create a Slack app at api.slack.com
2. Write logic in Apex
3. Map your Slack app features to your code
4. Deploy the Slack app to a Salesforce org of your choice using the new slackapp metadata type
5. Authorize the Slack App by connecting from Slack to your Salesforce org
6. Optionally build, package, and distribute your app on the AppExchange and the Slack App Directory

As mentioned, slackapp will be a new metadata type in which you will be able to bind actions defined in Apex to handle commands, shortcuts, and events from your Slack app in YAML format.

|_ slackapps/
|_ MySlackApp.slackapp
|_ MySlackApp.slackapp-meta.xml

For instance, this could be the code to show a modal when the create-travel-request global shortcut is clicked in Ready to Fly:

What about the views? A view will be a root component that displays in a Slack surface, such as a Home tab, message, or modal. In a Slack runtime environment, the view metadata translates to blocks. If we go back to Ready to Fly, this could be the modal view that is shown when you want to create a travel request:

Views will be able to have data providers, defined in Apex, to show Salesforce data. In Ready to Fly, we could use a data provider to show the travel request records that are pending review.

In summary, the Apex SDK for Slack will do all the heavy lifting for you, and you’ll be able to create apps almost without going outside of Salesforce. Here, you have a more detailed diagram of the SDK architecture that includes handlers, views, and data providers.

Wrapping up

That’s all for this blog series! I hope that you’ve enjoyed reading the five posts. Now, you have a much better understanding of the key points to know when building an app that integrates Salesforce and Slack.

Remember to take a look at the Ready to Fly app code, and if you plan to build an app from scratch, use the Salesforce Slack Starter Kit that my team created.

I also hope that you’re excited about the amazing features coming soon that will simplify this process. To enroll in the Apex SDK for Slack pilot, contact your technical account manager.

About the author

Alba Rivas works as a Principal Developer Advocate at Salesforce. She focuses on Lightning Web Components and Lightning adoption strategy. You can follow her on Twitter @AlbaSFDC.