vahagn-headshot

Vahagn Aharonian

It requires an ample amount of time, effort, and resources to produce great, user-friendly documentation. Good documentation is fundamental to the way engineers get started with a product and ultimately use it in the long run, which makes it essential to both user retention and growth. Building our documentation at [Courier](https://www.courier.com/) was a task we therefore took very seriously.

We originally created our documentation for a very small, specific audience with specific uses for Courier. Over time, however, our user base, their use cases, and our product itself has grown dramatically. To cover our bases, we needed to improve and expand our documentation and this time, we wanted to make it scalable and with a focus on a great user experience. We decided to use [Docusaurus](https://docusaurus.io/) to do so, which allowed our engineers to collaborate and update our documentation more efficiently. Here’s how we built our documentation and what we learned in the process that might be useful to you. 

![built-our-docs-1](//images.ctfassets.net/z7iqk1q8njt4/5rCidPNvia7pzkFHRThDWg/0eee977765165d61b895bf2aac459ef0/built-our-docs-1.png)

## Identifying challenges with our documentation process
When we first started Courier, we just wanted [documentation](https://www.courier.com/docs/) that explained how to use Courier as a product. So, we found a tool that could help with that: ReadMe. 

ReadMe gave us enough features to get started with our documentation. We could create and update our documentation when needed and without much effort, but we couldn’t collaborate as much as we needed and could only save one draft at a time. This was a major challenge because anyone could easily overwrite another’s work if they were working on the same file at the same time. ReadMe also had a flat file structure which was inconvenient to use. There was also no real [Git](https://git-scm.com/) integration into their CLI, so we had issues with document versioning and collaboration. Ultimately, this meant that docs were in the approval process for an unnecessary length of time and not everyone was able to make suggestions for improvement as they came up.

So some years and a few significant product updates down the line, we knew that it was time for a major documentation update. ReadMe was easy to get started with and served us well for our first couple of years, but we needed something that addressed our more specific pain points.

## Prerequisites for a documentation tool
So we knew we needed something new. The next step was to decide which solutions were necessary to address our pain points for the next version of our documentation. The team came up with a list of requirements for documentation tools we would use in the future.

### Limitless Collaboration
A happy challenge with a growing company is the need to scale almost every aspect of it as the team and product grow. As Courier’s technical team grows, we have more subject matter experts to provide input on documentation, which is good news for the quality of docs. However, more SMEs mean that we need more people to be able to collaborate on a draft at a time. Since the team will only continue to grow from here, limitless collaboration was one of the basic necessities for our future docs tool(s).

### Versioning
A growing company comes with the inevitability of a growing product. As new versions of the product are released, there will always be an overlap time when some of our users are using an older version of the product and some are on the newest version. Our documentation needs to cater to both of these groups of users, which means to make sure everyone has the correct information, versioning is an important docs feature. For example, we need to keep the documentation of our API 1.0.0 version separate from the one for API 2.0.0 and ensure that it is possible to update and switch between versions quickly and easily.

Version was also important to allow for the option to separate and store drafts away from the official documentation so that the team would be comfortable working without the pressure of a breaking change. 

### Link Validation
One of the worst things that can happen to user experience in product documentation is for a user to click on a link and get a 404 error. It makes it more difficult to keep users in the docs and following instructions, which can ultimately affect how many users successfully get started with the product and/or are able to troubleshoot on their own. A docs tool that would include link validation for internal links would go a long way toward avoiding damaging errors and UX issues.

### Localization 
We have customers from different ethnic groups all around the world who speak a diverse set of languages. To cater to a global audience, users need to be able to read our documentation and get the help they need, regardless of the language they speak. Localizing our documentation like link validation, improves user retention and UX.

## Docusaurus matched our list
With our list in place, we were able to begin researching to find the right new tool. After some research, we discovered that [Docusaurus](https://docusaurus.io/), which is built on React, allowed for limitless collaboration, versioning, link validation, and localization. 

With Docusaurus, we built our docs as markdowns and exported them as a static site. We created reusable custom components and now have complete control over how we build our documentation. The [MDX](https://mdxjs.com/) integration is also particularly useful, as it allows any JavaScript code to be embedded into the .md file. 

With a few lines of code, we could tweak our theme to suit our brand colors or customize any part of our documentation by [swizzling](https://docusaurus.io/docs/swizzling) the components we wanted. We also could use plugins to extend the functionality we got from Docusaurus. An example is the plugin for our search feature that allows customers to find relevant documentation.

![built-our-docs-2](//images.ctfassets.net/z7iqk1q8njt4/7umSHw0duZhot5KinxvX5g/1cf7082bd4060524f991dda6f714814b/built-our-docs-2.png)

I also built our custom API explorer myself, which enables developers to try out our API methods directly from our docs. I built it as an embedded React component placed in the MDX file. Because we host our documentation on [Vercel](https://vercel.com/), we could utilize Vercel Functions to proxy the API Explorer requests to the Courier API through our docs backend endpoint.

![built-our-docs-3](//images.ctfassets.net/z7iqk1q8njt4/5UGnlKtqc5VETHZdpcSUO6/270125cefaca0baf3b7d712a4120c059/built-our-docs-3.png)

With Docusaurus, we have been able to build our documentation quickly and easily. We can now make updates by simply cloning the repo on [GitHub](https://github.com/), branching off our main branch, implementing the changes, and creating a pull request (PR). Once someone has reviewed and approved the PR, it’s merged with the main branch, which deploys to Vercel and updates our site with the changes.

All we need to contribute to our documentation is a GitHub account and an integrated development environment (IDE). This helps us keep track of every maintenance task for our documentation.

## What’s next for our documentation?
There are a few more goals we have for our documentation. We have yet to utilize Docusaurus’s localization feature, so that’s in the works. We have also recently made our documentation [open-source](https://github.com/trycourier/docs) to welcome external contributors. This way, the user can take ownership of the updates they want and help themselves and others who would benefit from their contribution.

Until then, learn to use Courier via our [documentation and tutorials](https://www.courier.com/docs/guides/tutorials/how-to-design-a-notification-template/). We also [live stream](https://www.twitch.tv/trycourier) content that’ll help you get [started and continue with Courier](https://www.youtube.com/channel/UCuONBIOzl-hypZ5qqWKDeeg).


built-our-documentation-header

To cover our bases, we needed to improve and expand our documentation and this time, we wanted to make it scalable with Docusaurus.

built-our-documentation-thumbnail

How We Built Our Documentation On Docusaurus

shreya-headshot

Shreya Gupta

[Hacking the Engineering Process](https://www.meetup.com/hacking-the-engineering-process/) is a San Francisco-based meetup, which opens discussion for software engineers and tech enthusiasts to share their thoughts on leading topics, pose thought-provoking questions for each other, and learn more about how various engineering teams measure developer productivity amongst themselves.

In March, the guest speaker was the VP of Engineering at Apartment List, Sue Nallapeta. Nallapeta is a leader in tech and is passionate about building highly performant and vastly scalable engineering systems. One of the questions that many engineering leaders often contemplate is whether or when to build or buy software in the process of building a product. Companies invest a lot of time and resources into building software, while buying software can also be expensive in other ways. In her talk, Nallapeta described the “7 C’s” she considers when making this decision between build vs buy and shared her experience in implementing this process while developing Apartment List.

<iframe width="560" height="315" src="https://www.youtube.com/embed/dTSFDkWM1oM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

## Capability
The first C is Capability, which is determined by the problem that you are solving for, including any features you need or want to build. This is a product and a business’s core, and often what makes it stand out amongst others. These capabilities are what you want to go to market with and what your customers will use. The question then becomes whether these capabilities already exist. If so, developers need to decide whether it is worth building them from scratch or using the tools that are already available, which is a decision that depends on how quickly the product needs to go to market and which path would help achieve the goal most effectively and efficiently.

## Cost
There are two common dimensions to cost that most people will look at when building. The first is resources, including how many engineers a team may need to develop the product. The second being time, on how long it will take for those engineers to build the product given the resources they have available. Most teams will consider the two and choose the cheaper option. There are, however, other pertinent costs that can and possibly should impact your decision: build time, maintenance costs (to monitor the product, support it, build test cases, etc.), infrastructure costs, and hosting costs (which are hidden but can add up to a lot).

There are other costs if you choose to buy. Transferring a solution you already have or integrating a new tool can be time consuming and have major migration costs. Buying software also involves onboarding costs (how long it takes for engineers to learn the new system and become comfortable with it) with offboarding costs (typically there is an overlap between old and new systems) and maintenance costs for successful long-term integration. It is crucial for teams to think beyond these two dimensions before making a decision based on cost.

## Complexity
In order to build systems that are easy to understand and explain to others including the sales team, growth team, and all business stakeholders. Teams often build products that are very complex, and complexity also grows as the product scales. For example, Netflix’s scale was so large that they needed to invest in their own Content Distribution Network (CDN) and built Open Connect, which they can ship to all ISPs to cache videos on the client side to deliver content quickly.

## Competence
A product’s build speed heavily depends on the team’s competence. Do we have the right engineers on the team who understand what needs to be built? Do they have the experience and domain knowledge to understand what we are solving from the business and customer perspective? Do they work well together? If not, how long will it take to hire and build this team? Building a competent team can take upwards of 3-6 months just to hire.
At a previous company, Nallapeta’s team acquired over 10 companies, each acquisition immediately adding value in the span of a couple of months. If they built, it would have taken several months or more to add those capabilities.

## Cohesion
Cohesion, or connectedness, is tricky in the case of buying - whether the feature you are buying integrates with the other systems that you already have. For example, Apartment List uses Salesforce for Customer Relationship Management (CRM), and any other software they build that ingests data should support sending data to Salesforce. You can create value through an ecosystem of softwares, where systems coexist with each other and are dependent on each other.

## Competitive Advantage
Any product needs to be able to compete once it enters the market. Competitive advantage is a key factor decided by whether the product or its features are core to its functionality and to the business. The product’s capability determines if it can be competitive and can ship features faster to win the industry.

## Continuity
Continuity goes hand-in-hand with maintenance. It determines how you ensure scalability of the product as your user base grows and as new feature requests rise. This is important to track so you can guarantee that your system is sustainable and you don’t need to replace the system every few years, which can be a major setback.

## Apartment List’s Experience
### Build: A/B testing
In building a product that satisfied all of the capability needs, Out of the Box (OOTB) solutions were insufficient for the business need at the time. Apartment List is a subscription based business. The team had to quickly ship many experiments, and try various subscription based models and paywalls, each with changes in prices and features, which would not have been possible without fast iteration.

They also wanted to maintain control over customization to build a great user experience. The product was highly customized for various customers and customers sub-groups. It also provided a great competitive advantage with insights and quicker feature launches with a lower experimentation and test setup, leading to an increase in customers globally.

### Build: Billing System
In a high risk industry, the chargeback rates are extremely high. With a subscription based business model, Apartment List needed to maintain fall back use cases such that if a payment does not go through for a customer, the system automatically redirects to a different payment processor, a feature unavailable in other billing system tools. This allowed them to also lower the renewal rates and offer more discounts to their customers. Most importantly, Apartment List’s margin was low, meaning using a tool like Stripe would lead to them cutting into their margins.

### Buy: Email Software
Apartment List had initially built their own email software, which was relevant for the stage of the business. At the startup stage, it made more sense to build the software and have access to customized complex features. However, engineering teams did not have the bandwidth or documentation to support the system and over time, as the team who built the software left the company, there was not enough in-house knowledge about the software to maintain it. Eventually using the in-house software also meant that something as simple as a brand update with new logos and colors would require weeks or months of engineering effort.

Apartment List chose Courier to support transactional emails and another provider for marketing emails. This also helped the company achieve cohesion, with the new systems integrating well with the existing system and each other.

### Buy: Testing Software
Every company requires some form of Quality Assurance (QA), which, as the product scales, can become an expensive and tedious process that forces engineers to divide their attention away from the product. Using an external tool offers better control and ease of use of the testing software and increases the efficiency of the testing process.

### Build & Buy: Analytics
Data is the backbone of any company, requiring high data accuracy and coverage. Every decision made needs to be built on a strong foundation. With evolving business needs, ApartmentList chose to both buy analytics software and build on top of it to close the gaps.

## Learn More & Join
If you would like to learn more about Sue Nallapeta’s decision making process and experience with Build vs Buy, check out the talk recording on YouTube: [https://youtu.be/dTSFDkWM1oM](https://youtu.be/dTSFDkWM1oM)

Hacking the Engineering Process hosts monthly meetups.

* Become a member: https://www.meetup.com/hacking-the-engineering-process/
* Submit a CFP: https://jkfr7wbzytt.typeform.com/submit-cfp


A swan pulls a ready-made nest out of a Courier box while a duck has to build one from scratch across the pond.

build-vs-buy-header

This post gets into the “7 C’s” that should be considered when deciding to build vs buy. Learn about how Apartment List implemented this process.

build-vs-buy-thumbnail

Build vs Buy: The “to be or not to be” of Tech

Aman profile pic

Aman Kandola

Last fall, we published [a post](https://www.courier.com/blog/why-remote-work-is-not-here-to-stay/) on how despite the ongoing impact of Covid-19, Courier would remain committed to keeping our office in San Francisco and focusing our hiring efforts on local talent in the Bay Area. As the company has evolved, we’ve decided to shift our approach to a remote-first model. Although we had good reasons to choose not to go remote earlier, this eventual change in mindset led to several new initiatives during the hiring process and to maintain company culture in a remote-first environment. This blog post will highlight some of these initiatives and why we chose them.

## Why weren’t we already remote?
There were a few reasons we didn’t move to remote-first sooner. Firstly, we believed it would be easier and quicker to onboard new employees in-person vs. remote. When you’re a small team, every single hire changes the entire dynamic of the company so it’s really important to make sure they have a great understanding of the company’s culture, strategy, product, tools, and customers. People generally tend to be less hesitant to ask questions when they see people in-person than over Slack, especially if they’ve never met them before. When speed is critical, poor communication can become a bottleneck and we thought focusing on in-person hires would shorten the onboarding process. Secondly, we believed that certain kinds of collaboration were not feasible in a remote environment - especially in scenarios that call for creativity and quick decisions such as product design, marketing campaign construction, and deal strategy. Third, we also believed that maintaining a physical presence as an early-stage startup would actually serve as a differentiator since we saw many other similar startups shift to remote-only and we had a handful of people join the team citing our office and the in-person experience we offered as motivating factors. We believed there were many other similar candidates who specifically sought out an in-person experience after over a year of remote-only work and we would be well-positioned to compete for their talent.

We’ve since learned that, while these assumptions were not completely unfounded, we overestimated the negative impact of shifting to remote-first. We had also always intended to eventually hire outside of the Bay Area as the company grew, but after another year of learning about the benefits of remote vs. in-person work, we decided to rapidly accelerate our timeline and immediately shift to a remote-first approach. 

There were two primary factors that led to our decision. The first is that even though we were ostensibly an in-person company, after March 2020, we never mandated office attendance even after many of the in-person restrictions were no longer legally enforced. The result was that we had many employees who, while based in the Bay Area, rarely came in person and who had onboarded and operated 100% remote since the day they joined. We found that they were just as effective as employees who were coming in regularly and we had not sacrificed any operational velocity or our existing company culture. Second, we also found that even though there were candidates who did indeed appreciate our commitment to maintaining a physical presence, there were many more who wanted the flexibility afforded by remote work. By shifting to a remote-first approach, we could actually offer an attractive work environment to both of those types of candidates and, after experimenting with this approach for a few of our open roles, we saw a large increase in our inbound talent pipeline for those roles. We simply could not move fast enough on hiring if we focused only on Bay Area talent. So if we had nothing to lose and lots to gain, it seemed like shifting to remote-first was a pretty obvious decision.

## Compensation and leveling philosophy
Of course, shifting to remote-first isn’t as simple as making an announcement and writing a post - we had to consider the long-term impact this would have on the company and how best we could support the growing percentage of our team that would be permanently remote. Firstly, we had to decide how we would compensate remote employees. We’ll be writing a separate post detailing our compensation and leveling philosophy, but ultimately, we decided it made the most sense to pay everyone the same amount regardless of where they were based (within the U.S.) and to make compensation and leveling information completely transparent internally and in all external job postings. This would be the fairest approach for all team members and would minimize the associated administrative overhead while also making expectations clear to any prospective candidates. 

## Cultural and communication expectations
We also decided to make our cultural and communication expectations more explicit in the recruiting and onboarding process for new hires. Some examples of the kind of communication behavior we now explicitly outline for all employees include: preferring public Slack channels to DMs, encouraging asynchronous communication over synchronous, and sharing notes from in-person meetings with context in Slack. We also introduced a handful of new ongoing company activities to help remote employees get to know everyone on the team such as monthly virtual hangouts (escape rooms, games, etc.), quarterly in-person events where we bring the entire team in for some fun, and starting new employees in cohorts when possible instead of by themselves and encouraging them to come in-person for at least a few days in their first few weeks (travel expenses all covered by Courier). 

## Reviews for new hires
Lastly, in an effort to help us better identify how we as a company could support new employees when they first join, we are instituting a 30 day review process for all new hires when they hit 30 days from their start date. Instead of focusing exclusively on performance indicators as most review processes do, we are going to be emphasizing behavioral indicators of success at Courier via peer reviews. Some examples of indicators that we believe will be correlated with success are “proactively asking questions”, “offering feedback”, “taking ownership”, and “proactively suggesting improvements”. The goal of this process is to help reinforce the work philosophy at Courier for new hires (and reviewers - they’ll have to be on the lookout for these behaviors) and help us think about what we should be looking for in the hiring process to make sure there is a mutual great fit with all candidates. 

## The impact of this decision
Since we announced this change to the team a few months ago, we’ve seen a largely positive reaction. Ultimately, this change allowed existing team members more flexibility since they can now live anywhere in the U.S. without any changes to their compensation or they can keep coming into the office as they already were. We’ve also noticed a significant increase in our inbound talent pipeline across all roles from candidates who want a primarily remote experience. It’s worth noting that even among the non Bay Area hires we’ve made, they’ve all come and visited at least once already and our Head of Developer Relations, Nočnica, who is based in Portland, actually cited her experience having lunch with the team in the office during the interview process as a primary factor in her decision to join Courier. We’re excited to see that this has been received well by our existing team members and potential candidates alike and will be continuing to think of improvements we can make to build a world-class workplace at Courier. 

If you’re interested in learning more about opportunities at Courier, check out our open roles [here](https://jobs.lever.co/trycourier/).


Several people sit on blue clouds away from each other with their office in a cloud at the back, but are working together remotely

now-remote-first-header

We wrote a blog post about why Courier would never be permanently remote. This post covers why we changed our minds and Courier is now a remote-first company.

now-remote-first-thumbnail

Why Courier is Now Remote-first

suhas-headshot

Suhas Deshpande

When I realized there was a leak in my home, I knew it was time to put my expertise to work. I needed to call on my years of experience and passion for my job - as a software engineer? While at first glance, it may appear that a plumber would have been a better option, my argument is that there is a step to be taken before a plumber is even involved to fix a leak. And that is to detect the leak when it first happens. 

Sure, I could have a plumber on call who checks for leaks every day, but seeing as that’s not an effective use of time or money, we needed to find an alternative to waiting for the problem to become bad enough to become a major problem. So if a 24/7 plumber-butler wasn’t an option, I thought some kind of automated system would be more realistic.

As it turns out, I had been thinking for some time about how to use a Raspberry Pi with Courier to bring notifications to life. This happened to be a perfect use case to try it out, so I decided to invest in the appropriate hardware and make use of my own software development skills to make sure that I would get a notification any time there was even a small leak in my home. This way, I’d know to call the plumber and handle the problem before it became too big to handle.

## A leak can become an expensive problem
I myself had a water leak in my apartment some time ago. Because I didn’t know there was a problem until it was already too late, I had to call for a plumber when the damage was already done. Even for a simple leak like this, I ended up spending more than $500 to fix it. 

But things could have been much worse. Major damage is often caused by mold spores.
Water leaks may also cause structural damage to property. Walls start swelling and warping, leading to cracks and holes in them. Furthermore, water leaks may negatively impact the value of a home.

I never wanted to deal with the complications, so I decided to take matters into my own hands. But of course, it was important to find a solution that would be fun and interesting as well as useful. 

## Building alerts for water leaks using Raspberry Pi
During my research for a solution in the form of alerts for water leaks, I found that I could use a small, affordable [Raspberry Pi](https://www.raspberrypi.com/) single-board computer to achieve my goal. With this tiny computer, I could read signals from my water sensor and then send those signals to my monitor. 

To develop the project, which I called [potential-octo-lamp](https://github.com/suhasdeshpande/potential-octo-lamp), I first got all the hardware I needed to detect water leaks and connect to my computer. These devices included:

* [Raspberry Pi 4 Model B](https://www.amazon.com/dp/B07WYC73LF?psc=1&ref=ppx_yo2_dt_b_product_details)
* [Floor Water Sensor for Flood and Leak Detection](https://www.amazon.com/dp/B079YB1T8J?psc=1&ref=ppx_yo2_dt_b_product_details)
* [SanDisk 128GB Ultra MicroSDXC UHS-I Memory Card with Adapter](https://www.amazon.com/dp/B08GYKNCCP?psc=1&ref=ppx_yo2_dt_b_product_details)
* [GPIO Breakout Expansion Kit for Raspberry Pi 4B](https://www.amazon.com/dp/B08736NSPK?psc=1&ref=ppx_yo2_dt_b_product_details)
The next step was to build “potential-octo-lamp” to send alerts for any detected water leaks. I built the project to check for leaks from the sensor using JavaScript and TypeScript programming languages. When potential-octo-lamp detects one, it then sends the result to my phone using Courier and Twilio.

With [Courier](https://www.courier.com/), I could create custom alerts and define their titles and body text. I could also specify the communication channels through which the alerts should go and the recipients of these alerts. I also added a [Twilio](https://www.twilio.com/) integration on Courier to deliver the contents of my alerts through the channels I specified — in this case, SMS and email.

## How to use potential-octo-lamp to get alerts 
Luckily, I’m a really nice guy and have made potential-octo-lamp open source. You can use my program to protect your own home from water leaks. Once you have all the hardware requirements listed above, connect your Raspberry to your water sensor. If you need help setting them up, this [tutorial](https://www.youtube.com/watch?v=KwKiiWYQies) will help. Then you can begin using potential-octo-lamp to receive alerts for water leaks in five easy steps:

### 1. Create Your Courier and Twilio Accounts
If you don’t already have [Courier](https://app.courier.com/register) and 
[Twilio](https://www.twilio.com/try-twilio) accounts, you’ll need to sign up for both to configure your alert system. You may sign up for free on Courier and Twilio using an email address. Courier also allows you to use your Google or GitHub account to create an account.

### 2. Add Your Twilio Integration in Courier
[Start by getting](https://www.courier.com/docs/guides/providers/sms/twilio/) your Account SID, Auth Token, and messaging service SID from Twilio. Then log into your Courier account and go to [Integrations](https://app.courier.com/integrations). Add the Twilio info to their corresponding fields in Courier.

### 3. Retrieve Your Courier Authorization Token
When you create an account with Courier, you get an Auth Token so that you can safely make requests to and from Courier. Once logged in, you may retrieve your Courier Auth Token from the [API keys page in Settings](https://app.courier.com/settings/api-keys).

### 4. Clone potential-octo-lamp and Add Your Courier Auth Token
Next, go to GitHub and clone [potential-octo-lamp](https://github.com/suhasdeshpande/potential-octo-lamp). Because it’s unsafe to input your Courier Auth Token directly in your code, create a .env file and add it there. That way, it’s only visible to you.

### 5. Start the App
Finally, run the following commands one after the other to install dependencies and start checking for water leaks:

>> npm install

>> npm run build

>> npm run start

<div style="position: relative; padding-bottom: 200.55555555555554%; height: 0;"><iframe src="https://www.loom.com/embed/6c977bc087fd4943b27fbda8c2069f65" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>

As soon as your floor water sensor detects leaks, potential-octo-lamp sends alerts for water leaks to the recipients you added on Courier. Then you can quickly repair the leak to prevent further damage.

## Alerts are your answer to urgent situations
Potential-octo-lamp is open-source, so you can clone it and use it yourself. Any improvements or suggestions you may have are also welcome. You can raise an issue or [reach out](https://www.linkedin.com/in/suhasrdeshpande/) to me if you’d like to contribute to the project!


Two robots, one with a Courier logo and one with a Raspberry Pi logo, fix a leak.

raspberry-pi-leaks-header

I decided to invest in a Raspberry Pi and Courier to make sure that I would get a notification any time there was even a small leak in my home. 

raspberry-pi-leaks-thumbnail

How I Used Raspberry Pi to Detect Water Leaks in My Home

nick-headshot

Nick Gottlieb

Product notifications should never spoil a user’s experience—they should contribute to it. Otherwise, users are prone to turn off the notifications. According to Statista, [39%](https://www.statista.com/statistics/1242709/us-too-many-push-notifications-users-reaction/) of smartphone users who receive too many notifications turn them off in response.

So how do you create product notifications that delight a user no matter how harried? Consider your users and their many different experiences as you design and build your product, not after.

In other words, your product should define the notification experience.

## Notify Intelligently
Simply put, notifying your users intelligently means serving them the right content, in the right channel, at the right time.

Let’s say you work for a large airline and are currently building a mobile app to serve your travelers. Some information, like gate or flight time changes, must be served in real time to a user. Considering this scenario in the design and build phase allows developers to understand the right content, in the right channel, at the right time.

Let’s say the real-time information our user needs is a gate change. Our user is hurrying through security and stressed to the max. A real-time push notification and or text message is probably the best way to send their gate details without adding more stress to an already stressed traveler.

In our scenario, a push notification or an SMS at the right moment is the difference between a missed flight and a user who’s bound to churn and a happy traveler who will probably be a long-term user.

However, there’s a fine line between delighting and spoiling a user experience. Push notifications and SMS are best for urgent updates like delays, cancellations, or gate/terminal changes. Travelers trying to get through security with their sanity intact do not need real-time push notifications or SMSs about promotions or travel deals—that would be an example of the wrong content, in the wrong channel, and at the wrong time.

## Offer Notification Granularity
Let’s be real—today’s users [expect to maintain control](https://www.courier.com/blog/your-in-depth-guide-to-email-notification-services/), so offering notification preferences isn’t really an option anymore; it’s a must-do. Offering users control over how an app notifies them pays off exponentially in a user's lifecycle with the app.

Granular permissions allow users to opt-in and opt-out of notifications that aren't time-sensitive or essential to the users' end experience. For example, when a user installs our fictional mobile travel app, they will be delighted to see that they have the option to curate their preferences around flight reminders. You might not let them opt out of gate or terminal changes, but you do let users choose whether they want seat upgrade or flight deal notifications.

Once our user is safely through security and relaxing at their terminal—browsing options for seat upgrades or a deal on their next trip is delightful. Whereas notifying our users as they struggle to get to their terminal with dings and buzzes reminding them to UPGRADE!—spoils an already stressful airport experience.

When developers don’t consider notification as an extension of the product and don’t offer preference controls to their users, they risk spoiling their users' experiences and losing them. In fact, research shows that [40%](https://www.outerboxdesign.com/web-design-articles/mobile-ecommerce-statistics) of users will abandon an app for a competitor after a bad experience.

## Know When to Batch
To put it simply, don’t spam your users! Whether they're running late on a Monday morning or sweating their way through airport security, people rarely appreciate a stream of notifications.

Have you ever collaborated with someone via [Google Docs](https://www.google.com/docs/about/)? The tool is pretty smart about notifications. Instead of sending a separate email for every comment someone leaves, Google Docs bundles these notifications into a single email.

Be like Google Docs. Instead of overwhelming your web users with notifications, group them into batches that you send just a few times per day.

Think of our first user taking a moment in the car to silence their notifications indefinitely and probably forever, and instead, give users a reason to stay. [Android 7.0](https://developer.android.com/training/notify-user/group) shows developers when and how to create and send group notifications so that you're not inadvertently spamming your users away.

## Be Helpful
Serving your users’ information at the right time is only half the battle. Knowing what details your user needs is another.

Let’s return to our fictional user relaxing in the terminal, waiting patiently for their flight (and looking forward to their upgraded and better seat). Suddenly, they receive a text message alerting them that the flight is canceled. A total bummer.

But what if the text message also said: “click here for rebooking options”? Less of a bummer and actually kind of delightful.

When notifying users, provide all of the information they need to help them achieve their end goal.

## Use Notification Analytics
To constantly provide and optimize a better user experience, engineers and developers need to build their products with visibility. Visibility means being able to see and understand how users receive and/or react to your notifications.

If a product engineering team can’t see how notifications are performing, they can't optimize their user experience. Once the product is built, engineers and developers should have a means of analyzing notification metrics, from deliverability open rates to engagement rates. Without this information, how will our fictional travel app know when it is the wrong time to send a push notification?

## Moving Forward with Notifications That Delight and Enhance UX
Understanding that your product will ultimately define its users’ notification experiences means your engineering team can implement these ideals as they build. This is the best way to ensure your notifications enhance and don’t spoil your users’ experiences. In a nutshell:

### TL;DR
1. One universal rule that will never fail your app or your users: consider your users and their many experiences while you design and build your product—not after.

2. There are five ways to leverage notifications and make them core to your UX. Notify intelligently, offer notification granularity, know when to batch, be helpful, and use analytic visibility.

3. [Read](https://www.courier.com/customers/hospitable/) more about real-life start-ups leveraging notifications successfully and how they are doing it.

4. Or, [try](https://github.com/trycourier) delivering in the right place and at the right time for yourself!


Two paths lead in different directions, one to a bright forest and the other to a dark, desolate field with dead trees

building-product-notifications-that-users-love-header

Consider your users and their many different experiences and UX preferences as you design and build your product and notifications, not after.

building-product-notifications-that-users-love-thumbnail

Building Product Notifications That Users Love

The consumerization of SaaS has resulted in a massive handling of PII (personally identifiable information) over recent years. The security and protection of said PII has therefore become central to the foundation of a quality SaaS product, and Courier is no different. In a world where there seems to be a new data breach every time we look, users continuously demand transparency into how their data will be handled. SaaS engineering and product teams who care about how secure their apps are are just as eager to fulfill this demand. Today, in a big step toward this transparency, we are excited to announce that Courier is now fully SOC 2 Type 2 compliant. 

But what does this mean? Software security and compliance is constantly evolving and is as complicated a topic as it is important. So we wanted to take this opportunity to talk a bit about what it means to be SOC 2 Type 2 compliant, why it is important that we are, and what our journey looked like on our way here. 

## Why Courier invested in SOC 2 compliance
Courier’s mission is to make software-to-human communication delightful, currently through providing excellent notification infrastructure. Product notifications can include a wide range of content. A rideshare app may need to include a user’s location information to provide the best experience, while a banking app may send notifications with personal financial information. Because of the sensitive nature of many notifications, it is important to us, and our customers, that Courier provides safety and security for sensitive data and peace of mind for our end users.

Also worth keeping in mind is that SaaS companies tend to use other SaaS tools to build their own products, which must be disclosed to customers using sub-processors agreements. One requirement of SOC2 compliance is ensuring that all of your sub-processors are also SOC2 compliant so this is a necessary step for providing software to many other SaaS tools.

SOC compliance is one way Courier, like other SaaS companies, can reassure customers and end users that their data remains and will continue to be as protected as possible. Having a Systems and Organizations Control (SOC) report shows that we have the important security controls in place, are using best practices to prevent, detect, and remediate any  breaches, and will be transparent with our customers in how we use their information.

 ##Why all SaaS companies should be SOC 2 Type 2 compliant
To understand the steps to take to be SOC 2 Type 2 compliant, we should better understand the myriad of SOC reports a company can produce and why SOC 2 Type 2 is the best option of them all. 

A company that is SOC 1 compliant reports on security controls around financial information and objectives. SOC 2 compliance steps beyond finance and focuses on reporting on security controls concerning the five trust services principles (TSP) including security, availability, processing integrity, confidentiality, and privacy. Recently, there has been a trend towards producing and sharing SOC 3 reports in place of the more rigorous SOC 2 report. A SOC 3 report is typically generated during a Type II Audit and is intended to be a publicly available report that describes the internal controls a company has in place for SOC compliance at a high-level. They generally do not include enough information to be considered a substitute for a full Type II report, but can provide a third-party with general information on a company’s policies without divulging any sensitive information about internal controls. 

Because of the detail and depth provided, SOC 2 compliance is the best option for most companies. Of SOC 2 reports there are two types: Type 1 and Type 2. Type 1 reports are quicker and easier to generate because they cover security controls and their functions on a single given day. Their purpose is to show that the controls exist, but do not provide any context on whether the controls are used in practice. Type 2 reports, on the other hand, consist of a one-year audit period requiring evidence of effective policy and control enforcement. . While these reports require more time and resources, they also provide a better view of the effectiveness of a company’s ability to detect and repair security vulnerabilities.

Courier wanted to be able to not only state our intent, but also prove to interested parties that we are following through, which a SOC 2 Type 2 report would allow us to do. 

## What did Courier’s journey to compliance look like?
Over a year ago, when Courier started acquiring customers in industries with sensitive data like financial services and healthcare, it became important to show our customers that their data (and their customers’ data) would be in good hands. To do so, like many early stage tech companies, we went for SOC 2 Type 1 compliance first.

In order to become Type I compliant, we needed to develop a set of policies and controls for our business practices covering a range of activities from financial reporting and hiring, to how we ship code and store data. We used a software service called Vanta, a Courier customer, to develop these policies and ensure we had covered the entire set of requirements. The process after this was fairly simple - we engaged with an auditor to go over our policies and ensure we were meeting all of the criteria to be Type I compliant. After they completed their brief audit, they generated a SOC 2 Type I report for us. We completed this in November 2020.

Since Type II compliance requires going through a one-year audit period, we had to wait a full year before we could begin the process. In December 2021, we began an engagement with [Geels-Norton](https://geelsnorton.com/#home), an advisory service that is a qualified auditor for SOC 2. In order to complete their audit, they requested and analyzed evidence from Courier that we had effectively enforced all of the necessary policies and controls for SOC 2. Some examples of evidence included proof that we enforced hard drive encryption on all devices, enforced multi-factor authentication on all engineering systems, and regularly conducted meetings with our board. Once we satisfactorily completed the audit, they issued a Type II report for Courier.

## Conclusion
The journey to ensure that we are doing our best to protect our customer’s data does not end with becoming Type II compliant. In addition to continuously evolving our policies to follow best practices in the industry and baking them into our company’s culture as we scale, we are also working towards other compliance standards such as HIPAA so that we can support healthcare organizations with their customer communication infrastructure and ISO 27001. As a provider of core infrastructure, it is extremely important to our customers that we remain on the cutting edge of security practices and we remain committed to earning their trust.


The Courier pigeon is in castle fortress surrounded by defenses to protect against imminent attack

soc2-compliant-header

This post is about what it means to be SOC 2 Type 2 compliant, why it is important that Courier now is, and what our journey looked like on our way here. 

soc2-compliant-thumbnail

How Courier Became SOC 2 Type 2 Compliant

Notifications—such as emails, SMS, or push notifications from an app—are a big part of daily life. Whether for work, fun, banking, or just to chat, mobile notifications tell us what we need to attend to and when. While some users like getting notifications so that they don’t miss out, others turn off most notification channels for the sake of peace. But if it’s your application, what can you do to make sure that you’re communicating effectively with your users?

Last year, Courier introduced the Inbox Feed, an in-app repository of the notification history so that users don’t miss out on any important information. In a notifications inbox, users can view all their notifications in one place. Having such a centralized repository for notifications makes it easier for users to tackle all relevant action items at once, reduces notification fatigue, and increases focus. Courier’s Inbox Feed implementation provides ready-made components that you can use and a scalable back-end API to power those components.

Read on to learn how exactly embedding an Inbox Feed into your application can benefit your users.

## Why you need an Inbox feed
In this section, we’re going to talk about how an Inbox Feed can be a viable solution for users who have difficulties staying connected. 

### Dealing with notification overload
Most applications have more than one way of communicating with their users. Notification channels such as push, SMS, and e-mail are all point-in-time notifications. When they are sent out, a user might not be directly using the app or even available to attend to the notification. When the user does choose to review the missed notifications, they might have to check more than one channel, such as an email about a planned outage or push notifications about changes in status in the application. In that case, the user will have to pick the pieces up separately, by checking different channels, to stay informed. In the example of an email about a planned outage, they might forget about it completely and get frustrated when they can’t access your application. Separately, their email client might be filtering out certain messages so they might never have seen the email about an outage. Some users disable all notifications to avoid being overwhelmed by them, even if they specified contact preferences in your application. These users risk missing out on important information, and your product risks losing engagement with them.

This is why a central feed for notifications, inside your app, will be a huge improvement to  users' experience with your application. With a notification inbox, users can control what they attend to and when. A historical notification feed takes the pressure off users to feel like they need to respond immediately. It can improve user engagement by giving them a sense of control over how they interact with your application. 

Popular examples of historical notification feeds include Facebook’s News Feed and the notification history in Reddit or GitHub. In the widely-known Facebook News Feed, when a user enters the application, they can click on the notification bell icon to see a historical list of all events since they last logged in. These can include messages and comments to relevant pages and what their friends were up to. Reddit’s notification repository is similar: when a user enters the application, the notification bell icon is lit with a red circle and links to new messages, comments, and other relevant popular subreddits for the user to check out. In applications like these, when there is a lot of activity, a notification feed allows a user to see everything that has happened since they last used the application.

In GitHub’s case, the notification repository also includes notifications that depend on other user activity, such as assignments and review requests. Below is an example of the notification inbox on GitHub, which is accessed by clicking on the bell icon in the top right corner.

![inbox-feed-1](//images.ctfassets.net/z7iqk1q8njt4/2GjKRa3XYpCGUicNymXBKm/54e890bead09cdec1c00839d48167651/inbox-feed-1.png)

### Effective distribution of information for collaboration
Effective distribution of information is important, especially in the case of B2B SaaS applications, where teams from different companies or different departments are often collaborating to work together on more than one project. Users need to understand the scope of each project’s status and who is doing what and when. In a business application like Asana or Trello, users can get notified of any activity on their projects by email and push notifications. However, it is still essential that they can see all such updates when they log into the application, such as mentions, conversations, deadline changes, and project changes. Without the Inbox page in Asana or Trello, it would be difficult for someone working on more than one project to keep track of these updates. Scattered notifications via email or push are not as efficient in distributing that information—especially for collaboration—as a notification inbox embedded in the app. Weekly digest emails are another option, but they are inadequate for teams working within strict deadlines. 

Google Docs, for example, allows all users sharing a document to view all comments and suggestions via the Comments drop down menu, in addition to sending comments to the document’s collaborators via email. In the Google Docs interface, users can view current and past comments, and sort comments by status.

![inbox-feed-2](//images.ctfassets.net/z7iqk1q8njt4/65xyYqhkXTo2vxDn3hUZ9H/325f374b560887d2f7becff0473357cf/inbox-feed-2.png)

### Smoothing workflow automation with notification inbox
For many B2B SaaS applications, automating a workflow is the core value the software delivers. Examples include team members receiving access requests, review requests, or other notifications requiring the action of another user. These teams need to function efficiently, within deadlines, and it is up to the design of the application to ensure that all relevant information is available as clear as possible and easy to visualize. A notification feed empowers a user to get an understanding of what’s happening overall in the scope of their projects and administrative requests and attend to them as necessary. 

In early 2022, [LaunchDarkly](https://launchdarkly.com/), a software feature development platform and one of Courier’s clients, [decided to include](https://launchdarkly.com/blog/new-inbox-for-flag-approvals/) the Inbox feature in its product. LaunchDarkly’s reasoning was similar to what we have outlined here: some notifications, especially those that require an action from another user, are too important to be overlooked. To avoid the uncertainty of a user missing an email or Slack notification and potentially delaying the development or approval process, the Inbox Feed makes all notifications ever-present and accounted for, every time a user logs in. 

Below is an example of LaunchDarkly’s Inbox feed, accessed by the bell icon in the top right corner.

![inbox-feed-3](//images.ctfassets.net/z7iqk1q8njt4/7eZaAVJ0v2xiFh0EwVtYTs/1840c947b3c600107cb46c756eab971a/inbox-feed-3.png)

## Implementing an Inbox Feed is faster with Courier
If you’ve decided to implement an inbox feed feature in your app, there are two main components that you need to consider: the front-end element responsible for displaying the notifications in the user interface, and the back-end system that handles the sending of the notifications and their read/unread status. 

For the front-end, there are several open-source React libraries to choose from. At Courier, we recommend [react-toastify](https://github.com/fkhadra/react-toastify). Alternatively, you could use a framework like [react-hot-toast](https://react-hot-toast.com/) or [notistack](https://github.com/iamhosseindhv/notistack).

On the back-end, you can integrate your own notifications provider with the front-end components, or you can use [Courier Push](https://www.courier.com/docs/guides/providers/in-app/courier-push/) to power your inbox feed—and get additional features. For example, Courier Push takes care of read status: if a user already opened an email that was sent through Courier, the Inbox will show the respective notification as read. Courier’s API gives you the power to make a single function call that can notify a specific user via any already configured channel. A user can also delete notifications to keep their feed organized and uncluttered.

If you decide to build the back-end yourself, consider how you will integrate various channels and how you will scale the back-end for growth. This is ultimately a build-or-buy decision: are you ready to spend resources on building this feature, or do you prefer to use an already reliable and easily integrated service with Courier? If doing it yourself, you’ll need a developer dedicated to fixing issues, for example, if an error or delay occurs and the feeds do not update by the time a user logs in. As with all notifications, it’s vital that an inbox feed is reliable and stays relevant for its users or it risks its actual usefulness as a feature. Check out our other articles on building a [routing engine](https://www.courier.com/blog/routing-and-preferences/) and [scalable and reliable systems](https://www.courier.com/blog/scalability-and-reliability/) for what you need to know if you’re thinking of making the build yourself.

With Courier Push, you would use the configuration studio to customize the Inbox feature for your application, pictured below. Or, if you prefer, you could customize the Inbox feed [with code](https://www.courier.com/blog/react-toast-inbox-notifications/). 

![inbox-feed-4](//images.ctfassets.net/z7iqk1q8njt4/4cMhCSbpC7h85gxGekdAqc/96d6fe7006314c0489bee9c986f872a0/inbox-feed-4.png)

To get a feel for setting up an Inbox feed for your application, try it out on this [Courier-powered playground](https://reactinappnotification.com/). You can see our example below. The first image shows the notification alert as we had entered it. The second image illustrates the actual Inbox view.

![inbox-feed-5](//images.ctfassets.net/z7iqk1q8njt4/5GdSzajhiu5VHQBK8AR7Wn/e651bc3c6faf38fc57c75c1c6808ed9e/inbox-feed-5.png)

![inbox-feed-6](//images.ctfassets.net/z7iqk1q8njt4/7xitd5ihUdYOzOyIqVZl8p/0f84febb8e70c66fe61e8f43b33023ad/inbox-feed-6.png)

## Ready to give the Inbox a try?
Notifications are integral for connecting with your users and alerting them to an event, or another piece of relevant information. But without a repository of the notification history, your application might be losing out on valuable engagement with your users or hindering timely collaboration between them. Our Inbox feature strives to improve user engagement and social collaboration within applications. We see it as a valuable tool that empowers users to take control.

Read more about how to integrate Inbox [here](https://www.courier.com/blog/react-toast-inbox-notifications/). If you’re looking to learn more about the feature, check out our [documentation](https://www.courier.com/docs/guides/providers/push/courier-push/). 


octopus is looking at notifications in multiple places instead of one concise inbox

inbox-feed-header

Inbox Feed is an in-app repository of the notification history so that users don’t miss out on any important information.

inbox-feed-thumbnail

Organizing In-app Communication With Inbox Feed

nat-headshot

Nathalia Sandoval

Utilized by countless organizations, approval workflows arrange the hierarchy of teams and the sequence of tasks for the ultimate goal of improving collaboration and efficiency. In my experience as a software engineer, approval workflows are vital for peer code reviews, but that’s not the only use case. In this article, we’ll explore the difference between manual and automated approval workflows and what you’ll need to know if you decide to automate your workflow.

## What is an approval workflow?
An approval workflow is a formalized process to ensure that project tasks are completed on time, are free of mistakes, and adhere to business and product standards. It generally consists of several phases of approval through different stages of project development. In software development, for example, approval workflows are often used to manage peer code reviews. Other use cases for approval workflows include: 

* granting temporary access to particular projects or accounts within an organization 
* handling document requests such as vacation and time off requests
* reviewing invoice, budget, or expense reports

Companies can structure their approval workflow manually, where it is up to each person to understand the hierarchy of approvals and initiate requests. However, manual workflows have limitations: they are harder to audit and can slow the company down. 

In this article, we explain in more detail why manual workflows can be limiting and when companies should prefer the automated option. If you are ready to automate, we will show you how you can do it by using Courier.

## When a manual approval workflow might not fit your needs
Suppose you’re a developer who needs their code peer reviewed and your company works with a manual approval workflow. You ask a team member to review your code. But in a fast-paced environment, there are so many moving pieces that your request for a peer review gets ignored or forgotten and you yourself forget to escalate the request. Not only might you and your team be frustrated with tasks falling through the cracks, but the software feature you had been working on gets delayed for a week and project schedules get shifted. 

This is exactly the situation I experienced in my software engineering role some time ago. Code reviews became bottlenecks in the process. In a manual approval workflow, it is up to the code author to follow up on the request for a code review and escalate the request if necessary, on top of their other tasks. 

In addition to the efficiency aspect, it’s difficult to ensure consistency with a manual workflow. A high degree of consistency allows all team members to know where they stand in the process, and removes the need for “reinventing the wheel” every time a new workflow begins. While checklists can be helpful in ensuring a consistent workflow, companies rarely use or follow them. Lack of consistency in tasks can become a serious limitation when applying for process certifications or security certifications.

Finally, manual workflows often lack transparency. They are hard to analyze and troubleshoot, as the statistics on the steps are not very “readable” to a business analyst or even to an interested observer.

To address the inefficiency, inconsistency and lack of transparency of manual approvals, companies often choose to automate parts of the approval process—especially the parts that are tedious or distracting.

## What does an automated approval workflow look like?
Don’t spin up that shiny new Kubernetes cluster just yet! Automating an approval workflow doesn’t have to mean writing custom software. Tools like Slack are already available in many businesses and are well suited for simple automations. Let’s see what a Slack-based workflow could look like.

### Automated approval workflow with Slack
A useful place to start an approval workflow automation is [setting up a Slack bot](https://slack.com/help/articles/115005265703-Create-a-bot-for-your-workspace). Using a dedicated bot account for approvals will lower the risk of security issues and allow you to customize your flow more easily, without requiring you to [build a full-fledged Slack app](https://api.slack.com/start/building).

Next, you will need to create different [message templates](https://api.slack.com/messaging/composing/layouts) for the specific tasks in your workflow. Then you can set up the automations—for example, posting one of the templated messages when a new pull request is ready for review. You’ll also need to specify the actions a user can perform on such notifications. We recommend including approvals, denials, reminders, and options to escalate a request. 

As you develop your workflow, you’ll notice that the creation of these templates and automations presents further details to consider. 

## What to watch out for if you build your own automations
There are a few important factors to keep in mind if you’re creating your own automated approval workflow. The first is handling actions from users. Once the approval request is sent, what do you want to happen if it is accepted or denied? You will need to create different notification templates to alert the user making the request. The automation here also needs to stop the flow if the request is approved or denied. The next main factor is getting the timing right: if there is no response, you’ll have to decide how long until you escalate the request. What would be the right timing for your needs? For example, if a pull request isn’t approved within 30 minutes and it’s marked as P1/Urgent, you might want to escalate it right away, while other pull requests can likely wait a bit longer. If a request is ignored, to whom will the escalated request be sent? Additionally, you could add an option to manually escalate a request, interrupting the configured wait time.

You will also have to manage the database for these procedures and the status of each request any time something changes. If any database complications arise, that’s more time you have to spend on sorting out what went wrong. Your current available resources may allow you to dedicate a developer to these tasks, but consider whether, in the future, you’ll want to expand your automations to other channels like email or SMS, which will also use development resources. 

## How Courier makes automated workflows easier
At Courier, we have already implemented automations that best address customer needs, and it's all based on experience. The approval and escalation workflow is a straightforward use of [our product’s automations](https://www.courier.com/docs/guides/tutorials/how-to-automate-message-sequences/). For example, you would just make an API call from Courier to start the automation. You could then add actions to this automated notification that would trigger other automations depending on whether the request is approved, is denied, or needs to be escalated. Instead of configuring the details of the automations, you’ll just need to create the API calls. 

![approval-workflows-1](//images.ctfassets.net/z7iqk1q8njt4/7bxH46wFV2Lpmk6NjQ9jop/54d704b36f2c207345c996aa9b3ddd26/approval-workflows-1.png)

With Courier, you can create or [configure dynamic templates](https://help.courier.com/en/articles/5437032-using-the-automation-template-visual-designer) easily. Courier also makes it simple to add more communication channels, whether you need email or SMS notifications. The benefit here is that your team does not have to spend any extra time on code outside of building your product. Your approval workflow can expand, adding users or communication channels, as you develop your product.

## Example of an automated workflow with Courier and Slack
An automated approval workflow with Courier and Slack requires two components: a Slack bot, as mentioned above, and a Courier workflow that’s set up in the Courier user interface.

The relevant part of the Slack bot gets attached to the /request_access Slack [slash command](https://slack.com/help/articles/201259356-Slash-commands-in-Slack) and handles the sending of a message to Courier for the next steps. Here’s how the Node.js code that accomplishes this task can look:

```javascript
// Handle the command to start slack bot access request
app.command("/request_access", async ({command, ack, say}) => {
  try {
    await ack();

    // Message to send to Courier
    const message = `<@${command.user_id}> is requesting access ${command.text.length > 0 ? 'to ' + command.text : ""}`

    // The person requesting access who ran the command
    const requestor = command.user_id

    // First automation from template is called for initial access request.
   // Sends to first user, then waits 30 minutes before initiating the escalation request
    const { runId } = await courier.automations.invokeAutomationTemplate({
      templateId: "initial_access_request",
      profile: {
        slack: {
          access_token: process.env.SLACK_BOT_TOKEN,
        }
      },
      data: {
        message,
        requestor,
        requestId, 
      }
    });
  } catch(error) {
    console.log("ERROR " + error)
    say("There was an error sending your request")
  }
});
```

The corresponding Courier workflow that gets activated when the Slack bot sends the message to Courier can consist of the following steps:

* Send a confirmation of the request to the user who requested access.
* Send a message to the person who should handle the approval request.
* Wait for 30 minutes, and if the request hasn’t been approved by that time, send another message to the sender to tell them the request is getting escalated.
* Start the next automation that handles the escalation.

Here’s how such a workflow would look in the Courier user interface.

![approval-workflows-2](//images.ctfassets.net/z7iqk1q8njt4/4hnC7BpOevx1KJCcDveM3U/fc2602cdf51b4d0f202f7c3c26c4d623/approval-workflows-2.png)

The approval request that Courier sends with this workflow looks like a Slack message from the Slack bot—AccessBot in this case. It offers three actions on the request: Approve, Reject, and Request Further Approval.

![approval-workflows-3](//images.ctfassets.net/z7iqk1q8njt4/3qE788hhfcaB6l2OEi6fWy/a6daf46b21fc3377c9d6afbfcb53d439/approval-workflows-3.png)

## Ready to automate your approval workflow?
While manual workflows might be suitable for your needs, they also have their limitations. Automations help with these limitations, as well as ensuring efficiency, consistency, and visibility. Creating your own automated workflow will, however, cost you time and resources that could instead be spent on further developing your product. Also, keep in mind that automated approval workflows have many use cases besides peer code reviews, such as for various internal tasks or in your actual product. They can be used within any organization that needs to automate company document requests or control access to project or customer accounts, such as for support issues.

This article has explored what you need to consider in designing an approval workflow. At Courier, we’ve worked hard to create automations tailored to our customers' needs and we continue trying to find new problems that we can solve. If you’re interested in helping us out,  send us a message or follow us on Twitter at @trycourier today!


A few people hold up a paper airplane and launch it over a valley overlooked by a bright sun

approval-workflows-header

In this article, we’ll explore the difference between manual and automated approval workflows and what you need to know if you decide to automate your workflow.

Welcome to the Courier Engineering Blog

How We Built Our Documentation On Docusaurus

Build vs Buy: The “to be or not to be” of Tech

Why Courier is Now Remote-first

How I Used Raspberry Pi to Detect Water Leaks in My Home

Building Product Notifications That Users Love

How Courier Became SOC 2 Type 2 Compliant

Organizing In-app Communication With Inbox Feed

Using Courier to Build Approval Workflows

Build your first notification in minutes

Build your first notification in minutes

Product

Developers

Resources

Company