The process of switching between multiple apps to get all the information you need is counterproductive.

You may experience this problem if you have to switch between your CRM and email client to access information about your client.

Wouldn't it be great to quickly access all of the information you need directly in your email?

If you are using Missive to manage your personal and team emails and you want to display data from your own database or from a Google Sheet, Retool is a good tool to use.

Here is a tutorial on how to use the Retool integration to add this data to Missive.

What Is Retool?

Retool is a powerful and flexible tool that helps you build custom internal applications quickly and easily. It provides a simple, but powerful, drag-and-drop interface that lets you add any data source to custom applications and share them with your team.

How to Use Retool with Missive?

Retool is a great way to create a custom integration that connects a source of data with an application used by your team. You can easily use this low-code solution to build the internal tools you need to kickstart your team's productivity.

In this tutorial, we'll explore how to use Retool to display data from a Google Sheet next to your emails in Missive.

1. Creating Our Queries in Retool

To be able to see the data of a Google spreadsheet alongside conversations, we'll need to query our Google Sheet document in a Retool application embedded in Missive.

We must first create three queries in our Retool application. To do so, let's log in to Retool and create a new app by clicking on Create new > App. If you don't already have one, create a Retool account.

Then we must create our data queries:

1. One will query data from the Missive application.
2. One will query data from a Google Sheet.
3. One will merge those two data sources and display the correct data in the Retool application (Missive sidebar).

We can add a data source to your Retool application by clicking the + icon and selecting the Resource query. We will first create the query that gets the data of the selected conversation in Missive.

We can add a data source to your Retool application by clicking the + icon in the bottom left panel named Code and selecting Resource query.

To start let's create a query that will fetch the data of the selected conversation in Missive.

Below, we're calling the query getCurrentConversation , but feel free to change the name if you wish. The resource select should be set to ParentWindow and the selector input should be set to conversation.

The second query connects our Google Sheet to Retool. To create it, add a new query as we did previously. In Resource , select + Create a new resource. Then select Google Sheets and follow the instructions.

From there, we can select the spreadsheet you would like to connect to.

We can test with one that has the same columns as this one:

Lastly, we need to create the query that will merge the data from Missive with the spreadsheet. we'll simply name it query. For this one, select Query JSON with SQL as the Resource.

The query should be as follows:

select * from {{ googleSheet.data }} where Email = ANY({{getCurrentConversation.data.email_addresses.map(x => x.address.toLowerCase())}})

In a nutshell, this will find all of the rows in the spreadsheet where the email address is equal to at least one in the selected conversation in Missive.

2. Creating a UI for Missive

Now that we have the correct data, we can build a simple user interface to display it. In the right panel of the Retool editor, select the Create tab, then drag and drop the Key Value component in your application.

Then select the dropped component and in the Inspect tab of the right panel and in the Data input paste {{ query.data[0] }}.

That's it! We've got a basic but functional application.

Before we try it in Missive, let's make some stylistic changes to the Retool application so it renders better in the Missive right sidebar.

For this, select the More menu at the top-right corner, then select the Scripts and styles option.

Then paste this CSS code:

._retool-container-table1 {
   width: 100% !important;
}

._retool-container-keyValue1 {
   width: 100% !important;
}

The ._retool-container-keyValue1 class name depends on the name of your component. Make sure to update it according to your component name.

This CSS will make the component dynamically resize with the Missive sidebar width.

3. Adding Our Retool Application in Missive

It's time to try this in Missive! Copy the link View link of your application:

In Missive, open the Settings > Integrations and add a Retool integration, paste the copied link in the Retool public URL input:

Lastly, add this ?_embed=true at the end of the pasted URL. It will remove the Retool header from the integration for a far better look.

Also, make sure to disable the Enable mobile layout from your Retool app settings:

And here is the final result!

‍

Using Missive JS API from Retool

You can also take advantage of Missive JS API from your Retool app. Here are the steps to do so:

1. Enable parent window communication

By default, Retool will block any communication between the app and its parent window (Missive). You can enable it in your Beta settings:

2. Add missive-retool.js library to your Retool app

Add this script in the Scripts and styles section of your Retool app:

https://integrations.missiveapp.com/retool/missive-retool.js

3. Use the Missive JS API

You can now use the Missive JS API from your Retool app. You can, for example, add a link that will add new comments and tasks to the selected conversation:

All software needs limits. Almost every part of any software needs a hard limit. At least every part that deals with lists. In most languages and databases, this means arrays and strings.

This sounds obvious, but I suggest every engineer reading this open up their codebase and look around. Surely you have length validations here and there, but if you never dedicated half a day to go over all lists aiming to set a limit on each, you likely have several cracks remaining.

I do not mean obvious user-facing limits, such as “3 seats” or “15 days email history“ on our Free plan. I mean limits that 99% of users will never hit. For instance, pasting several paragraphs in your email subject instead of the body. Or likewise, typing the “Notes” of a contact in the “First name” field. Or everyone’s infinite loops you’ll be plagued with as soon as you introduce a public API.

The only scenario where you do not need a hard limit is when a list is always accessed through pagination. After all, pagination means there is already a LIMIT involved.

Embrace Hard Limits

I love hard limits. I love knowing they are there. I love introducing new ones with any new feature. Hard limits are key to keeping me asleep at night.

They are also low-effort; they don’t need public documentation. You naturally implement decent error messages for the few outliers that will hit them, but nobody needs to have these limits in mind to plan whether they will affect their business.

You should even make it a requirement to not have to disclose these limits. If you start seeing a significant enough number of exceptions, you’ve most likely just set it too low. The point is not to annoy or restrain users; it’s to avoid crashes. Increasing one limit from 500 to 1000 will not cause your app to crash, but it may make the difference between one user hitting that limit every month instead of every day.

It’s also an occasion to remember that our world is diverse. Stay humble, accept and embrace the fact that some of your customers will have use cases you never expected. Don’t fall into the trap of accusing people of misusing your software.

One day, we did have an organization hit a roadblock due to a limit and they emailed us. They needed to set over 25 custom fields on a contact. Did we ask them to explain their situation and figure how they could adjust their usage? Of course not. We had set that 25-limit arbitrarily at first so we could just as well increase it to 50. Problem solved!

Avoid Bikeshedding

I suggest you constraint yourself to a short list of numbers for all your limits:

1 • 5 • 10 • 50 • 100 • 500 • 1000 • 5000

These are the easiest to remember for anyone. There is also a wide enough gap between each to make decisions easy. It’s wasteful to wonder whether 100, 200 or 300 is appropriate. Any doubt 100 isn’t enough? Pick 500, that’s plenty!

“1” comes into play when used as KB or MB. What should be the max length of an HTML email body? I’m sure you’ll agree 1 MB is OK, given that’s roughly a Harry Potter book.

What size of JSON payload should our web server refuse to parse? Either 5 MB or 10 MB sounds great. The latter is what Amazon API Gateway uses.

When you reply to an email thread and we quote it under your response, where do we stop? 10 KB of quoted text for the win.

How many labels will you apply to that one conversation? I hope 100 is fine with you.

How many concurrent sessions do you need before you smell like multiple users not wanting to pay a fair price per seat? Never heard a soul needing more than 10.

The list goes on.

Hope you enjoyed this and will spend your next morning adding sweet limits all over your codebase. Do it, it’s fun! ✌️