As a software engineer with a specific problem to solve, Rea Loretta wasn’t thinking about scale, or branding, or enterprise solutions. She needed a communications tool that her small team could use to eliminate coding bottlenecks. So, she built one.

In the years following, her Slack app known as Toast would become a must-have tool for software development teams around the world, including enterprise-level clients with 1,000+ engineers. By integrating essential GitHub processes into the Slack workspace, Toast makes it easier to keep tasks moving through the programming pipeline, eliminating the inefficiencies of micromanagement.

For the third installment of our On the Platform interview series, Rea and I talked about the early days of Toast, the future of remote work and the value of virtual programming communities.

The following is a condensed transcript of our interview; answers have been edited for length and clarity.

Tell us a bit more about Toast, and how it got started.

We first got the idea for Toast in late 2018. It was me and two engineer friends … similar to a lot of other startup stories from San Francisco. We were still trying to figure out all the engineering processes. It became clear that communications was where the big bottlenecks were.

We never meant to be a company. We just had this communications problem to solve for our own team. So we naturally decided to work inside of Slack, because it was already the hub of communications.

It was very basic in principle, just a messaging service that could provide some value for our business. From there, we were able to discover more issues involved with building an engineering team.

What does your day-to-day look like?

Beyond being CEO, I’m also an engineer and designer. So my day-to-day is learning about the problems our customers are facing, prototyping new features and playing with new toys from the Slack API team. I basically leverage that first-hand access to Slack API to provide even more visibility and usability for our customers.

You mentioned that Toast wasn’t intended to be a business. When did you make that flip, and what has that journey been like?

It was at a holiday party of all places. I was not prepared as a founder to be pitching to people; that’s not why I was there. But then people start asking you where you’ve been, or what you’ve been working on. I started talking about what I was doing with Toast.

Before long, people were tapping me on the shoulder and asking what I was talking about.

When you’re talking about something that you’re passionate about, it just really comes through. People were really interested in the fact that I was building for Slack.

Why did you choose Slack as a platform, especially with everything else that exists?

From the beginning, Toast has always been an integration company. Because I had done so many of them, I knew that Slack was the benchmark on what it means to work an integration with another company. The documentation is really robust and unique.

Then there’s the helpful people like yourself and the Slack internal team. I’m continually impressed with how quickly you all can move. It’s not like working with a customer service rep who is going to put me on hold and say “I’ll get back to you next week.”

You’re also one of the founders of the San Francisco chapter for Slack Community. What prompted that? How has that experience been starting a Slack Community chapter?

It all started because I was hacking together a Slack app. I knew right away that I was going to run into a lot of issues. Even though Slack had phenomenal documentation, I couldn’t just read it all at once.

Back then, there was a Slack workspace called Developer Hangout. A lot of other Slack engineers were on there. I made new friends and was able to share some pieces of code, which was new for me. I wasn’t ‘out there’ as an engineer; It wasn’t my space yet. But it was my first foray into public coding. That’s when I found out that there was a way to drive the community and surface our concerns in a formal way, while supporting and nurturing other struggling developers.

Not all developers find that on their own. I wanted to make a home where we could grow together. It’s a place to explore.

What was it like trying to drive a virtual community through something like COVID? Do you think virtual events are getting any better?

The one cool thing about a virtual community is that a lot of the stuff we’re talking about is the same. Time zones aside, the problems we’re trying to solve here are the same problems that they’re trying to solve in India. It’s something everyone can relate to.

Founder isolation is a real thing. Then there’s COVID isolation on top of that. It’s amazing, the energy you get from other people that are overcoming the same challenges. In a way it lends itself to a virtual community, and even a global one. Everybody gets help feeling good about what they’re doing. We’re all struggling together, we’re all growing, we’re all overcoming.

You’re not just the founder and CEO of Toast … You’re also a designer, engineer and now a Slack Community leader. Is there something that appeals to you about that context switch? How do you go about embodying those different roles?

I was pretty unintentional about that in the beginning. I think that’s how a lot of founder journeys go. It’s a combination of imposter syndrome, and then the revelation that you’re doing 20 jobs inside one company.

It becomes a personal responsibility thing. I have my day-to-day, but I also work well with sporadic bursts of energy. That’s when I throw my day-to-day out the window and try to solve a problem with a mini hackathon.

Everything is a lot simpler because of Slack. I start with a hand-drawn concept in my notebook, then send that to Block Kit Builder. I go from there to working on our data model and databases. Then I send that to Slack API and they deliver it directly to the users, so I can work on some of those interactions right away.

That’s one day of prototyping. If not for code review, I would be able to ship a new feature out by the end of the day.

What has the growth been like, in terms of users and scale?

We’ve actually had a lot more customers because of the pandemic. We’ve had to question what that means for us, accounting for API limits and how to deal with the flood of data from large teams. We never thought we’d have a customer with 1,000 engineers on GitHub.

We’ve managed to overcome the scale issues by making some elegant changes in our own infrastructure.

Are there other changes that you’re preparing for with the switch to a hybrid workforce? Any hopes and dreams for the future of work?

For us, Toast was always about solving time inefficiencies. When a piece of work is ready, it’s value is best served by moving it right along the engineering pipeline. If it’s ready to be merged, then it needs to be merged.

But managers and higher-level executives want to be subscribed to the issue. They will track the issue from this person’s plate to that person’s plate, and so on, peeping over their shoulders. It’s micromanagement, and it’s not just a problem that remote companies face. It was a problem that needed to be solved anyway.

Now, people are starting to learn about efficiency solutions like Toast. Even if we all go back to the office, I think people will take this kind of thing with them.

Besides Toast, are there any other apps that you admire from a UX perspective?

One of the old-school apps that we always looked up to was Geekbot. They had a lot of innovative ways of building in Slack, and using the Slack API for non-conventional means.

What’s your favorite Slack feature that you think people should know about?

You probably hear this often, but it’s the ability to make custom emojis.

Yes, the amount of emojis I upload to the Slack workspace is ridiculous.

It’s a low-effort, high-impact way to incorporate culture into your company. I made a sticker pack for myself to use, all engineering humor related. Now it’s in a lot of the workspaces I’m in. I’m able to inject culture across multiple workspaces. It’s such a fun way to customize things and build with positivity.

Any advice for people who are interested in building for the Slack API?

Don’t worry about whether or not your concept is enterprise ready. If you want to build something just for yourself, go for it. Make it the best that you can for yourself. After all, you’re the first user. Then allow other people to try it, and see where it goes. If someone is really excited about it, you can worry about the enterprise solutions later on.

As engineers we put these roadblocks in front of ourselves. The truth is, the process of getting an app approved for the marketplace is not that hard. It’s actually the easiest part of the process.

Go build it. Let your beta users give you the hard feedback; they’ll become your champions in the process. That’s how you grow.

As always, we are here for you. Never hesitate to email feedback@slack.com.

On the Platform: Toast CEO & Engineer Rea Loretta on Driving Virtual Community was originally published in Slack Platform Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Erin Blaskie was only six years old when she got her first computer, a Commodore 64 that her dad brought home for the family. When it came to computers, the Blaskies always seemed to have the latest and greatest, even if they weren’t, as she says, the kind of family that could afford it.

Like a lot of people from our generation, Erin got off to an early start in the blogging realm. LiveJournal led to Open Diary, Open Diary to GeoCities, GeoCities to MySpace. It didn’t take long before she realized what we all did: The internet was going to completely change the ways that we create, nurture, and maintain communities.

Today, Erin Blaskie is a consultant and serial entrepreneur that has worked with over 300 businesses. This year, she’s stepping out on her own once more, launching a Fractional CMO firm dedicated to helping startups, marketing teams, and VCs leverage the power of the internet to nurture community-led growth.

For the second installment of our On the Platform interview series, I sat down with Erin to talk about the lessons and challenges that 2020 brought to the growth marketing game, as well as what it was like to launch an all-new Slack Community chapter in her home town of Ottawa.

The following is a condensed transcript of our interview; Answers have been edited for length and clarity.

You’ve spent the last 15 years doing marketing work for various companies and personal brands, many of them in Silicon Valley. How did you find your fit in the startup community? What is it that you like about that atmosphere?

I started my first company in 2004. Back then I was bidding on projects through Elance (now Upwork). My first Silicon Valley client was this guy with an ebook company. He had one about beauty secrets, and another about Texas hold ’em tips. He took a very simple idea, and with the marketing plan we came up with, it wasn’t long before he was making bank.

It was really fascinating watching companies like these grow from the ground up. I got this incredible passion from these people about the power of internet marketing. I saw firsthand what an enormous role marketing can play in growth.

I love the early days, the “art of the start”. I’ve always been entrepreneurial, and I’ve always been drawn to entrepreneurs in general. It’s like a gravitational pull.

You’re no stranger to working remotely. What lessons have you had to learn to make it all work?

I worked remotely for a long time before I landed at Fellow. But honestly, I wasn’t always good at the time management thing. It’s been something of a journey.

I had my first daughter while I was working remotely for my first business. Overnight, my life changed a lot in terms of what I had to balance and how much time I had to balance it in. I had to get really good at project management, and quickly.

The first thing I learned was about systems and processes. Everything needs to be systemized. Everything needs a process in place.

Delegation is the second thing, and I learned that one really late. When forming this new company, I knew that I wasn’t going to go it alone like last time. The first three calls that I made were to an accountant, a lawyer, and a virtual assistant.

Boundaries are another huge key. With remote work, it’s so easy to bleed the lines. There’s no 9 to 5 anymore; It’s all amorphous. With both my clients and my team, I just need to be cognizant and shut the laptop at some point, so I can give that time to my family

It seems like everyone is looking for that ‘miracle app’ that will solve all their problems, and maybe make remote work a little easier. Can you recommend an app that has made your life easier?

For me, and probably for a lot of other people, the remote working environment is not going away. My clients are all over the place, so all the conversations are going to keep happening virtually.

For this reason, absolutely everything I do stems from Slack. Between all my clients and projects … I can’t even tell you how many Slack channels I’m in.

But what I really love is looking for other apps that can sync into my ecosystem. ClickUp is a product management tool that syncs beautifully with Slack. I also still use Fellow for meeting agendas and meeting notes. That one I can’t live without.

Earlier this year you shared your passion for Slack with your hometown of Ottawa, by opening a new local chapter of Slack Community. What was it like to grow a community in the midst of a pandemic?

It was great to bring something unique to the city. Along with my co-lead, Alexandra Sunderland, we were able to host two in-person events before the pandemic set-in. We tried to get a broad collection of Slack enthusiasts together. With my marketing background, I was able to find people who just love the platform and want to learn more. Meanwhile, Alexandra is an engineer and was able to capture the heavier technical crowd, the people who were building workflows.

Ottawa doesn’t have as much of a startup scene, so we had to really explore our demographic. Fortunately, Shopify is located here, and that became a great anchor for us in terms of a partner and a venue. We also tapped all the accelerators on the shoulders, and brought their people in.

The pandemic hit, and obviously, that changed everything. We started hosting virtual events, but not as many as we would have liked. The turnout was great, and we were able to find some great speakers.

Speaking of post-pandemic, what’s your vision of the future? How do you think the world is going to change in terms of the way we do work?

For the first time in a really long time, we’ve all had an opportunity to put our priorities in perspective, and see what’s really important. We’ve been able to understand and feel the work-life balance like never before.

One thing that needs to change is the sheer number of meetings and calls in general. Before the pandemic, we were handling a lot of quick things via phone, email, or Slack. Now, video is the default for everything. We need to make sure that we’re saving time for deep work, which means shutting off the distractions and notifications. That can be hard, but it just requires more boundary setting.

It’s going to be interesting as we move out of the pandemic to see what happens to different companies. We’re already seeing the articles coming out, about companies saying “It’s time to come back into the office” and employees saying, “Nah”. These people are quitting their jobs because they don’t want to go back to the way things used to be done.

Post-pandemic, companies that have hybrid or remote-first environments need to focus on intentionality.

Have you seen any examples of this kind of intentionality working really well?

I think for most of us we’re still in an experimentation phase. I’ve seen a lot of people try stuff on, but some people are really leading the charge.

It’s just about having someone on the team who is focused on the aspect of remote work, or just culture in general. GitHub is a great example that comes to mind. Darren Murph, oh my gosh. He’s their Head of Remote. It makes so much sense to have that position.

Shopify is another great example. When the COVID restrictions hit us in Ottawa, they went immediately to digital-first, and they’re staying that way. They’ve already let go of a bunch of their office space, which is now being turned into a coworking space.

I also really like Drift’s CEO, David Cancel. They had him before the pandemic, but I’ve always really liked his approach. He leads with such transparency. We need to lean on leaders that are more open and transparent with their practices.

Last question: What’s your favorite Slack tip or feature that you would recommend to other users?

This is a little embarrassing to admit because it’s so simple. I remember telling my Slack Community co-lead Alexandra, “I wish I could organize my DMs and threads into groups.” She just looked at me like, “You don’t know?”

She showed me how to clump things together the way I needed. I can hide the threads and conversations that aren’t as critical, and keep the important stuff at the top. It’s such a simple thing, but for someone who likes to be so highly organized, it was a true game-changer.

As always, we are here for you. Never hesitate to email feedback@slack.com.

On the Platform: Entrepreneur & Fractional CMO Erin Blaskie on the Evolution of Growth Marketing was originally published in Slack Platform Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today’s the day! Slack is part of Salesforce. What does this mean? We’re still the Slack you know and love — now connected to the most open and interoperable ecosystem of enterprise apps and workflows. Read on to learn more.

A transformed world of work

Over the past year, we’ve embraced the power of flexibility. Every business in every industry now has to evolve to meet their customers, employees, and partners in a digital-first world. We know that with the right tools, we can be productive from anywhere — and this is our opportunity to reshape everything about how and where we work.

Salesforce enables any company to sell, service, market, conduct commerce, and more from anywhere. And with Slack, your entire organization is far more connected, engaged, and productive. Together, we’re shaping the future of enterprise software, creating the business operating system to lead this historic shift to a digital-first world.

We also create the most extensive open ecosystem of apps and workflows for business, including more than 8,000 apps available from partners. With this increased scale, we see even greater opportunity for millions of developers looking to build the next generation of apps — with clicks, or with code.

A more powerful platform

With this digital-first shift, it’s critical we stay aligned and connected across our people and information, which can be challenging given the proliferation of software and tools within most enterprise organizations.

Slack connects conversations, apps, data, and workflows in ways that make work life simpler, more pleasant, and more productive. We’ve seen companies like IBM use both Salesforce and Slack platforms to build robust and powerful integrations between their software and systems.

Our vision for our platform is to enable every Slack customer to be an event-driven enterprise — with Slack serving as the engagement layer for all system and human events, integrations and automations, code and no-code solutions that keep your people and tools tightly aligned. The goal is to make it easier than ever for anyone to build solutions that ignite transformation within a company — ensuring that in this digital-first world, work moves forward and everyone is empowered.

This is happening already — today our developer ecosystem builds incredible event-driven apps on Slack, from onboarding employees faster, to managing incidents in record time.

And accelerated by today’s announcement with Salesforce, this vision will soon take a major step forward as we work to deliver groundbreaking changes to the platform.

A note of appreciation

As head of product for Slack’s developer platform, I have an unusual perspective on our joining Salesforce: I previously sold a process-automation software company to Salesforce, and helped build the go-to-market strategy for the Salesforce platform. I know from experience that with Salesforce’s support, we’ll have the resources to bring you an even better Slack.

We’re always investing in our platform and in you — from our recent re-launch of slackcommunity.com, to our largest-ever re-architecting of the platform. You’ll be hearing more about both of these exciting announcements this October at Slack Frontiers. And more to come here on the Slack Platform blog.

And I personally want to thank you each and every one of you — for what you’ve built, automated, coded, and created to-date. Thank you for bringing your very best to us, as we’ve introduced new features, deprecations, betas, and countless developer success stories. We’re excited to amplify your work and showcase your creations on a bigger, better world stage. On behalf of our whole Slack platform team, thank you for taking this journey with us.

As always, we are here for you! Tweet us @SlackAPI with questions or feedback, and keep tabs on the latest by joining the Slack Community conversation.

Salesforce acquires Slack was originally published in Slack Platform Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

On the Platform is a new series where we’ll host members of our platform community — from developers, to chapter leaders, to folks building their own enterprise business. I’m Shay DeWael, a Senior Developer Advocate at Slack, and each month I’ll chat with members of the Slack community about a variety of topics that surround their personal story and thoughts on building the future of work.

Back in 2017, London-based software engineer Wilhelm Klopp found himself bunked in a crowded room at a German hostel along with seven strangers in town for the same conference. The crowded cots and pungent smells led him down a path familiar to many young hackathon attendees: He found a corner in the lobby and built a prototype of Simple Poll.

Motivated by difficult experiences of reaching consensus with his team, Simple Poll began as a bare-bones polling app for Slack. It didn’t take long for it to become a hit; Within days, Simple Poll was giving hundreds of workspaces a new way to “keep their fingers on the pulse” of their teams. Since the first version, Wilhelm has continued to grow Simple Poll with new feature-sets and a continued investment in a Slack-first experience.

Wilhelm joined us to share his experience about building Simple Poll, as well as the increasing value of automation in a remote-first environment.

The following is a condensed transcript of our interview; Answers have been edited for length and clarity.

What made you want to work with the Slack API? Walk us through the early days of Simple Poll.

In the early days, my prime motivation was to get a job with Slack. What better way to do that than to build something specifically for them?

From the beginning, what drew me to Slack is that it’s an enterprise software that feels like consumer software. The UX was really polished. Simple and straightforward. That’s what I wanted to do with Simple Poll, to create something that felt like it was made for the end user and not just the buyer. But at the same time, it needed to be a tool that could meet big enterprise challenges.

It really speaks to the power of the Slack API. I don’t need to keep up with complicated documentation that changes every few minutes in the goal of serving some big enterprise need. Building an enterprise app would be a lot harder without that consumer-level base layer.

Over the last year, the shift to remote work has brought a lot of changes to Slack in terms of usage and engagement. What’s changed with Simple Poll in terms of users and the product as a whole?

COVID itself is the first thing that comes to mind. Some of our most active new user behavior was COVID-adjacent usage … Things like COVID research groups creating polls to coordinate virus tracking or medical efforts.

But the broad usage changes from the shift to remote work, like you said, those are probably here to stay. Before COVID, the leading case we used in our marketing copy was the “lunch” use case. You can use Simple Poll to ask your team, “Where do you want to go to lunch today?” Then your team could cast their votes in-channel, based on the options you entered. But obviously, this example doesn’t work as well when everybody is working from home.

What about hybrid or remote-first usage? Has there been any change there?

We have seen big changes in both of those. Our hybrid use case is the manager who creates a recurring daily poll that asks, “Who is coming into the office today?” It posts automatically at 7am, and the team submits their answers in-channel. It’s a good sense-check on what the day is going to be like.

For remote-first users, the feedback-loop case is the big one. Pre-COVID, a good manager had to remember to check in with their people regularly in order to establish that feedback loop. To ask, “Hey team, how are you feeling today? Good? Bad? How’s your mental health?

Now, our users are creating polls that automate that feedback loop. It doesn’t take good team management out of the equation, but it does reduce the friction on the team lead. This concept is what got us started building out the Surveys product.

Simple Surveys was a big step for your product. Can you tell us more about that?

With the big shift to remote work in early 2020, we had a lot of users requesting a more extensive and confidential way to interact with their team.

Simple Surveys was our response. This is a type of poll that isn’t posted in a channel, but goes out to a manually selected group of users. It has a lot of the same functionality as Simple Poll: It can be anonymous, private, plain text, multiple choice, checkboxes. But only the person who created the survey can see the results.

Speaking of Workflow Builder, how are you approaching that from a Slack app perspective? How does Simple Poll fit into the Workflow Builder realm?

Our default approach to Workflow Builder is that if there is a new capability that is even remotely relevant to Simple Poll, we’ll build for it. That enables our users, both in the medium and long term, to achieve better integration with a greater number of apps.

Where things become really interesting is steps for apps. Without requiring any code, users can add custom steps into their workflows that can be executed by different apps. When a Simple Poll is closed, that can trigger a workflow for something else to happen.

The “Create poll” step fits neatly into any workflow where it’s important to gather quick input from your team.

Results can be automatically shared or updated to Google Doc, for example. Or, if a Zoom all-hands concludes and that shows up as a notification, immediately afterwards it can send a poll or survey in that channel to all attendees. This is a very popular use case now that we’re remote.

Slack is the pulse of the organization. After Zoom, you go back to Slack. So that’s where you should immediately be asking for feedback. I’m really excited for the future of workflow triggers by Simple Poll, as well as other Slack apps.

To change gears, how do you see the remote work shift going now that we have the tools to more intentionally engage with it? What do you think the next few years will look like?

In the rush to remote work, everything became less intentional. We mapped everything 1-to-1, which really wasn’t making the best of the new world that we were entering.

When I was with GitHub, everything was very asynchronous even before the pandemic. We had people spread across time zones, which meant that work was happening in a way where some things were blocked if they involved other people.

But these slower, long-form conversations actually unlocked a deeper side of thinking, thinking that could get lost in meetings. It gave everyone a chance to chime in, especially those who were in different time zones, or who were simply less commanding in meetings. I think there will be more of that. There needs to be more of that. A new approach to a new world.

Polls are a lightweight way to open up dialogue with a group.

How do you see Simple Poll handling that new approach?

I think with tools like Simple Poll, there is a big opportunity to help folks do the right thing by default. As a Slack app, we’re right in that critical path of where communication happens. If we can guide users to the directionally correct path from the start, without the manual effort, we can reduce more friction.

Take those famous Gallup survey questions. “Do you have the tools to do your job?”,” Do you have the materials and equipment to do your work right?” That kind of thing takes manual effort. But if you had those systems by default, it all comes down to one click. You can start with something and tweak your needs, rather than start from scratch.

Which is your favorite or most used Slack app besides Simple Poll?

I can probably cheat and say GitHub, but that’s probably not what you’re looking for.

Simple Goals is one. It’s like Simple Poll in that it brings our team’s goals into the workspace where they’re just one click away, not ten or fifteen. We do a retrospective with the team every 6 weeks, and Simple Goals reminds us of our action points for the quarter.

Donut is great for finding time to meet with people. This is especially true in community-based Slacks, I’ve been seeing a lot of that.

What advice would you give to someone who is building an enterprise app for the first time?

Enterprises care a lot about data security. So, I’d say make sure that you’re using the minimal amount of data that you need to provide your experience. This can be tricky when adding features and needing to grow. But a big part of our early success with Simple Poll was that it required so little in terms of data.

One key component is working closely with your users’ Slack admins. A lot of Slack admins have the reference point of wanting to help their employees get the best out of Slack. Help these people help their users, and they’ll become your internal champions.

Aiming for a decent onboarding experience is another one. With something like Slack, you have a huge opportunity to expand someone in the workspace. So, plan that path, and share it with everyone else so you can really bring people in.

As always, we are here for you. Never hesitate to email feedback@slack.com.

On the Platform: Simple Poll’s Wilhelm Klopp on the power of the Slack API was originally published in Slack Platform Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Calendly, we aim to make scheduling easy. You keep ownership of your calendar and time while sharing your availability with others, simply by sharing your Calendly link. But to make it as easy as possible, Calendly needs to be wherever people get their work done, and for many people, they get their work done in Slack.

Slack has transformed workplace communication and made working together easier and more productive. We heard from our users and from Slack that now more than ever, people want the simplicity of Calendly scheduling seamlessly integrated into Slack.

Slack released Slack Connect, which will further transform the way we work with people outside of our organization by opening up externally facing channels of communication. Calendly’s focus is to help people outside of their own organization connect with each other. Naturally as Slack pushes forward with Slack Connect, we felt that Calendly should be an integral application to help users be more productive when communicating outside of their organization.

Keeping it simple

We want to make sure using Calendly in Slack would be easy and intuitive. There’s a lot of ways we can continue to make scheduling easy in Slack, but we found that we could make the most impact by focusing on making it as easy as possible to share Calendly links in Slack, and more specifically Slack Connect, natively without the user having to disrupt their workflow.

We achieved this by focusing on 2 product features:

Richer link unfurling of calendly.com URLs in messages

/calendly global shortcut to easily share your Calendly event

In providing these two features, it was important that we keep the experience as simple and straightforward as possible for Slack users wanting to install and use the Calendly app. This meant that we needed to provide seamless authorization and then rich messaging to let users know what is going on.

Seamless authorization

When we thought about how we wanted to give our users’ the ability to use Calendly seamlessly in Slack, we need to consider how to handle data from Slack as well as the main Calendly application. More precisely, we need to capture events and interactions happening in Slack, as well as be able to make requests against the main Calendly application.

As a somewhat unique approach, we decided that the cleanest way to do this would be to build a standalone application that sits between Slack and Calendly, whose sole purpose is to handle events from Slack and make requests to Calendly.

We chose this layer of abstraction because it allows us to separate concerns of Slack from our main Calendly application, continue our approach of a service-oriented architecture, and dog food our own Calendly API.

When a user installs the Calendly app to their Slack workspace they actually authorize the use of the Calendly app for all users in that workspace. Slack provides this ability to determine the level of authorization granularity based on the token type your application designates, which in our case is the Bot User Token. For users, this means that they actually have access to the rich unfurling of Calendly links without actually authorizing their individual Calendly account. Only when they specifically want to use shortcuts to share their Calendly events directly in Slack do they need to authorize the use of their Calendly account.

Building a simple data model

We need a clean data model to represent this unique authorization mechanism: a single installation for an entire workspace associated with individual Slack users, who may authorize the use of their Calendly account. So we came up with a fairly simple model to represent this behavior:

When the Calendly app is installed to the workspace we store a slack_installation record. This record holds the necessary access information like bot_token to make authorized requests to Slack.

If a user authorizes the use of their Calendly account, we create a slack_user record to associate that user to the slack_installation and then create a calendly_user record associated to that slack_user. The calendly_user records hold the necessary information like access token to make authorized requests to Calendly. In this way we can continue to support installation across a workspace without requiring every user to authorize the Calendly App. We also get the benefit of allowing all users of a workspace to get the rich link unfurling without having to authorize their Calendly account if they choose not to.

Getting users authorized

Now that we covered the data model, let’s get into the flow of control and how we actually make it as easy as possible for users to get authorized:

When a user goes about installing the Calendly app to their workspace, we request authorization for access to specific scopes like chat:write, link:write, shortcuts, user:read…

Upon authorization, Slack redirects to our Calendly app so we can persist their installation information. Rather than ask the user that installed the Calendly app to later authenticate with Calendly, the Calendly app immediately attempts to request the user to authorize access to their Calendly account. We do this by using the Calendly API to register an OAuth app that can provide authorization on behalf of Calendly users.

This part was a bit tricky but enabled a user that installed the Calendly app to be able to use all features immediately without any additional steps. In order to make this happen we actually pass the Slack team.id and the user.id encoded as a secure JWT through Calendly OAuth flow as a state parameter. This way, when the user authorizes the Calendly app to access their Calendly account, we know specifically which Slack user to associate the Calendly user information with.

We also needed to consider the case when Slack users who installed the Calendly app to their workspace, but have not connected their Calendly account, know how and when they need to do so. Our solution was to have checks at each entry point of using the Calendly app to see if they still needed to connect their Calendly account and prompt them to do so if needed.

In order to do this we leveraged messages on attempting to use the shortcut,

and provide links to connect on the App Home page:

We feel that providing these messages at the time of use and making it as easy as possible to connect with Calendly, we can increase usage of the app as well as potentially new signups to Calendly.

Using Blocks, Slack Events API, and Interactivity

In order to support our two core features: rich link unfurling, and shortcuts to share your Calendly event, we heavily relied upon the Block Kit. Slack has created a highly customizable UI framework to allow app developers to display content in Slack.

We use these blocks throughout the Calendly app to display all messaging in Slack. We highly recommend testing and playing with the Block Kit Builder to understand how users will interact with them and how they can be combined together to achieve rich messages, modals, and more.

Slack Events API

Another nice feature of the Slack Developer ecosystem is the Slack Events API. In order to understand how it works, I’ll let the Slack API Docs explain: “Don’t call us, we’ll call you”. Slack’s API makes it easy to listen to specific events performed by the user. Once a user has installed the Calendly App to their workspace, the Calendly app listens for any link_shared event that contains the “calendly.com” domain.

Upon receiving an event, we quickly reply with an acknowledgment of the event, make a request to the Calendly API to get more detailed information about the Calendly event shared, and respond back to the event with a chat.unfurl request to the channel that the link was created in containing a set of blocks displaying a richer unfurling message that other Slack users can interact with.

Interactivity

Saving the best for last, a core feature and technical challenge we faced was allowing users to share their Calendly event without ever having to leave Slack. We decided that what made the most sense was to leverage Slack’s interactivity features including global shortcuts and the newly added modal surfaces. Here is an overview of how this works:

When a user selects the “Share an Event Type with Calendly” shortcut, the Calendly app receives an interactive shortcut payload that we can use to determine which user attempted to use the shortcut.

We then find the Calendly user associated with the Slack User and make a request to the Calendly API to get a list of the user’s Event Types. In the payload received from Slack, we receive what’s referred to as a trigger_id, which allows us to respond to Slack with a views.open request containing a modal view. Using the modal view object and blocks we are able to craft a modal that contains a variety of block elements.

In order to actually build the dropdown selection when choosing an Event Type, we used the static_select input block element, and load each option as the event type received from the request from the Calendly API.

We also add a conversations_select block element to the modal view. This allows the user to select where they want to post the message. In this element we set response_url_enabled: true. This is important because it allows us to know where to post the scheduling message after the user submits the modal. We also use the checkbox block element to allow users to create a single use link and a multiline plain text input to allow users to post a message.

In order to provide an even better experience, we wanted to allow users to preview the event type details they would be sharing when they submitted the modal. This requires an update to the modal when the user selects an event type. In order to achieve this, we actually need to listen out for a block action payload, specifically when the event type is selected from the dropdown. We set an action_id on the block and set up a listener for when that action is received for that specific action_id.

When we receive that action, we capture the existing event types in the options list and preserve it through the update so that the list of event types does not change. Slack preserves any selected views for an event type as long as the block elements remain. We then add a few additional blocks similar to the ones used for link unfurling so that users can preview the message they will create on modal submission. We then fire off a views.update request using the same view.id provided in the block action payload.

Finally, when a user clicks submit, Slack sends a view_submission event. Like the other events, the Calendly app is listening for this specific event and captures this view_submission payload. We make a request to the Calendly API to get the chosen event type’s details or, if a user wants to use a single use link, we actually use that optional checkbox as our indicator to actually create a single use link in Calendly rather then just fetch the details of the Event Type. As mentioned earlier we reply back to the response_url provided based on the conversations_select block element we created when first rendering the modal.

And that’s how Slack users can seamlessly use Calendly without ever leaving Slack!

Closing thoughts

By combining existing functionality in Calendly with Slack’s customizable Block Kit, Events API, and interactive messaging, we as app developers are able to create seamless integrations to empower users to be more productive and make their work life easier.

By doing a little bit more work like automatically authorizing flows with all necessary parties or providing intuitive messaging with as much information as possible to guide the user, we can create apps in Slack that users love.

How Calendly makes scheduling smarter in Slack was originally published in Slack Platform Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Crossbeam, we make things for people that work in sales and partnerships — just the kind of person that is an ideal user of Slack Connect. Our users often join one another’s Slack channels to help work out deals, explore partnerships, and get context on target accounts, so we knew our Slack app had to be ready to deliver.

When channels are shared between organizations in Slack Connect, a Slack app can no longer assume that all of its users work for the same company. Which meant that was extra important our existing app displayed the right data for the right users in the right circumstances.

In other words, we needed to consider an entirely new context for our app.

Trust is our business

Crossbeam is a partner ecosystem platform — we act as a data escrow service that finds overlapping customers and prospects with your partners while keeping data private and secure.

Those “private” and “secure” parts are everything. One of our core values is “trust is our business” — our users need to be crystal clear that the data they are sharing with partners in Slack Connect are seen by the intended recipients.

Our users leverage Crossbeam for Slack to share overlapping customers with a partner to see if integration is worth making, or sharing a list of opportunities that overlap with their partner’s customers so they can give a warm introduction into a new account.

Our Slack app will share overlaps and send notifications when new overlaps occur with the use of the /crossbeam command.

However, with Slack Connect, we have to tweak our outputs to be aware of these new possibilities. If your Slack application involves important data, you’ll likely have to do the same. Here’s what we learned to account for:

1 — Always check what kind of channel the user is in

There are now seven types of Slack environments:

During development, we needed to make sure that, when sharing Crossbeam data, our application took into account who is in each channel. As an example, if I am exchanging leads with a partner in a direct message, our application can comfortably share. However, if I run the /crossbeam command in a public Slack Connect channel, the amount of data our app will share is limited.

2 — Check what kind of user is running the commands

The channel is the “where” and now we must check for the “who”. Mainly is the user running the /crossbeam command:

• Normal Slack user
• Multi-channel guest
• Single-channel guest

The types of Crossbeam data a user could see depending on their user type. For example, we blocked channel guests from seeing the output of /crossbeam.

3 — Choose “ephemeral” vs “public” states

After /crossbeam is triggered, we first share the results ephemerally (only visible to the user). If the channel members also have Crossbeam installed with the proper permissions, the user is then given the option to post publicly (posted to the channel or DM for members to see and search).

That ephemeral state is important. It gives the user a chance to confirm the output of the command before sharing. And in select cases, they won’t be allowed to share. For example, if the channel contains a multi-channel guest, Crossbeam’s Slack app will not allow public posting from the /crossbeam command.

Each output requires separate design states and copy. Using Slack’s provided Block Kit our team was able to make multiple versions of the /crossbeam output as well as the proper warnings letting the user know why they cannot share Crossbeam data

4- Don’t skimp on testing

And lastly, before you get too far into the code, have the right test environment. You’ll need at least:

• Three Slack Orgs, with one in the Enterprise Grid
• Each with multi- and single-channel guests
• Each with shared Slack Connect channels

And it helps to have several developers and designers hopping in using different test accounts. However many outputs you have for your app, test using all users with all channel types.

-

The end result was Crossbeam For Slack, one of the launch partners of Slack Connect!

Slack on Twitter: "When partners work together, their data often doesn't. Map accounts with @Crossbeam, then rally together in Slack to:📝 Share details on clients🤝 Craft a joint sales strategy🍾 Give yourself a reason to celebrate😎 Do it all again https://t.co/SQjpxz0lUr pic.twitter.com/gsrAJeuhry / Twitter"

When partners work together, their data often doesn't. Map accounts with @Crossbeam, then rally together in Slack to:📝 Share details on clients🤝 Craft a joint sales strategy🍾 Give yourself a reason to celebrate😎 Do it all again https://t.co/SQjpxz0lUr pic.twitter.com/gsrAJeuhry

Context is everything: building for cross-company collaboration in Slack was originally published in Slack Platform Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Slack, our focus is to make work simpler, more pleasant, and more productive. And a key way we’re bringing that vision to life is with Workflow Builder. In simple terms, Workflow Builder helps teams automate routine, manual tasks, freeing them to work on high-impact projects.

Thanks to Workflow Builder, you don’t have to code to automate work. The only real constraints on what you can create is your own creativity — and we’ve seen so much creativity! Since the launch of Workflow Builder, more than 1M workflows have been created and used over 120M times. See the most popular workflows by visiting our template library, or dive right into building your own, unique automations.

With that in mind, I wanted to share some really innovative ways we’ve seen teams using Workflow Builder to achieve new levels of productivity. Hopefully, you’ll take these ideas and apply them to your own Slack team, or even better, they’ll act as inspiration for you to create a unique new workflow for your team. Let’s dive in!

Onboarding new-hires

Everyone knows how important it is to effectively onboarding new-hires. It can be overwhelming, with a whirlwind of documentation, countless people to meet, and a huge amount of information to process. We hear from many Slack customers that Workflow Builder helps HR, Recruitment, and Onboarding teams streamline that process and make it better for everyone.

I joined Slack last July, and onboarded fully remotely, so I feel like I’m a good judge. Whenever I joined a new Slack channel, I’d automatically receive a welcome message with a packet of information relevant to the channel. Much of the new-hire documentation was automated. Automating the manual processes of starting a new role made a massive difference to the experience, and let me focus on building relationships with new colleagues.

Slack isn’t alone in using Workflow Builder to create better onboarding experiences. Learn how DocuSign and Noom are automating onboarding workflows in Slack.

Hosting team meetings

Regular team meetings are important, but they can often be disruptive. We use workflows to run our all-hands meetings. My fellow VP, Steve Wood, and I record our all-hands and share the video with our team. Everyone then submits their questions via a shortcut-triggered workflow, and we’ll answer them.

We use workflows in place of stand-ups, too. Instead of each person sharing what they’re working on during a video call, everyone completes a quick form, which saves an incredible amount of time.

It’s hard to gather the entire team at once, especially now that everyone is remote. Aside from timing, there’s the opportunity cost of 15 of your top engineers taking an hour out of their day to meet. That adds up — over time it’s costing you tens of thousands of dollars. Even setting that aside, the information shared in a stand-up can just as easily be shared using Slack. And responding via a workflow encourages higher-quality, more thoughtful responses.

McAfee, a technology security company and Slack customer who transitioned their entire organization to work from home due to the pandemic, is a great example of how Workflow Builder helps newly distributed teams. They needed a way to keep open lines of communication between employees and leadership and in turn created a simple workflow to conduct AMAs (Ask Me Anything) Q&A sessions. These sessions were successful in connecting McAfee employees and created an easy, automated solution.

Facilitating feedback

I have to give credit for this to Dave Stevens, an Engineering Manager on my team. Every Friday, he uses a workflow to send his Friday Fives — a list of five things each of his direct reports should be proud of in the last week, and one thing he’d like them to work on.

Getting positive feedback every single week is a huge morale booster and a great conversation starter. Team members feel appreciated and a bigger part of the team culture. For Dave’s part, the workflow he built makes sharing feedback easy — every Friday he’s prompted to complete a form in Slack, and the feedback is instantly shared with the individual.

We’ve seen Slack customers have success doing this too, like Snowflake, the cloud data platform company. Snowflake’s IT team programmed a workflow that prompts employees to react to a message at the end of their IT support session. By responding with the Surfer emoji, Snowflake employees are DM-ed an experience survey (lovingly called a “Surf-vey”) where they can offer feedback and share their experience at their convenience without ever having to leave the Slack platform.

Scheduling logistics

As an engineering leader, demo days are one of my favorite parts of the job, but getting them set-up used to be a pretty time-consuming, manual process.

So, we created a workflow. Now, our engineers are invited a few days in advance, and if they want to present, all engineers have to do is raise an emoji hand in Slack. Everyone who signs up is automatically slotted into a schedule, and the workflow shares reminders and information for the video call. It might sound simple, but it increased participation in our internal demo days by over 200%.

There are all kinds of workflows engineers can build, but if you need some inspiration, here are 6 templates to get you started.

Automating the escalation process

Every week, our Platform Technical Architecture team receives a lot of escalation requests. Besides the quantity, the lack of detail in many requests made it challenging to take appropriate action and to effectively assign the request.

To address this, the team created a workflow for escalation requests. This reduces unnecessary escalations, and improves on the level of detail shared, making it easier to take appropriate action. The introduction of this workflow was a huge win for the team — they boosted productivity and morale, saved engineering hours, and were able to offer better service.

But Slack isn’t alone in using Workflow Builder to streamline business operations — our customers are making use of the technology too.

At a major telco, an operations team responsible for the maintenance and installation of information systems leveraged Workflow Builder to improve the way they handled service requests. Previously, they had relied on email, with each service request generating as many as 10 emails, creating friction and slow response times.

The team created a new system, which integrates Slack channels, Workflows, and Google Sheets to track requests. Before the Slack-centric system, the average time to resolve requests was 20 minutes, but with workflows in place, the average time is 12.51 minutes, a 37% improvement. Adoption is so strong that the team increased its estimated annual cost savings by $16M.

Getting started

Workflow Builder is a great way for your team to get ahead of the curve on no code automation and unlock higher productivity levels. The winning organizations of tomorrow will create automated processes to take care of routine tasks, enable asynchronous communication, and find ways to focus their people on high quality human tasks.

If you’re on a paid Slack plan, you can get started with Workflow Builder today.

Questions? For quick support, you can always email feedback@slack.com.

Reducing the work of work was originally published in Slack Platform Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

As Slack app developers, we create solutions that save time, increase productivity, and foster effective communication. Our most popular apps connect Slack to Atlassian and are used by all kinds of organizations — even the most security-conscious enterprise companies.

Previously, connecting to on-prem systems were a challenge, but now Socket Mode makes it much simpler.

Cloud is the future

At Nextup.ai, the majority of our customers use our secure multi-tenant SaaS platform. To build trust with these companies we have SOC-II Type 2, HIPAA compliance, bug bounty, and offer data residency. However, for a select set of enterprise customers, opening an internal system (Jira Data Center) to our static IP address is not a viable option.

66% of IT experts agree that security is actually their biggest concern when adopting enterprise cloud computing strategies. Historically, these concerns have stopped firms from opening internal systems to cloud-hosted offerings.

Any SaaS founder knows that larger clients have larger security concerns. As such, running critical tools on-prem has been the de facto move for most enterprise companies.

To satisfy this on-prem demand, we started offering a dockerized version of our software in 2017 and instantly started learning a ton about working with enterprise customers. Our on-prem version streamlines security reviews and allows our customers to configure the solution in a way that works best for their team.

However, data center, infrastructure, and firewall changes can be challenging to implement even with a dockerized instance. The process requires a time commitment from already busy teams.

Expediting the process with Socket Mode

Socket Mode changed the paradigm for enterprise and has allowed our docker container to function without exposing software outside our firewall. Below is an excerpt from Slack API documentation.

Socket Mode allows apps to use the Events API and interactive components of the platform — without exposing a public HTTP Request URL. Socket Mode helps developers working behind a corporate firewall, or who have other security concerns that don’t allow exposing a static HTTP endpoint.

It’s a simple, secure means for us to connect without having to manage additional layers of software like proxies or punching holes in firewalls.

Socket Mode helps enterprises:

• Reduce the risks associated with web-based access to on-prem systems
• Reduce complexity via easier onboarding
• Innovate faster and reduce time to MVP/POC

When we sign up for a productivity tool, we’re doing so because the tool can save time for our whole team. That’s the ROI. If enterprise employees must jump through hoops to get tools approved by the proper stakeholders and (rightly-cautious) IT departments, how much time is really saved?

Some of our customers even build proxy servers to safely transfer data between the public internet and their internal servers. Now they can securely operate behind a firewall without the usual bureaucracy headaches. Socket Mode helps ensure that Nextup’s productivity tools for Slack and Atlassian really do save time for our customers.

How we added support for Socket Mode

When Slack announced Socket Mode we immediately knew our customers would want to adopt this new model. Significant time is saved when we reduce the number of teams required to deploy our integration. However, the security benefits alone are well worth it.

The great part of the implementation is the way socket mode mirrors the existing events our system already processes. With identical payloads, the migration process was actually quite simple.

All our development team had to do was:

• Add a way to enable/disable socket mode on a per-server basis
• Securely store and retrieve the app token
• Implement using Slack’s socket mode SDK

The Slack SDK made this process so simple that the actual development work took less than a week!

Where to go from here

Our Enterprise version is not intended for everyone and in 99% of cases, we recommend our secure SOC-II and HIPAA compliant cloud hosting model.

But let’s face it — not all companies are ready for cloud or have committed to migrating yet. For this reason, we support high-quality, on-prem installations for enterprise teams.

Security is important, let’s treat it as such.

To build your own application for on-premise software with Socket Mode, visit the Slack API documentation for an introduction to some core concepts, the new app token, and related sample code.

Check out Nextup.ai for Slack by visiting the Slack App Directory.

Questions? Email feedback@slack.com.

Breaking down barriers for Slack app adoption was originally published in Slack Platform Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Clerk enables teams to send and receive SMS in Slack. At the beginning of 2020, our mission was to build the first billion-dollar business on top of Slack. As the world changed during a pandemic, so did our grand plans.

Enduring digital transformation

By early last year, our Slack app had won the Slack Hackathon, was featured on Product Hunt, and adoption was climbing. Then, the pandemic hit. We saw a significant decrease in the number of installs, so we feared the worst.

Many of our customers are small businesses, like event and construction companies, that use Slack for both communication and collaboration. Impacted by the pandemic, these businesses ceased operations and their Slack usage.

But early indicators are not predictors of final outcomes, as businesses started a shift toward digital. Discovering tools like Shopify, Slack, and Clerk, we were able to become an essential part of this wave of digital transformation.

Slack SMS — Breaking down communication silos

Our vision at Clerk is to help our customers consolidate communication tools, like Slack, email, webchat, calling, etc. Information often flows into a system that’s only visible to an individual user, like email, then is stuck there unless shared elsewhere. We call this chasm in communication the messenger problem.

The challenge with this flow is that it relies on user-initiated action to share the critical information in all the right places. For instance, a customer support ticket is generally solved by the customer support team, but the key learnings and outcomes only sometimes flow back to other teams like sales, engineering, and product.

Slack is beautiful and successful because it allows anyone from any team to communicate, peruse channels, and consume information in both active and passive ways.

Building on this, when customers are empowered to text a business number via Clerk, details flow into channels for easy collaboration in real-time. This results in a more cohesive team and better customer experience — ultimately, driving sales, retention, and referrals.

Solving the messenger problem during a pandemic

Over the course of 2020, as companies adapted to dramatic change, so did humanity. Medical response to the pandemic was fast, and several first-responding companies adopted Clerk on Slack for gathering COVID support information. Our Slack app made a small impact on the world!

That same early shift to digital was now being leveraged by medical professionals and the general public, transforming critical information into a more human experience. No extensive calling menu, canned responses, or wait times to get to a person. Slack and Clerk were connecting people to people.

“One major feature that helped us during COVID was texting via Clerk,” said Zhanetta Shapiro, a Staten Island-based doctor of audiology at Audiology Island. “The fact that it was integrated with [both] Slack and our database made communication much easier with our patients, regardless if we were in the office or not. It is wonderful knowing that our entire team can stay connected and help our patients get answers right away.”

More to come

Today, Clerk serves hundreds of paying customers — and growing every day. Addressing the needs of both large corporations and nonprofits, we are on a mission to solve the messenger problem for everyone using Slack.

Check out and install the Clerk app on the Slack App Directory. Questions? Email feedback@slack.com.

Pivoting during a pandemic was originally published in Slack Platform Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In 2018, we released an integration between Stack Overflow for Teams and Slack. It’s now one of the most popular ways for users to interact with our platform, and we have been steadily upgrading it with new functionality based on feedback from customers. We’re pleased to announce that we’re releasing version three of our Slack integration with plenty of new features to reduce context and tool switching while streamlining the developer workflow.

With this release (available for Basic and Business today, for Enterprise in the 2021.1 release), we wanted to dig into some of the technical details of what we did. There’s a lot of great new features, and a lot of work behind the scenes to make them a reality. For reference, the integration that most people use was version two; version one was a bare-bones integration that just supported notifications (and is still used by a small fraction of Teams).

This version brings several new features that will improve your overall experience:

• A more secure and configurable authorization experience.
• Org-wide installs, so organizations with multiple Slack workspaces can add our integration to all of them at once.
• Ask questions directly from Slack with /stack ask.
• A one-click autoupdater that uses a modal dialog to make sure the app is current on all associated workspaces.

Additionally, our previous integrations were built on functionality that has since been deprecated. So the work we’ve done here sets us up to provide even more functionality in future versions.

We had originally worked with Slack to be one of their launch partners in implementing their workspace apps. When the developer preview for the feature ended, they recognized that this was the wrong path for them, and they deprecated workspace apps. While we had been planning to include features that built on workspace apps, Slack was such an incredible partner on this that we were able to pivot smoothly.They reached out and gave us a shared support channel and were incredibly responsive to our support questions. We wouldn’t have been able to implement the features in this release without them.

We had to do a fair bit of work to make sure that the new granular bot version had feature parity with what we had previously. Asking you all to upgrade only to lose functionality would have been a hard sell.

In this article, we’ll talk about how we built this new version and the path we took to ensure our new bot useful, usable, and secure.

Authentication and permissions for the granular bot

One of the primary features of the Slack integration is notifications. You can configure Stack Overflow for Teams to send a notification for a channel whenever there’s activity you are interested in.

Previously, the mechanism were used for notifications was incoming webhooks. These are URLs that we could post to whenever we wanted to send a notification to a channel. These URLs were automatically generated, so that Stack Overflow for Teams had easy access to post to any channel.

We decided to stop using incoming webhooks for a good reason: improved security. If one of these URLs returned an error, that has potential to get logged on our side. Now we (and anyone who got a hold of our logs) could spoof whatever messages they want to corporate Slack channels. For some of our more security conscious customers, this was a big no-no. They had actually asked us to disable this feature because it opened a new angle of attack.

With these updated scopes and without the incoming webhooks, we made some InfoSec teams quite happy and they were green-lighting our applications. But we still had to figure out how to get notifications sent to the right channels. Without the incoming webhook URLs, we were restricted to scopes available to our Slack bot.

For public channels, this wasn’t much of a problem. The bot just has to join all of the channels that one might want to send notifications to. We give workspace admins an opt-in setting that instructs the bot to automatically join all public channels, which has to be done one by one. It’s kind of a pain in the butt, but it worked fine on our testing environments.

Once we decided to dogfood the app and try it out on our own workspace, it broke completely. On our testing workspace, we have maybe ten channels. On our company’s workspace, we have something like 350. In stepping through these one by one and joining them, not only did it take a long time, we hit Slack’s rate limits. So we had to build a background queue on our end, which would send join messages until we saw a failure, then stop processing the queue and wait a few seconds.

But for private channels, this meant that the bot had to be manually added to a channel by a user before anyone could consider interacting with it. This may seem like an extra hassle, but it’s actually a good thing. Imagine you’ve been invited to a private channel to discuss an upcoming feature. Just revealing the name of the channel could be a massive information breach.

There’s another side effect to having to manually add the bot to channels. Imagine you have a channel with hundreds of people, something like #engineering, and you don’t want it clogged by bot spam. Admins can now exclude a bot from a channel, preventing everyone else from targeting it with notifications, no matter what their permissions, even if the channel is public.

As a result of these changes, we had to build a channel selector drop-down in Stack Overflow for Teams. This is not something we wanted to do; previously, when you were choosing which channel to send a notification to, we would send you to your Slack instance. Slack would then show you a channel selector based on your privileges. Instead, we had to create an external component that should only have access to what the bot has access to, and nothing more. Unfortunately for us, that type of scope is not currently supported by the Slack API.

Our options were to request all public channels or all private channels — separate and complimentary scopes. But both scopes are all of nothing. As we talked about earlier, just displaying some of those private channel names could be a huge problem. We don’t want to do that, and our customers don’t want us to do that. So our channel browser only has the scope to access public channels. We need to do a second check on these channels to make sure that the bot has access. Once we configure this, we can then access the bot directly to post notifications.

One install to rule them all

It’s becoming more common for large companies to have multiple Slack workspaces — one workspace for C-level execs, one for the engineers, one for sales, etc. Each of those workspaces may have their own administrator. But if you’re installing an integration with an enterprise-level piece of software like Stack Overflow for Teams, you’ll likely want that to work on every workspace in your organization. If you have ten workspaces, that’s ten installs coordinated with ten admins. Org-wide installs help to reduce the administrative burden that comes with delploy app integratiosn across multipel workspaces.

But it was worse than that. Our Enterprise customers have the option of installing our software on a local or organization-controlled server, which means the endpoint that the Slack integration interacts with will be at a different URL than normal. Admins on Enterprise installs would have to manually edit this URL in the app; we provide instructions on how to do this, but still, this makes ten edits to apps to make, ten installs on ten workspaces with ten admins. That’s exhausting.

With this release, we’re introducing org-wide installs. One person — the organization admin — can install the integration on all workspaces. If Enterprise customers need to edit the endpoint, they do so on one integration app and then install that. If the organization needs to create new workspaces, then they can make it installed by default so it already has the application baked in.

Now a single Teams user can be associated with multiple Slack workspaces, including multiple unconnected workspaces. Because of this, we had to change our database schema to support more than one workspace per user. Previously, we had one Slack access token associated with each Stack Overflow for Teams user. But now we store as many tokens as the user has workspaces in a single grid.

This can get complicated (and annoying) with a lot of workspaces in an org. In order to send notification DMs to Slack users when they are tagged in a question or otherwise need to be directly notified, we have to store a mapping of these users in addition to the access tokens. This is based on the email address, which lets us automatically map any users that match.

If a user has a different email address on Slack and Stack Overflow for Teams, then you can use the new `/stack connect` command in Slack. This gives you a link that will take you to the workspace’s associated team and allow you to link your user accounts. On the one hand, it’s not great for notifications because it adds a new requirement to map users. On the other hand, you can mention people on Slack when you create a question and that’s going to properly tag them on Stack Overflow for Teams.

Security-minded Enterprise customers have some additional new options. Those worried about storing more PII on their installation or exposing their entire company mailing lists to us can turn off the mapping feature — notifications will still work. It’s as simple as a checkbox during the install process. Some might be protective of their internal information and firewall their Enterprise environment away from the rest of the internet. For them, we allow restricting their instance to outgoing-only traffic. Only notifications will work, but it still gives us the opportunity to integrate with strictly controlled environments.

Ask directly from Slack

For this release, we also wanted tighter — and two-way — integration between Slack and Stack Overflow for Teams. To compliment notifications, you can now ask questions directly from Slack to help reduce context switching.

As you can see, this command displays a modal dialog where you can create a question with all the features as if you asked it on Stack Overflow for Teams. We had to write new code to support modals, but this modal is essentially a dumb layer that interacts with Stack Overflow for Teams APIs. The only part that is doing real time work is an autocompleter for tags. Both of these functions were part of the prep code we put in place before implementing the feature; once they worked, most of the `/stack ask` feature was easy to write.

We were able to keep most of the functionality on our side and reuse the existing post insert and post validation logic. On submit, we have the barest basic validation in the modal, checking that required fields are filled in and that they have the appropriate content lengths.

Despite being able to entirely reuse the existing post validation functionality, it turns out that the solution wasn’t so simple. At one point, one of the automated unit tests failed in a weird way. Like a lot of mysterious errors, it worked on the dev machine. However, the dev machine was set up for developing against Teams Basic and Business, while the failing test was being run against an Enterprise environment, which is code-wise closer to the public Stack Overflow site and therefore has much stricter rules around what a valid question is. In this case, the test was periodically failing because the “duplicate post” checks were triggering a warning if the unit tests were run in a specific order.

The validation logic that checks word counts, grammar, and more has to work inside of the modal. And any errors that come back from failed validations have to be visible in the modal. Those errors have to be one-to-one with what comes back from the Teams instance. Not to brag, but we did such a great job matching the behavior on both sides that it messed us up with a later automated test. Nice job, us.

Reducing friction now and forever

Chat programs like Slack are an integral part of the contemporary workplace — especially remote workplaces — so we want to make sure that the Stack Overflow for Teams experience integrates seamlessly into Slack. Requesting and providing information should be frictionless, and with this latest iteration of our Slack integration, we think the experience is even easier than before. Even with the challenge of building towards a changing paradigm, this is a better integration than before.

Of course, this won’t be our last version. The work that we put into 3.0 will pay off in future versions, and we’ll be in a better position to implement new features. For example, we’re looking at expanding on the base functionality written for modal support to add more features within Slack, such as creating and managing notifications.

We hope you enjoyed this peek under the hood of what goes on with Stack Overflow for Teams development. It’s a product that we think will make a lot of people more productive, and we look forward to making collaboration and knowledge sharing easier than ever.

This post originally appeared on The Overflow, Stack Overflow’s company blog, on January 26th, 2021.

Modernizing the Stack Overflow for Teams app for Slack was originally published in Slack Platform Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.