When we surveyed SalesSheet users in January, we asked a simple question: "What is the number one thing that still makes you leave SalesSheet during your workday?" The answer was overwhelming. Eighty-three percent said email. They were logging calls in SalesSheet, managing pipelines in SalesSheet, taking notes in SalesSheet -- and then switching to Gmail in a separate tab to actually communicate with prospects.
That tab switch is not just an inconvenience. It is a broken context loop. You look at a deal in your pipeline, you think "I should follow up with Sarah," you switch to Gmail, you search for Sarah, you lose context on the deal, you write a generic email. The CRM knows everything about the deal. The email client knows nothing about it. We had to fix that.
A CRM without email is a database. A CRM with email is a workspace. That distinction matters more than any feature on our roadmap.
This is the decision that generated the most internal debate, and I want to explain our reasoning transparently because it is unconventional.
Most CRMs that integrate with Gmail use OAuth 2.0. The user clicks "Connect Gmail," a Google consent screen appears, the user grants permissions, and the app receives an access token. It is the standard approach. It is what Google recommends. And we chose not to use it as the only option.
Here is why. OAuth tokens expire. When they expire, the integration breaks silently. The user does not realize their emails stopped syncing until they notice a gap in their timeline three days later. Refreshing tokens requires background processes that need to handle rate limits, token rotation, and edge cases where Google revokes access without notice. Every CRM that uses OAuth has a support queue full of "my email stopped syncing" tickets.
We offer both options in the "Connect Gmail Account" dialog. Users can choose "App Password" (marked Recommended) or "Google OAuth" for one-click setup. An App Password is a 16-character password that Google generates specifically for third-party apps. It does not expire (unless the user revokes it), it does not require token refresh logic, and it provides the same IMAP/SMTP access that we need. When a user enters their credentials and clicks "Test & Connect," SalesSheet verifies IMAP first, then SMTP, showing step-by-step progress. The connection is stable for months without any maintenance.
The obvious concern: is an App Password less secure than OAuth? Technically, yes -- OAuth is scoped (we only request the permissions we need), while an App Password grants full IMAP/SMTP access. But in practice, the security difference is minimal for our use case. We only use the credentials for IMAP read and SMTP send. We do not access Google Drive, Calendar, or any other Google service. And App Passwords require the user to have 2FA enabled on their Google account, which is actually a stronger security baseline than many OAuth implementations.
The real security question is how we store the credentials, and that is where we put our engineering effort.
Whether you connect via OAuth or App Password, your credentials are encrypted at rest using AES-256-GCM. The encryption key is derived from a combination of your user ID and a server-side secret that is rotated quarterly. The encrypted credentials are stored in a dedicated secrets table that is physically separated from the main application database.
Decryption only happens at the moment we need to establish an IMAP/SMTP connection, and the decrypted credentials exist in memory only for the duration of that connection. They are never logged, never cached, and never written to disk in plaintext. If our application database were compromised, the attacker would get encrypted blobs that are useless without the server-side secret. If the secrets table were compromised, they would get encrypted blobs that are useless without the decryption key derivation function.
We do not cut corners on credential security. Your email password is the key to your professional life. We treat it with the gravity it deserves.
Connecting to Gmail is straightforward. Two-way sync is where the real engineering challenge lives. Here is what "two-way sync" actually means in practice.
Every 60 seconds, we poll your Gmail inbox via IMAP for new messages. When a new email arrives, we check the sender's address against your SalesSheet contacts. If there is a match, the email is attached to that contact's timeline. If there is no match but the email domain matches a company in your CRM, we flag it as a potential new contact. If there is no match at all, we ignore it -- we are not building a full email client, just syncing CRM-relevant communication.
The 60-second polling interval is a deliberate choice. Gmail's IMAP IDLE (push notifications) is unreliable at scale and adds significant infrastructure complexity. A 60-second poll means your emails appear in SalesSheet within a minute of arriving in Gmail. For a sales workflow, that latency is imperceptible. We optimize the poll by only fetching message headers first, then fetching full bodies on demand when the user opens the email in SalesSheet.
When you compose and send an email inside SalesSheet, we send it through your Gmail account's SMTP server using your credentials. This means the email appears in your Gmail Sent folder, includes your real email signature, and threads correctly with any prior conversation. The recipient sees your actual Gmail address as the sender -- not a "sent via SalesSheet" address or a weird relay domain.
This was a firm design decision. Some CRMs send emails from their own servers and BCC a copy to the user's email. The problem with that approach is deliverability. Emails sent from CRM relay servers often land in spam because the sending domain does not match the "From" address. By sending through the user's actual SMTP server, we inherit their domain's reputation, SPF records, and DKIM signatures. Deliverability is identical to sending from Gmail directly.
The trickiest part of two-way sync is thread matching. When a reply comes in, we need to match it to the original conversation. Gmail uses a combination of Message-ID, In-Reply-To, and References headers for threading. We parse all three to build a thread graph. When you view a contact's timeline in SalesSheet, you see the complete email thread -- your messages and theirs -- in chronological order, just like you would in Gmail. Except now the thread is attached to a deal, annotated with CRM context, and visible to your entire team.
Once we had sync working, we needed to design the email experience inside the CRM. We iterated through four designs before landing on the compact view that shipped.
The first three designs all made the same mistake: they tried to replicate Gmail. A full inbox view with folders, labels, search, filters, and a reading pane. It was comprehensive and completely wrong. Sales reps do not need a second email client. They need to see their sales-relevant emails in the context of their deals.
The compact view shows one row per email thread: sender avatar, sender name, subject line, preview text, timestamp, and the associated deal or contact. That is it. No folders. No labels. No categories. Clicking a row expands the full thread inline. Reply and forward buttons appear at the bottom of the expanded thread. You can handle 90% of sales email without ever opening Gmail.
The view is filterable by contact, deal, pipeline stage, or date range. Want to see all emails related to deals in the "Proposal Sent" stage? One click. Want to see every email exchanged with Acme Corp across all deals? One click. These are queries that would require mental gymnastics in Gmail but are trivial when email lives inside the CRM.
We did not build an email client inside a CRM. We built a CRM that understands email. The distinction matters.
Three things surprised us during the development of email integration.
First, email volume is lower than we expected. The average SalesSheet user sends 11 sales-related emails per day. That is far fewer than the 40-50 total emails they receive. The filtering we do (only syncing CRM-relevant emails) eliminates 75% of inbox noise. Users told us this was one of the most valuable aspects of the feature -- seeing only the emails that matter for their deals, without the newsletters, internal threads, and spam.
Second, the hardest bugs were timezone-related. Email timestamps are notoriously inconsistent. Some email servers use UTC, some use the sender's local timezone, and some use the server's timezone (which might be different from both). Getting emails to appear in the correct chronological order on the contact timeline required normalizing every timestamp to UTC on ingest and converting to the user's local timezone on display. We found and fixed 14 timezone-related bugs in the first two weeks.
Third, attachment handling was more complex than the email itself. Inline images, PDF attachments, calendar invites, signature logos -- every email attachment type has its own MIME encoding and display requirements. We spent almost as much engineering time on attachment rendering as we did on the core sync engine. The result is that attachments display correctly in the SalesSheet email view, but it was not cheap to build.
Email integration shipped three weeks ago and is already the second most-used feature in SalesSheet (after the pipeline board). Our next priorities are Outlook/Microsoft 365 support, email sequences (automated multi-step follow-up campaigns), and AI email drafting powered by Voice DNA. The foundation is solid. Now we build on it.
If you have been waiting for email inside your CRM before making the switch, the wait is over. Connect your Gmail account in under two minutes and start seeing your sales emails in context.