Two different worries send people looking for their email activity. One is about the account: did somebody get in who should not have. The other is about the mail itself, that something in here happened without you and you would like to know what it was and when. Those are answered by two separate records, kept by two separate parties, and mistaking one for the other is how people end up reading a list of sign-ins wondering why it says nothing about the thread that moved.
- A mail 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 have authorised anything on your mailbox, the access record can no longer tell you apart from the tool working for you. That gap is what the second record exists to close.
- What is on the record and what can be put back are different sets, and the rows that cannot be reversed are the ones worth reading 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 is what produces the message almost everyone has now received, the one carrying Google’s or Microsoft’s name and the words unusual activity, or a sign-in that was not recognised.
Nothing here replaces that and nothing here argues against taking those notices seriously. What is worth being exact about is the boundary. It is a record of access, which means it can tell you a session opened from a machine in a city you have never visited, and it can tell you nothing whatsoever about what was done during it. Access and action are different subjects. Your provider only ever had the first one, and on a mailbox that nothing is connected to, that was enough, because the only thing acting in there was you.
Why a connected mailbox needs a second one
Something changes on the day you connect a tool to your mailbox, and it is easy to miss because from the outside it looks like nothing happened.
You authorise the connection, and from then on the tool’s work reaches your provider as an authorised session. That is correct behaviour rather than a loophole. You said yes, and the provider is honouring what you said. But it also means the access record has stopped being able to separate you from the thing acting on your behalf. Both are legitimate. Both are, as far as that record can see, you. The question it was built for still gets an answer, and the answer has quietly stopped being interesting.
Which is why the record that can still say what happened has to be kept by whatever had the intention. Only the assistant knows that a thread was filed rather than merely moved, that it was filed at twenty to nine, that it was filed because it read like a receipt rather than like a client, and where it went. None of that can be recovered from the mailbox afterwards, because a mailbox stores outcomes and not reasons. Six weeks later there is a thread in a folder and no way to tell whether it arrived there by rule, by judgment or by mistake.
So the case for an activity log is not that automation is alarming. It is narrower and harder to argue with: the record you have been relying on for twenty years stopped covering half of what happens in your inbox on the day you connected something to it, and 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, and there are three grades of the thing.
The first is a list of events. Something happened, here is the time. This is cheap to build and close to useless, because all it establishes is that the software was busy. Reading it produces the feeling of oversight rather than any oversight.
The second is an explained event. What was done, to which message, when, and in a sentence you would use yourself rather than a code you have to interpret. Point’s log is this: the day’s actions in order with their times, mail sorted, a thread filed away, a reply drafted, a task created, and 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 for the occasions when you would rather check than take a summary on trust. Most weeks nobody goes down there. The week you want it is the week it matters, and 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, and only one of those is any use to you when somebody asks you to account for what your software did.
Reading it without making it another inbox
The obvious way to get this wrong is to read all of it, which rebuilds by hand the work you were trying to put down. The log is not a queue. Someone who reads every row has bought an assistant and kept the job, and has also stopped noticing, because attention spread evenly over two hundred routine filings is not attention.
The reading that pays follows the dial. Where a kind of work still prepares something and waits for your yes, the log is a receipt for a decision you already made, useful mainly on the Thursday you cannot remember whether you made it. Where you have raised a setting and the work now happens while you are with a client, the log is the only surface that work has. That is 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 have raised, not the ones you are still supervising. Read for disagreement rather than for volume, because the number of actions is not information and the only row that tells you anything is one you would have handled differently. Read it closely for a fortnight 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 would 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 rather than to resolve to keep a closer eye. Resolving to keep a closer eye is not a control. It is the absence of one, propped up by good intentions, and it lasts about nine days.
The first time a kind of action appears at all is a different moment, and it does not reach the log unnoticed: something Point has not 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.
Nothing Point does happens off the record. The sorting, the filing, the drafts, the tasks, the back and forth that finds a meeting slot: all of it lands in the log whether you were consulted about it or not, and work done at the top of a setting produces a row exactly as work you approved does. Completeness is the easy half, and it is the half a log can actually deliver.
Putting something back is narrower. Point’s own moves are Point’s to reverse, so a thread filed away returns to the feed and nothing filed is lost while it waits. A message that has been delivered is a different category, because it is 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 irreversible rows are the ones to read first, and they are 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 cannot be pulled back, so the only thing any log can offer is the earliest possible knowledge that it went, and the exact words that went with it. That is not a consolation prize. Knowing at half past four with the text in front of you is the difference between a short second message that evening and a phone call on Monday about something you did not know had been sent.
What the log is not
It is not a security record. It says what your assistant did, not who reached your account. If the worry is a stranger rather than your own software, the answer is in your provider’s account and stays there.
It is not a copy of your correspondence. A row records an action and links to the message it acted on. The mail itself stays where mail lives, and the detail underneath a row is the data behind the action rather than the thread.
It is not one record spanning everything you run. If you operate more than one business, the separation between them holds here too, which is keeping one business isolated from another.
It is not an answer to the supplier questions. How long records are kept, who inside a vendor can see them and what happens to them when you leave are answered by a company rather than by a screen. What to put to a supplier, and what to accept back, is questions to ask any AI tool about your data.
If the reason you are reading this is that handing any of it over still feels early, the log is the wrong place to start and learning to trust AI with client work is the right one. What Point can be asked to do in the first place is listed 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, which in Point is 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. The reason both exist is the point of this page: with a tool connected, the provider’s record shows that tool’s work as yours, so the assistant’s own log is the only 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 a provider does not recognise, and an assistant you authorised does not look unrecognised to it. The other thing worth knowing is that those exact words are among the most copied templates in phishing, precisely because they make people hurry. A message of that kind is a reason to 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 is 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 were not thinking about, in order to answer a question that only needs the action.
How far back does it go?
That is 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 is the right shape for the same reason the rest of this page argues: a log is only as good as its boundary, and a single merged record would be a place where one business’s work became visible from inside the other.
The short version
There are two records and they answer different questions. Your provider knows who reached the account. Your assistant is the only thing that knows why it did what it did, 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 lets you go down to the underlying entry when a sentence is not enough. Read it against the settings you have raised, read it for the actions you would have taken differently, and treat two of the same disagreement as an instruction to lower a setting rather than to watch harder. Everything is on the record; what can be put back is a smaller set than that, which is why the rows you cannot reverse are the ones to read first. Point is the product the record is kept by.