A tag turns up on a message. An app put it there, and you’re looking at the visible end of a short list. Four things travel from a connected app into a Gmail or Microsoft 365 mailbox. Every one of them is an object your mailbox already had a name for. The traffic going the other way matters more than the list, though. The return direction decides whether the two are still telling you the same story on Friday afternoon.
- Four things get written. A label or category on a triaged message, the filing when a thread is put away, the reply when you send one, and an event when a meeting is agreed. Each one is a standard format, and your provider’s own app can read all four.
- Putting something away means two different operations. In Gmail the inbox is itself a label, so filing removes one. In Outlook it’s a real move into the Archive folder. That’s why Outlook shows it in your folder list and the Gmail version shows nowhere.
- The return direction runs on machinery both companies publish. Google notifies an app when your mailbox changes. Microsoft does the same and also offers a pull. Both expire on a clock, so a connected app keeps renewing.
- Microsoft publishes how long a mail change takes to reach an application: under a minute on average, three minutes at the outside. That’s the size of the window where your two views can honestly disagree.
- The reasoning stays in the app. Gmail and Outlook have a place to put a name and no place to put a why, and that trade buys everything else on this page.
The whole list is four items long
Start with the inventory. Vendors rarely hand you one, and this one’s short enough to hold in your head.
A label or a category on each triaged message. You’ve already met this one. In Gmail an app adds and removes them by name. The Gmail API takes “a list of IDs of labels to add to this message” and “a list IDs of labels to remove from this message” (Google for Developers, checked September 6, 2026). In Outlook the same object is a category. Why a label leaves yours alone is the Gmail part of this series. Why a category is the right object in a folder mailbox is the Outlook part.
The filing, when a thread is finished with. File once, in the app, and the mailbox is filed too. This is the write people are most nervous about. It’s worth understanding rather than trusting, and that’s the next section.
The reply, when you send one. This one carries the strongest guarantee on the page, and almost nobody notices. Gmail’s own documentation sorts labels into the ones an app may apply by hand and the ones it may not. Sent is in the second group. It’s “applied automatically to messages that are: sent with drafts.send or messages.send” (Google for Developers, checked September 6, 2026). Google also says “system label names are reserved”, so an app can’t create one of its own with the same name (same page, checked September 6, 2026). Read that as a promise about honesty rather than about plumbing. Every entry in your Sent folder is a real send. A message is in there because it genuinely left your account, from your address. That’s also why it threads under the original, the way a reply you typed yourself would.
The event, when a meeting is agreed. A time settled inside the app becomes an ordinary event on your real calendar. You see it in Google Calendar or Outlook with the app closed. A calendar only counts if you can see it from your phone.
That’s the whole list. Everything written into your mailbox is a message property, a folder move, a sent message or a calendar event. Files, hidden folders and working notes stay out of it. There’s a rule in that worth carrying into any demo. Ask a vendor to name each object it writes, in the words your provider uses for it. If the answer is a word only that vendor uses, ask where it’s being kept. The answer is usually somewhere else entirely.
The word file does two different things
Both providers have a button that means put this away. Underneath, each does something different. This is the one place where the same action in the same app has genuinely different consequences, depending on which mailbox you have.
In Gmail, the inbox is a label. Google’s documentation on system labels says they “typically correspond to predefined elements in the Gmail web interface such as INBOX” (Google for Developers, checked September 6, 2026). The same page lists INBOX among the labels that can be manually applied, alongside UNREAD and STARRED. So being in the inbox is a property of a message, held the same way every other property is held, and archiving is removing it. An app filing a thread away in Gmail makes the same kind of write it made when it labeled the thread, and it undoes the same way. Put the label back and the message is in the inbox again. In Gmail the message stays where it always was, because there’s nowhere to move it from.
In Outlook, a message has one parent folder, and archiving is a real move into a real folder. The Outlook part sets out what Microsoft says about that, including the reassuring half. Archived mail stays in the mailbox and stays searchable.
The practical difference is what you see afterward. Filing in Gmail leaves your label list exactly as it was, and the message sits in All Mail like everything else. Filing in Outlook puts a message in a folder you can open, count and drag out of. Both are equally safe. But if you’re the sort of person who wants to watch what a new app did on its first afternoon, Outlook shows you a folder filling up and Gmail asks you to search. Knowing which of those you’re about to get saves an hour of quiet suspicion in week one.
When you file it yourself first
Here’s the direction demos skip, and it’s the one that decides whether this arrangement holds up.
You clear four threads in the Gmail app on the train. All of that happened at Google, in your mailbox, with the connected application out of the loop. If the app never hears about it, by lunchtime it’s showing you a feed of work you’ve already done. Two views of one mailbox, disagreeing, and the one on your desk is wrong.
You’re covered here: both companies build for exactly this, and both publish how.
Google’s arrangement is a push. In its own words: “whenever a mailbox changes, the Gmail API notifies your backend server application” (Google for Developers, checked September 6, 2026). An application asks for that by calling a watch on the mailbox. The ask has a clock on it. Google says “you must call the watch at least once every 7 days or you’ll stop receiving updates for the user” (same page, checked September 6, 2026). Alongside it Google keeps a running history of what changed. An application that’s been away asks for the difference rather than rereading everything. That history runs on a clock too. Google says records “are typically available for at least one week and often longer”, and that the window “may be significantly less” (Google for Developers, checked September 6, 2026). An application asking from a point outside the range gets an error and “must perform a full sync” (same page, checked September 6, 2026).
Microsoft has both models and names them. Change notifications are the push, where “Microsoft Graph sends notifications to the specified client endpoint” when a resource is “created, updated, or deleted” (Microsoft Graph, checked September 6, 2026). Delta query is the pull. It “enables applications to discover newly created, updated, or deleted entities without performing a full read of the target resource with every request” (Microsoft Graph, checked September 6, 2026). Microsoft is explicit about the pairing. In its words, “delta query uses a pull model, where the application requests changes from Microsoft Graph; while change notifications use a push model, where Microsoft Graph notifies the application of changes” (same page, checked September 6, 2026).
Microsoft’s subscriptions expire like Google’s watch. For an Outlook message the maximum is “10,080 minutes (under seven days)”. For the richer kind that carries the changed data with it, it’s “1440 minutes (under one day)” (Microsoft Graph, checked September 6, 2026). Microsoft even ships a warning system for the failure this creates. It calls them lifecycle notifications, and they “alert the customer when they are at risk of missing change notifications due to the lifecycle of their subscription” (same page, checked September 6, 2026).
The thing to take from all of that sits above the numbers. Two enormous companies, working independently, both concluded that a connected application will fall behind. Both spent engineering effort on catching it up: a renewal clock, a change history, an expiry warning, a full-resync path when the history runs out. Staying in step is maintenance rather than something careful code gets for free. It runs continuously, on both sides. That reframes the question you should be asking a vendor. Everyone says their sync is two-way. Ask instead whether it recovers on its own after a week of trouble, and what you’d see while it did.
How long the two can be out of step
Microsoft publishes an answer, which is unusual and useful. For a mail message the delay between the change happening and the notification arriving is “less than 1 minute” on average, with a maximum of “3 minutes” (Microsoft Graph, checked September 6, 2026). Google publishes no equivalent table. Its push exists, and its timing stays a matter of practice rather than a written promise.
Be careful what those three minutes cover. That’s Microsoft handing the news to an application. What the application then does with it, how fast, and whether it was awake to receive it, is the vendor’s half. Platform documents stay quiet on that half. Treat the published figure as the floor, and everything above it as the thing you’re actually buying.
Microsoft names two further behaviors worth recognizing, so you read them as ordinary when you meet them. The first is replays: “your application must be prepared for replays, which occur when the same change appears in subsequent responses” (same page, checked September 6, 2026). The second is a synchronization reset. The platform returns an error that is “an indication that the application must restart with a full synchronization” (Microsoft Graph, checked September 6, 2026). Google’s version of the same thing is the full sync after an expired history.
So here’s the symptom, in the only form you’ll meet it. Something you handled in Gmail or Outlook is still sitting in the app, or something you filed in the app is still in your inbox. Give it the rest of the morning. Almost every instance of this closes by itself, because the catch-up machinery above is doing what it was built to do. If it’s still wrong the next day, the connection has lapsed rather than the app being confused. Re-authorizing it is the repair. Your phone’s mail app has been doing this quietly since long before any of this.
One more thing follows from the expiry clocks, and it’s the honest limit of the whole arrangement. Write-back is a live service. It runs while something is connected and renewing, and it stops when that stops. If what you want is sorting that keeps happening after everything is disconnected and every subscription has lapsed, the tool for that is a rule at your provider. A rule runs on their servers, independently of any app. It can’t read a message the way any of this does, and that’s the trade. Worth saying once, so you can rule it in or out.
Five questions that settle this for any product
Every one of these takes a plain answer, and each has a wrong answer.
Does filing travel both ways, or only outward? Outward only is common and perfectly respectable. It does mean the app is a place you give instructions rather than a view of your mailbox, and clearing mail on your phone will leave it stale. Ask for both directions by name.
Does read and unread travel? This is the one that quietly annoys people for months. You read a thread in the app, and an hour later it’s still bold in Gmail. It’s a small thing that happens forty times a day.
If I take one of your labels off by hand, does it stay off? The answer turns on where the app keeps the record of its judgment. If the mailbox is the record, your removal stands. If the app’s own store is the record and the mailbox is a copy of it, the label may come back on the next pass. Both designs are defensible, and only one of them matches what you expect when you delete something.
When I cancel, what’s left behind? Whatever is an ordinary object in the mailbox survives: the labels, the filing, the sent mail and the events. Get that confirmed rather than assumed. Ask about the summaries and the notes too, where the answer is different.
What does the app write that I wouldn’t be able to name? The good answer is nothing. Anything else is worth a follow-up.
Put them in the same message as the retention and subprocessor questions collected in what to ask an AI tool about your data. Send it to every supplier on the shortlist, this one included.
The part with nowhere in Gmail to live
Now the debt this series has been carrying since the Gmail part. A label holds a name. The reason lives somewhere else.
Consider what a connected app actually works out about a message. That it needs you today rather than Thursday. Why it needs you, in a sentence. That it contains an ask, which is now a task with a date on it. That you set it aside until Tuesday at eight. That it was sorted at 9:14 on Monday and by what judgment, in a record you can read and reverse. That you prefer client mail signed off with your cell number.
A mailbox is a store for messages, with a small fixed vocabulary for marking them. It was designed decades before anything had an opinion about your Tuesday. A summary, a reason, a wake time and a task all fall outside that vocabulary, in Gmail and in Outlook alike.
An application could force it. You can encode almost anything into a label name or a hidden property, and some products do. What you get for it is a mailbox with a private language written into it. That language means something to one vendor and nothing at all to Gmail, to Outlook, to your phone, or to whatever you use in 2029. It’s lock-in dressed up as integration.
The alternative is the one this whole page has described, and it’s a deliberate trade. Write into the mailbox only what the mailbox already understands. Everything written there is then legible, ordinary and removable by hand. Keep the reasoning where reasoning can be shown, explained and taken back. The consequence is clean, and you should know it before you start. Stop using the app and the vocabulary stays, the reasoning goes. Your inbox keeps three labels, several years of correctly filed mail and every message you sent. The summaries and the record of why go with the app. What that looks like on the day you actually do it, and the short list worth exporting first, is the last part of this series.
What Point writes back
Point writes four things into the mailbox you already have, and they’re the four from the top of this page.
Three labels in Gmail, called Now, Later and Other. Point creates them when you connect, and puts one of them on each triaged message. In Microsoft 365 they’re the same three as Outlook categories. So the sorting reads fine with Point closed, and one click on Now in the mailbox itself leaves only the messages that need you today.
Filing that runs both directions. Put a thread away in Point and it leaves the Gmail or Outlook inbox a moment later, filed rather than deleted. Clear it in Gmail or Outlook first and it leaves the Point feed. One inbox to keep tidy, which is the whole point of writing back at all.
Replies sent from your own address. They land in your Sent folder and thread under the original, because they genuinely went out through your account. And real events on your real calendar, there in Google Calendar or Outlook with Point closed.
Each of those four writes carries a setting of its own, deciding how much of that kind of work Point takes on unprompted. There are three positions, and the cautious middle one is in place from the start. The autonomy dial sets out what each position permits, and everything Point does is the full inventory.
Which leaves the word undo, and it deserves precision rather than comfort. Everything Point does is written down as it happens, in ordinary language, in a record you can open and read. An entry there can be reversed: a filed thread comes back to the feed and back to the inbox, a label goes off, an event comes off the calendar. Those reverse cleanly for the reason this whole page has been about. They’re ordinary mailbox operations with ordinary inverses.
A sent email isn’t one of those. Once a message has left your account it’s on somebody else’s server, in somebody else’s inbox, and no button in any product reaches it. That’s the real edge of write-back, and it’s worth being exact about rather than reassuring. An undo reaches into your mailbox, and your mailbox is where it stops. Which is precisely why sending is the one kind of work where the position on the dial is worth choosing deliberately rather than leaving where you found it.
Some parts stay in Point. The summary on each thread. The tasks lifted out of your mail. The wake time on something you set aside until Tuesday. The record of what was done and why. And what Point has learned about how you like things. They stay in Point because the mailbox has nowhere to put them. Your contacts are the exception to all of this, and they’re the next part, for a reason worth stating in a moment.
Two minutes on the first Monday
You can check everything above in about the time it takes to make coffee, and a test beats a page.
There are three things to look for on the Monday you connect, and each one takes a glance. File a settled thread in the app. It should leave your mailbox’s inbox and turn up in All Mail or in the Archive folder, depending on which provider you have. Then finish with a thread in your provider’s own app, however you normally finish with one. It should leave the app’s feed a minute or two later. Then look at a message the app has triaged, anywhere else. It should be carrying its label or category. Three checks, one cup of coffee, and you know more about a product’s write-back than a comparison table will ever tell you. The same three on the Friday are the more revealing run, because they catch a connection that held for an afternoon and drifted over a week.
That test works because of an assumption this page has been leaning on the whole way down. There’s exactly one copy of each message. Both programs agree which one it is. Every message carries an identifier that arrived with it, chosen by neither program. Agreement is easy when the thing being agreed about comes in one copy.
Your address book works differently on all three counts. The same person is in there three times, under two addresses and a nickname. Once from your phone, once from an import in 2019, and once because a client wrote from home. Which of the three is really them is an open question. Writing back into that is a different problem altogether, and merging it wrongly is one of the few things in this series that can genuinely lose you something.