Connecting Gmail starts and ends somewhere you already control. What you authorize is a Google account, and Gmail is one of the services sitting on it. That distinction carries the whole Gmail case. The account decides which permissions get named on the screen. The account decides who’s allowed to grant them. And the account is why everything you’ve built up inside the mailbox stays where you left it.
- Gmail is a service on a Google account. The authorization is recorded against the account, and that’s where you end it too.
- The organizing you’ve done lives on Google’s servers. Your labels, your filters, your threads, what’s read and what’s archived are all held at Google, so a second app reading the same account can’t rearrange it.
- A Gmail label adds. Google’s own documentation says a message can carry several at once, so a label written by an application sits alongside yours and your filing stays put.
- If your address is on a domain and somebody else runs the Workspace, they decide whether a given application can connect at all. Google gives them four settings, and one of them is blocked. That makes it a Monday email, and the answer arrives long before the Thursday afternoon you planned to start.
- Google enforces its own rules on any application that reads Gmail. They include a limit on what your mail may be used for, and an annual security assessment by an outside assessor. That’s a floor under the whole category, and questions about any one company still get put to that company.
The account is the thing, not Gmail
Almost everyone says Gmail and means the account. Separate the two once, and three otherwise confusing details fall straight out of it.
The first is what appears on the consent screen. Your mail, your calendar and your contact list are three services on one Google account. So an application that needs the calendar to find a meeting slot is asking against the same account that holds the mail. That’s the shape of the thing you’re granting against. What Point can see, and what it cannot sets out the reach in full, calendar included. If the screen is what has you hesitating, that’s the page to read.
The second is where the permission lives afterward. Google describes linked apps in ordinary terms. “You can give linked apps different levels of access to your Google Account, like basic account info and to access or modify your account data”. You can also “remove the access a linked app has to your Google Account at any time” (Google Account Help, checked September 6, 2026). So the grant sits in an account you already had, beside every other application you’ve ever let near it. You can end it right there, on your own. What that grant names, and where its edge falls, is where your email credentials are kept.
Google is plain about the limit of removing it too. If you delete a link, “the app may keep the data you’ve already shared with them” (same page, checked September 6, 2026). That’s a fair sentence, and it’s the one place on this page where the difference is worth spelling out. Ending access stops what happens next. It doesn’t reach back to what a company already holds. How long they hold it is answered by a contract rather than a settings page, which is why keeping client data out of model training works through retention clause by retention clause.
The third is which account you have, and there are two answers that matter here. Either your address ends in gmail.com, in which case the account is yours alone and the say in this is yours alone. Or it ends in your firm’s domain and sits inside a Google Workspace, in which case somebody administers it, and that somebody might be you or might be somebody else. Which of the two you have decides one section of this page and leaves the rest of it the same. If the question underneath is whether the address itself is safe to build on, that’s a different question with a worse answer in some cases, and it depends on who owns the part after the @.
What nothing changes means when the mailbox is Gmail
The claim in this article’s title is a statement about where your mailbox actually keeps its order. In Gmail the answer is unusually clean.
Your labels are at Google. Your filters run at Google, on arrival, before any client has seen the message. Threading happens at Google. Whether a message is read, starred, in the inbox or archived is held at Google. All of that lives in the account itself, which is what keeps it safe from any program you point at it. An email client, any email client, reads and writes that state over a connection. Two of them pointed at the same account see the same mailbox, for the same reason two browsers see the same website.
Google’s own description of the model is worth having in its words, because the vocabulary trips people who came from Outlook. “Use labels and search filters (Gmail doesn’t use folders)” (Google Workspace Learning Center, checked September 6, 2026). The same page describes what archiving does, which is the behavior most people are quietly anxious about when a new app starts filing things. “After you archive messages, you can still find them under the label, All Mail”, and “If someone replies to a message you archive, it returns to your inbox” (same page, checked September 6, 2026).
Those two sentences describe Gmail rather than any product, and they carry on being true while a second app is connected. Mail you archive sits in All Mail, where you can still find it, and a reply pulls the thread back where you’ll see it. Anything writing to your account through Gmail’s own interface gets Gmail’s own behavior, including that one.
The item-by-item version of what survives lives in how to switch to an AI email client, along with the short list of things you do set up again. That guide goes through your signature, your other sending addresses, a shared mailbox and your phone, in order. This page stays on the Google side of the connection.
A label is added, never swapped
Here’s the property that makes Gmail the easy one of the two accounts in this series, and it’s worth understanding rather than merely being reassured about.
In a folder system a message sits in one place. Filing it somewhere new takes it out of where it was, so anything writing into your mailbox competes for the same slot your own organizing uses. Gmail hands out labels instead, and a message holds as many as it earns. Google’s documentation for Gmail says that “you can apply multiple labels to a single message or thread, and apply a single label to multiple messages or threads” (Google for Developers, checked September 6, 2026).
So a label written by an application is an addition. The label you put on a message stays on it. The category you spent two years maintaining keeps the mail you put in it, because a Gmail label shares a message rather than claiming it. Your client-name labels, your year-end labels, the nested set somebody talked you into in 2019 are all still there, all still holding the same mail. The messages that earned a new one carry one more alongside.
Two consequences follow, and the second is the useful one. A label written by another program is an ordinary Gmail label. It looks like yours, it stands on its own once that program is gone, and it shows up in the Gmail app on your phone the same afternoon, with nothing installed there. Because it’s ordinary, you take it off the ordinary way. The sorting an application does stays reversible from inside Gmail, by somebody who stopped using that application months ago.
A label carries a name, and a name is all it carries. Why a particular message got a particular one lives in the software that applied it. That trade, plain vocabulary that Gmail understands against reasoning Gmail has nowhere to put, is the subject of a later part of this series, and it’s a more interesting trade than it first looks.
Who can say no before you say yes
This section applies to one of the two accounts, and it’s the single most common reason a connection slips past the day somebody planned it.
If your mail runs through Google Workspace on your firm’s domain, you have an administrator, and Google gives that administrator direct control over which third-party applications reach the organization’s data. There are four settings, and these are Google’s words for them. A trusted app “Can access all Google services (both restricted and unrestricted)”. A limited app “Can only access unrestricted Google services”. Under the specific-data setting, an app “Can request data access only to scopes that you specify when configuring the app”. A blocked app “Can’t access any Google service” (Google Workspace Admin Help, checked September 6, 2026).
For applications nobody has configured either way, the default is permissive. “Users can sign in with Google to any third-party app. Accessed apps can request unrestricted Google data for that user” (same page, checked September 6, 2026). An administrator can change that, and plenty have. Then a person signing in gets stopped by their own organization rather than by anything to do with the product.
Three practical things follow.
Work out who the administrator is before you book the afternoon. In a firm of seven it’s usually the owner, which is usually you, and then this section costs you nothing. Often enough to be worth checking, it’s the IT contractor who set the domain up, the person who left in 2022, or the accountant’s nephew. If nobody can tell you, that’s itself a finding, and this is a better week to discover it than the week you meant to start.
Send one email rather than three. The administrator needs three things. The name of the application, the account it will connect, and what it’s being allowed to reach. They’re approving a named application against a list, so all three in one message is the difference between a same-day yes and two weeks of clarification.
On a personal gmail.com account, the decision is yours. There’s no administrator, no console, no policy, and the only person who can approve the connection is the one reading this. If that’s your case, this whole section was information about somebody else’s afternoon.
Day one is what the afternoon itself looks like once the answer is yes, including the part with the waiting in it, and the one screen worth finding before you read anything.
What Google requires of anything that reads your mail
Most of what’s been written about connecting an app to a mailbox covers what you’re agreeing to. Google is separately requiring things of the application, and for a firm holding client correspondence that second half is the more interesting one. Somebody other than the vendor enforces it.
Google sorts the Gmail permissions by how much they expose. The ones that let an application read the content of your messages, including gmail.readonly and gmail.modify, are classed as restricted (Google for Developers, checked September 6, 2026). Restricted is Google’s most demanding category, and it carries obligations beyond simply asking you. Anything that sorts mail by reading it holds one of those.
Google’s policy for developers sets out what restricted means in practice. Four clauses in it are worth having in front of you.
Use is limited to the feature you can see. An application must “Limit your use of data to providing or improving user-facing features that are prominent in the requesting application’s user interface” (Google API Services User Data Policy, checked September 6, 2026). Mail read for one purpose and quietly used for another is a policy breach rather than a matter of taste.
Selling it is prohibited outright. The policy forbids transferring user data “to third parties like advertising platforms, data brokers, or any information resellers” (same page, checked September 6, 2026).
A person reads it only with your agreement. Human access is allowed only with “the user’s affirmative agreement to view specific messages, files, or other data”, or for security and legal purposes (same page, checked September 6, 2026). If the worry you carry is a stranger at a vendor scrolling a client’s correspondence out of curiosity, this is the clause that speaks to it, and Google wrote it rather than the vendor.
Somebody outside checks. For restricted scopes, “applications must pass an annual security assessment and obtain a Letter of Assessment from a Google-designated third party” (same page, checked September 6, 2026). Google’s scopes page adds the trigger. “If you store restricted scope data on servers (or transmit), then you must go through a security assessment” (Google for Developers, checked September 6, 2026).
Here’s what that adds up to. It’s a floor under every application in this category, set and policed by a company with no interest in any particular vendor’s success, and it’s a great deal more than the nothing that guards a mailbox password handed to a colleague. What it covers is the floor itself. How one company behaves on an ordinary Tuesday sits outside it, so does where your mail is stored and for how long, and so does anything you could verify from your own screen. So it converts neatly into a question worth putting to any supplier in writing, this one included. Do you hold a current Letter of Assessment, and who issued it. That belongs on the list in questions to ask any AI tool about your data, alongside the ones about retention and subprocessors that a Google policy leaves to you.
Three Gmail details that catch people out
Small, specific, and each one is Gmail’s own doing, which is exactly why they get blamed on the new app.
A filter that archives on arrival goes on archiving on arrival. It runs at Google, before any client is involved, so mail it puts away stays away from every app you point at the account. When a particular client’s messages land somewhere other than where you expect in week one, an old rule is a likelier culprit than new software. The switching guide is where the filter audit belongs.
Send mail as is changing, and Google is the one changing it. If you send from another address through Gmail, Google has announced a limit on that. In Google’s words, “Starting January 2027, Gmail will no longer support the ‘Send as’ feature for third-party email addresses, such as @yahoo.com or @outlook.com” (Gmail Help, checked September 6, 2026). Workspace aliases and other Gmail addresses you own carry on exactly as they are. This one belongs to Gmail alone, and it’s the sort of thing that gets attributed to the new app in February, because that’s what changed most recently in the reader’s own life. Worth knowing which of your sending addresses falls on which side of it now.
A Google Group delivers mail to people, and a connection needs an account. Plenty of firms have an info@ or accounts@ that reaches several people, with nobody signing in behind it. A sign-in is what a consent screen needs, so a group takes a different route, and so does an address somebody reads for you through Gmail’s delegation. Both have answers, and how to switch to an AI email client handles shared and delegated addresses properly.
What Point asks your Google account for
Point connects to the Gmail account you already have and reads it in place. You keep your address. Google carries on taking delivery and holding the mail, and the bill you pay them is the bill you were paying. The sign-in happens on Google’s page, and your password goes where it has always gone. What comes back is the named, listed, revocable grant described above, in Google’s terms rather than anything Point invented.
What Point works out is written back into the account as ordinary Gmail labels. So the sorting reads the same from the Gmail tab you had open yesterday, and from the Gmail app on your phone, with nothing new installed there. Putting a thread away in Point puts it away in the mailbox too, with Gmail’s own archiving behavior. What exactly gets written, and what happens in the other direction, is the part of this series after next, because it deserves more room than a paragraph here. Your contacts come across with the duplicates merged, and the reason that matters more than it sounds is a later part still.
Each kind of work has its own level, and you set them one by one. A level runs from Point staying out of it, through preparing something for you to approve, to Point handling that kind of work itself. Every one of them starts in the middle position on the day you connect. Each level is a setting you can see. The work Point does under them is listed afterward in a record you can read, and you can take an action back out of it. Setting how much your inbox does on its own is where each position stops, and everything Point does is the full inventory.
The limits are Google-shaped, and they’re worth stating in the same breath as the rest. Point needs a sign-in behind the address. Point needs an administrator who allows third-party applications. And Point needs an address on a domain you control. Those are the three cases where the answer is no before any product is chosen, and it’s the same answer whichever client you read your mail in.
What Gmail has and the other does not
Strip this page back and one property is doing most of the work. A Gmail message can be in several places at once. That’s why another application can write its judgment into your mailbox while your own stays exactly where it is. It’s why the writing comes back out with an ordinary label removal. And it’s why running Gmail and something else side by side for a month is an ordinary month rather than a transitional state anybody has to manage.
Microsoft’s account works the other way. A folder holds a message once. The permission is granted at a different company under different words. The administrator sits in a different console with different settings. And the judgment lands in an object that isn’t a label at all. That makes it a genuinely different arrangement, and one that stands on its own terms. A page about it that was this one with the nouns swapped would quietly get three things wrong.
So the honest thing is to start that one from the other end, with the folder.