Midas Touch, a Slack app built by Slack
A custom app success story
Early last year, our Sales Analytics team approached us with an idea for a new custom bot. Our Sales reps were spending many hours each week creating customer slide decks. They were building these decks by copy/pasting content from our BI tool into Google Slides. The work was repetitive and error prone — a perfect candidate for automation.
It’s so rewarding to tackle a great idea, design and build something that helps others — project name: Midas Touch, an ode to Greek mythology, going from good to gold!
Our Midas Touch dream
At its core, we envisioned Midas Touch as an integration between Slack, Salesforce (Slack’s CRM), Looker (Slack’s BI Tool), and Google Slides. Midas Touch allows users to search for customers in Salesforce and request a set of pre-populated custom set of slides, pulled from a Looker dashboard — all without leaving Slack.
With the UX work sorted out, next up was the magic — and potentially thousands of hours saved for our Sales & Customer Success teams!
Getting started
Our team leveraged existing tools and Slack apps that accelerate our product development cycle. We leaned on that principle as we started exploring ways to make Midas Touch a reality.
The first step was to ensure our goals were possible. A brief review of the Looker API docs clarified that pulling the data from Looker wasn’t a problem, but we weren’t sure how to insert that data into specific locations within each custom slide deck.
After reviewing the Google Slides API docs, we found two request-types that looked promising: ReplaceAllText, which enables search and replace in a presentation; and ReplaceAllShapesWithSheetsChart, which substitutes a particular shape (like a text box) with a linked Google Sheets chart.
With Google API calls set, designing the rest of the app was pretty straightforward. We set up two template files: one Slides file and one Sheets file. The Slides file contained variables surrounded by brackets for easy search-and-replace functionality, and the charts had textbox placeholders with their own variable names.
Accompanying each Slides file is a Google Sheets file that stores the relevant dashboard data from Looker. Charts for the slides would be in this Sheets file and the placeholder data is then replaced with the selected company’s data. In addition, we included the variable mappings, indicating which field in the Sheets file corresponds to a particular variable in the slides.
Building a prototype
Now it was time to test our design. We started with a two-page slide deck with four scalar variables and one chart.
With a tight timeline, we needed the fastest way to build this app. Our team was already familiar with Workato from past projects. Workato has a good selection of pre-built integrations — like Workbot, which interfaces with Slack to post and receive messages, listen for slash commands and handle most Slack API interactions without excess complexity. It also offers a Salesforce integration, which simplified the account lookup portion of our plan.
Workato doesn’t integrate with Looker or Google Slides, but it’s extensible, so we simply created our own.
Scaling our proof of concept
The proof of concept only used two queries — but the desired final output has dozens of queries. Separate queries in Looker were no longer feasible and needed a code change to add new data. We needed an automated process.
Through the Looker API docs, we found a way to pull all Looker data in a single step. Although there wasn’t an endpoint specifically designed for this purpose, we did find scheduled_plan_run_once — enabling us to select a dashboard, request, and download data to a zip file that we then delivered to a webhook. Setting up a webhook in Workato is simple, so this solution was a perfect fit.
Using this endpoint brought up the next issue: Workato couldn’t deal with zip files. As the dashboard grew in size, the list of .CSVs was getting longer so the Google payload for reading mappings and writing requests was increasing in complexity.
Thanks to prior projects using Workato, we found a workaround. Using a Django-based multi-app hosted on Heroku and a custom Workato connector generator, we were able to spin up a sister app and run custom Python code there.
During our research phase, we wrote a short Python script using the Python client library for Google APIs. This 100-line script was able to decrypt the Looker payload, unzip the .CSVs, copy them to sheets, read the mappings, and construct the requests to send to the Slides API in a large batchUpdate. Because the client library handled this complex process, our work was done.
Adding this script to the existing Django installation, meant our Midas Touch microservice was ready to interact with Workato with some extensions to Django’s REST API.
Due to Heroku timeouts and the length of time it took to run the process (1–2 minutes), Midas Touch needed a background worker — so we chose Celery backed by Redis. This event-based architecture ensured that no matter how large the payload, a user wouldn’t need to wait. Instead, the user sees an “in process” message and the files are delivered to them asynchronously.
Final thoughts
This multi-system, hybrid approach enabled us to iterate on our prototype, while offloading processing to a robust Django application and leveraging the Google-built Python API library.
This is a custom app success story, because it brought together many systems, teams, and projects to deliver an impactful product. Instead of reinventing the wheel, we creatively built upon existing tools and processes, and provided this complex system in just a matter of months.
Midas Touch is emblematic of successful cross-functional development. This integration is not possible without application engineering, sales, data and analytics teams all working closely together.
We look forward to building more custom apps like this with our amazing colleagues here at Slack. Read more about Midas Touch and its impact at Slack.
Questions? Email feedback@slack.com or tweet @SlackAPI.
