Here is a massive feature request: email integration! Specifically Google & Microsoft, that seems to be the most logical starting point… especially Google
Currently, none of the no-code app builders that I’m aware of have ready-made integrations with email clients. Usually you see that kind of functionality in CRMs like Hubspot or Insightly or Pipedrive for example. And it makes sense, cause it’s tricky.
But for additional high-level context, this would be so helpful because my clients often rely on the portal for certain comms (like inter-team comms or client comms), but then there are ALWAYS the instances where users don’t adopt the portal wholesale, resulting in some object-bound communication (like the discussion of a project) occurring through a channel external to the portal (e.g. email). Another example of the value here is in CRM use-cases. A CRM without email management is ALMOST pointless, if critical to your CRM workflows is tracking comms.
So if users had the ability to connect to their Gmail account for example, then here is what I would want to see:
All emails (that match user-defined criteria) sync into a table. Whether or not it syncs into a dedicated Noloco collection (like how Noloco has a User table), or into Airtable directly (or whatever your external data source is), is another question. If from a technical standpoint it has to be a Noloco collection, then we would need the ability to easily and perpetually write new entries in the table into our external data source (e.g. a user-defined table in Airtable). That could be a native setting for syncing them, or at the very least allowing Noloco workflows AND Make/Zapier to be able to push that data from the Noloco collection into the external table.
I would imagine users would rely on Noloco workflows or Make/Zapier to build conditions that (1) detect new emails that Noloco extracts, and then (2) associate/auto-link them to related records such as Contacts or Projects for example.
Absolutely CRITICAL to this integration would be auto-threading. So, when Noloco picks up the 15th email response in one given thread, it knows that Gmail thread ID (for example), and then automatically links that new email response to that thread. So that might necessitate two tables, an “Emails” table and a “Threads” table. Not sure how to slice it and dice it, but I see this as necessary because if subsequent messages are siloed from the overarching conversation, then this is either (1) useless, or (2) requires Make (or similar) automation in order to auto-associate new thread replies to the overarching thread (so you can easily navigate/understand emails in context within your Noloco UI). That kind of threading via automation platforms like Make is a nightmare. I’ve tried building that kind of automation for myself and it gets complex very quickly.
I don’t see attachments as a necessary part of the email extraction, at least not for V1. This can be easily solved for by the integration automatically pulling the email link. So in the Noloco UI, a user can click an action button that opens that email directly in their browser, then they can view the attachments. However, if its technically viable for a V1, then yes please automatically extracting attachments would be massive.
I don’t see SENDING email as necessary for V1, though it would be nice. But at least syncing emails into Noloco/your external data source would be massive for overall data/comms visibility, and then subsequently relating those communications with particular objects (like projects for example).
Rest assured, this is incredibly top-of-mind, getting the execution right is going to be important though, so this feedback really helps.
If you don’t mind, I’ve a few follow-up questions:
If from a technical standpoint it has to be a Noloco collection, then we would need the ability to easily and perpetually write new entries in the table into our external data source (e.g. a user-defined table in Airtable).
What’s the need behind this?
If the emails are the be read in Noloco, then why not just keep them in Noloco, assuming they link to the relevant Contact / Company tables?
This would be great to understand more, and would increase the complexity massively.
I don’t see SENDING email as necessary for V1, though it would be nice. But at least syncing emails into Noloco/your external data source would be massive for overall data/comms visibility, and then subsequently relating those communications with particular objects (like projects for example).
This is actually a surprise to me, I assumed a lot of the value would be in sending, as there are not too difficult ways of syncing email into a table with Make/Zapier, but sending is still a pain.
Good question - ultimately I almost never silo objects of the same overarching dataset betwen two data sources (e.g. projects in Noloco and tasks in Airtable). From a migration, architectural, and even business intelligence standpoint it’s just not a good idea.
When moving data or migrating wholesale, it is easier to have that one datasource rather than moving data from two different sources into one
When building new features it is obviously easier since you’re not connecting two different datasources. You only have to worry about the architecture of your main database.
When building dashboards it is also easier as external sources like Airtable play better with external BI tools than Noloco does.
Ultimately what I said (and what you quoted/responded to) was more so in light of heavy external data source usage (i.e. a builder relying on Airtable or SmartSuite as the primary datasource for their app rather than Noloco). But of course, for apps built on Noloco Tables it would make sense to keep the email records in there, naturally.
I’m glad you followed up on this point! In retrospect, that point is definitely shaped by my own experience/my own clients’ needs, rather than being indicative of the whole. Mostly, my clients have wanted an easy way to at least view their emails within their app, in context (e.g. linked to a contact or project).
Example of the value of at least viewing emails: You can imagine a project manager opening a project, looking at the native comments/conversation with the client, not finding what they’re looking for, then scrolling down a tiny bit more to see recent emails with the client to find the context/info they’re looking for. That accomplishes a lot, and has been what most of my clients’ use-cases have revolved around. But of course, sending would DEFINITELY be even better–much better!
As you said, extracting the emails can be done in Zapier/Make but seamlessly threading conversations and viewing them as a whole isn’t as easy as it sounds.
Example & Other Complications
An email is sent to multiple recipients. Is one record or multiple records created, with one permutation for each recipient?
Moreover, how are the BCC recipients handled? If one record is created for everyone to view, then the challenge becomes appropriately hiding those email addresses. But the values in those fields don’t inherently mean anything to Noloco (presumably), which means hiding the hypothetical BCC field would have to be done by Noloco permissions (e.g. current user can NOT see BCC values except for their own name if they exist in it, OR if the current user is the sender of the email, they can see all BCC values)
I’m sure you’ve thought of this but if for any reason you’re thinking the integration would produce one permutation for each recipient then scalability becomes an issue with all the email records.
Also, linking back to the email URL is tricky because if there are multiple permutations, you would need each one to take into account the email’s URL for each specific recipient’s email which is virtually impossible unless you’re connected to the email account of every single possible recipient LOL.
Conversely, if there is only one record per email, then whose email inbox would the email link back to (given a hypothetical “Email Link” field that the integration auto-populates)? The only logical answer would be the sender’s, in which case that URL field would only ever be for use by them.
And then what about a thread with three recipients, but then someone clicks “Reply all” and adds two new recipients? Additionally, only one of those recipients is a portal user, while the other is not. So how are failed auto-link conditions handled? Additionally, the two new recipients are from differing organizations. Who sees what in Noloco? Again, you have to fall back on permissions.
How about maintaining chronology with email records? The hypothetical Emails table should have a “previous email ID” field and a “next email ID” field which the Noloco integration would automatically fill (or link) to the appropriate records. Otherwise, it would become hard to track messages within the same thread.
How about the UI? Right now list/rows/table seems the most logic choice for email conversation, and yet that is quite compressed and unnatural compared to a typical email client UI which is usually semi-expanded (you can just scroll up and down to read the surrounding emails in the thread) and vertical.
Would builders be able to choose the email body extraction method? What is the best method for pulling the data? Should the integration pull the body in HTML by default, then give the builder the option to choose between outputting into the record the raw HTML vs the HTML converted to markdown?
The more I think about this, the more I’m realizing builders would need a configuration option for sync conditions/rules. I’d recommend Make’s approach, that is, email client-specific queries such as :unread, or :[label].
Also need to consider the integration’s support for multiple inboxes. If it can’t connect to more than one inbox at a time, that would be problematic for many use-cases, especially a CRM where inbound accounts and outbound accounts could be from any number of team members.
The way I’m thinking about it, it would exist as something slightly higher-level than a standard data source, and we would provide new UI for both viewing emails and writing emails - because as you pointed out, with threading, HTML, rich-text creating, it’s not quite as simple as everything we’ve currently got.
As for recipients and linking etc, I would probably lean on the approach taken by existing CRMs in terms of how the associate email recipients with contacts, companies etc.
But thanks for the very detailed feedback, this will help a lot when we put pen to paper to plan this out
