Two worries send people looking for their email activity. One is about the account: did somebody get in who shouldn’t have. The other is about the mail itself, that something in here happened without you, and you’d like to know what it was and when. Two separate records answer those, kept by two separate parties. Mix them up and you’ll read a list of sign-ins, wondering why it says nothing about the thread that moved.
- Your provider’s record is about access. Sessions, devices, places, and the notice that arrives when one of them looks wrong.
- An activity log is about intent. What was done, to which message, at what time, and on what reasoning.
- Once you’ve authorized anything on your mailbox, the access record sees your own work and the tool’s as the same session. The second record closes that gap.
- What’s on the record and what can be put back are different sets. The rows you can’t reverse are the ones to read first.
The record your provider keeps
Your mail provider keeps a record of who reached the account. Recent sign-ins, the device, the rough location, sometimes the way the connection was made. It answers one question and answers it well: was that me. When the likely answer is no, that same record sends the message almost everyone has now had, the one carrying Google’s or Microsoft’s name and the words unusual activity, or a sign-in that wasn’t recognized.
That record matters, and those notices are worth taking seriously. The boundary is the part worth being exact about. It’s a record of access, so it can tell you a session opened from a machine in a city you’ve never visited. Access is the whole of what it covers. Access and action are different subjects. Your provider only ever had the first one. On a mailbox where you were the only one acting, that was enough, because the only thing acting in there was you.
Why a connected mailbox needs a second one
Something changes the day you connect a tool to your mailbox. It’s easy to miss, because from the outside the mailbox looks the same as it did yesterday.
You authorize the connection. From then on, the tool’s work reaches your provider as an authorized session. That’s the system working the way it should, rather than a loophole. You said yes, and your provider is honoring what you said. It also means the access record now reads your own work and the tool’s as the same person. Both are legitimate. Both, as far as that record can see, are you. The question it was built for still gets an answer, and the answer has quietly stopped being interesting.
So the record that can still say what happened has to be kept by whatever had the intention. Your assistant is the only one that knows a thread was filed rather than merely moved. It knows the filing happened at 8:40. It knows the thread went where it went because it read like a receipt rather than like a client. The mailbox holds the outcome, and the reason stays with whatever acted. Six weeks later there’s a thread in a folder, and the folder can’t say whether it arrived by rule, by judgment or by mistake.
So the case for an activity log is narrow, and it’s hard to argue with. The record you’ve relied on for twenty years stopped covering half of what happens in your inbox the day you connected something to it. A replacement has to come from the only party that knows why.
What one row has to say
A log is worth as much as the question you can put to it. There are three grades of the thing.
The first is a list of events. Something happened, here’s the time. It’s cheap to build and close to useless. All it establishes is that the software was busy. Reading it gives you the feeling of oversight rather than the thing itself.
The second is an explained event. What was done, to which message, when, in a sentence you’d use yourself rather than a code you have to interpret. Point’s log is this one. The day’s actions sit in order with their times. Mail sorted, a thread filed away, a reply drafted, a task created. Any one of them opens into the full sentence, with the thread it touched one link away. Now the questions a person actually has can be put. Why is this not in front of me, and where did it go.
The third is the entry underneath. The raw record of the action, the exact data behind it, sitting below the plain sentence. It’s there for the occasions when you’d rather check than take a summary on trust. Most weeks nobody goes down there. The week you want it is the week it matters. A log that stops at the sentence is asking you to accept an account of an action written by the thing that took the action.
The step from the second grade to the third is the step from a log you read to a log you can test. A log you can test is the one that holds up when somebody asks you to account for what your software did.
Reading it without making it another inbox
You can leave most of it unread. Reading every row rebuilds by hand the work you were trying to put down. Someone who reads every row has bought an assistant and kept the job. They’ve also stopped noticing, because attention spread evenly over two hundred routine filings stops being attention.
The reading that pays follows the dial. Where a kind of work prepares something and waits for your yes, the log is a receipt for a decision you already made. It earns its keep on the Thursday you can’t remember whether you made it. Where you’ve raised a setting and the work now happens while you’re with a client, the log is the only surface that work has. That’s the trade the top of a setting makes, and setting how much your inbox does on its own is where the trade is argued out.
Which gives a habit that survives a real week. Read the log for the settings you’ve raised, and let the ones you’re still supervising go by. Read for disagreement rather than for volume. A big number of actions is just a big number. The row that tells you something is the one you’d have handled differently. Read closely for two weeks after you raise a setting, and seldom after that.
Then treat a disagreement as being about the setting rather than about the row. One action you’d have taken differently is a wrong call, and every assistant makes those. Two of the same kind inside a month is a setting sitting in the wrong place, and the answer is to lower it. Resolving to keep a closer eye feels like a control, and it lasts about nine days. Lowering the setting is the one that holds.
The first time a kind of action comes up at all is a different moment. Something Point hasn’t done before waits for you, rather than turning up in the record afterwards, which is the subject of approving anything new before it acts.
What is recorded and what can be reversed
These are different sets, and the difference is the most useful thing on this page.
Everything Point does lands on the record. The sorting, the filing, the drafts, the tasks, the back and forth that finds a meeting slot. All of it reaches the log whether you were consulted about it or not. Work done at the top of a setting produces a row exactly as work you approved does. Completeness is the easy half, and it’s the half a log can actually deliver.
Putting something back is narrower. Point’s own moves are Point’s to reverse. A thread filed away returns to the feed, and what’s filed is still there while it waits. A message that’s been delivered is a different category. It’s sitting on a server that belongs to somebody else, and no product reaches in there to retrieve it. What can be taken back, and what the reversal actually does, is the subject of undoing what Point did.
Which means the rows you can’t reverse are the ones to read first, and they’re the ones people read last. A filing you disagree with costs you a moment. A message that went out at four on a Friday under your name stays out. What a log can offer is the earliest possible knowledge that it went, and the exact words that went with it. That’s worth more than it sounds. Knowing at 4:30 with the text in front of you is the difference between a short second message that evening and a phone call on Monday about a message you didn’t know had gone.
What the log is not
It’s a record of your assistant’s work. It says what Point did. Who reached your account is your provider’s question, and the answer lives in your provider’s account and stays there.
Your mail stays where mail lives. A row records an action and links to the message it acted on. The detail underneath a row is the data behind the action rather than the thread.
Each business keeps its own. If you operate more than one, the separation between them holds here too, which is keeping one business isolated from another.
A supplier answers the supplier questions. How long records are kept, who inside a vendor can see them, and what happens to them when you leave: a company answers those, rather than a screen. What to put to a supplier, and what to accept back, is questions to ask any AI tool about your data.
If handing any of it over still feels early, that’s a fair place to be, and learning to trust AI with client work is the better page to start on. What Point can be asked to do in the first place sits on the benefits page.
Common questions
How do I see my own email activity?
It depends which of the two worries brought you. Access lives with your mail provider, and always will. What your assistant did lives in its own log. In Point that’s a surface in the product rather than a report you have to request, showing the day’s actions in order with the thread each one touched a click away. Both records exist for the reason this page is about. With a tool connected, the provider’s record shows that tool’s work as yours, so the assistant’s own log is the one that can tell the two apart.
I got a message about unusual activity on my account. Was that Point?
Almost certainly not, and the reason is structural rather than reassuring. Those notices fire on a sign-in your provider doesn’t recognize. An assistant you authorized signs in with your say-so, so the session looks familiar. The other thing worth knowing is that those exact words are among the most copied templates in phishing, precisely because they make people hurry. Look at the account through the route you normally use, never through a link inside the message itself.
Does the log contain my emails?
No. It’s a record of actions, so a row holds what was done, when, and a link back to the message it was done to. Your mail stays in your mailbox. This matters more than it sounds. A log that duplicated your correspondence would be a second copy of everything sensitive you own, sitting somewhere you weren’t thinking about, in order to answer a question that only needs the action.
How far back does it go?
That’s a supplier question rather than something you can read off the screen, and it sits with retention, deletion and who at a vendor can see a record. Worth asking in as many words before you rely on the log as your account of what happened, because a record that answers your professional obligation has to outlive the month it was written in.
If I run two businesses, do they share one log?
No. The isolation Point holds is between the businesses you operate, and the record follows the business it belongs to rather than pooling into one feed. That’s the right shape for the same reason the rest of this page argues. A log is only as good as its boundary, and one merged record would be a place where one business’s work showed up inside the other.
The short version
There are two records, and they answer different questions. Your provider knows who reached the account. Point is the only one that knows why the work happened, and once a tool is connected, that second record is doing the job the first one used to. A row is worth having when it explains itself in a sentence, links to what it touched, and opens onto the underlying entry when a sentence isn’t enough. Read it against the settings you’ve raised. Read it for the actions you’d have taken differently. Treat two of the same disagreement as an instruction to lower a setting rather than to watch harder. Everything is on the record, and what can be put back is a smaller set than that, which is why the rows you can’t reverse are the ones to read first. Point is the product the record is kept by.