← All help articles

Tracking changes to a request and its answers

Tracking changes to a request and its answers

Two questions come up about requests more than any others, and until recently 1pm could not answer either of them.

The first is "who changed this?". A request that asked for a certificate number is now asking for an upload, the deadline moved, and nobody on the team remembers doing it. The second is worse: "this answer used to say something else". A crew member's insurance number is different from the one you wrote down last month, and the record shows only the number that is there now, as though it had always said that.

There are now two trails, one for each question. They are deliberately separate, because they answer different things: Admin history covers the request, and the trail under an answer covers what crew submitted against it.

The one distinction to hold on to

  • The request is what you asked: the label, the wording, whether it is required, the deadline, the document you attached. Changing it changes the ask for everyone.
  • The answers are what came back: one per crew member, submitted from their own link.

Admin history is the history of the ask. It never covers the answers, which is exactly why the button says "Admin" rather than just "History". The answers have their own trail, and it lives where the answers do, behind View.

Admin history: what changed about the ask

Open the event, go to the Requests panel, and expand the request you are asking about. At the foot of the expanded row, under everything that edits it, is an Admin history button.

It opens a list of every change, newest first. Each entry gives you three things: who made the change, when they made it, and what actually changed, written as the old value struck through and the new one beside it.

Most fields on a request are covered: the label and description, the choices on a multiple-choice ask, the answer format on a text ask (such as Phone number or Email), the booking field an answer fills in, the reference document you attached (including a replacement file with the same name, shown as "(new file)"), minimum and maximum counts, and the switches for required, expiry date, long answer, multiple choices, archived, the signature and typed-name requirements on a terms request, and whether the request is limited to named crew. Linking to a contact field or a terms template shows up too, by name rather than by id.

The oldest entry reads Created as, with the label the request started life under, so you can see the whole arc from first draft to what it says today.

A few things it deliberately does not do:

  • Reordering is not listed. Dragging one request up the list rewrites the position of every row it passes. Recording those would bury the changes that matter under a wall of position churn.
  • It does not name the crew a conditional section is limited to. That a request became limited to named crew is recorded; which names are on the list is held elsewhere and is not part of the trail.
  • It does not carry procedure text pulled in from a task template, for the same reason: that text lives with the template, not on the request.

Names, and when there isn't one

Where 1pm knows who made a change, it says so, and it names the person, not the account. If a collaborator on your account edits a request, the trail says their name, not the account owner's.

Some entries read No name recorded instead. That happens for three honest reasons: the change was made before 1pm started recording the actor, nobody was signed in when it happened, or the person who made it has since been removed from the account. Guessing at a name in any of those cases would be worse than saying nothing, so it says nothing.

How far back it goes

Request history is kept for six months. If a request is older than that and its early changes have aged out, the modal says Older changes are not shown, rather than passing the earliest surviving entry off as the beginning.

A very heavily edited request shows the most recent 200 changes, and says that is what you are looking at. That line and the retention line are different messages on purpose: one is a display cap and everything is still there, the other is a retention cut and it is gone for good.

A request nobody has touched since it was created shows No changes recorded yet, which is the honest answer rather than an empty box.

What an answer used to say

The other trail sits with the answers. On a request row, press View to open the responses, and under any answer that has been changed you will find a small Changed once or Changed 3 times line. Open it and you get each previous value, struck through, with what happened to it and when:

  • Replaced means the crew member submitted a new answer over the top of their old one.
  • Removed by the crew member means they took their answer away themselves.
  • Removed by a name means somebody on your account deleted it.

Each line also carries the date the old value was originally submitted, in brackets, so you can tell "this was wrong all along" from "this was right until Tuesday".

Answers submitted once and never touched show nothing at all. The line only appears where there is genuinely something behind it.

Which document an answer was given against

When a request has a document attached, each answer also records which one: "Answered against induction.pdf, uploaded 3 Aug 2026". Previous values in the trail keep the document they were given against too.

If the document has changed since someone answered, their answer carries an Answered before the document was replaced badge. It records when they answered relative to the file, not what the earlier file said: the old file itself is not kept. When the exact wording someone agreed to matters, use a terms request, which keeps every version.

Answers that were removed entirely

An answer that has been deleted has no current value to sit under, which would make it the one trail you can never find, and it is the one people look for hardest. So removed answers get their own Removed answers section at the bottom of the same View panel, grouped by person and already open, since there is nothing above them to expand.

A few things worth knowing

  • Nothing watches people type. The crew card saves on submit, so every value in the trail is one a crew member deliberately sent you. There are no drafts or keystrokes in there.
  • Answer history is kept for 180 days, which is the same window as the six months on the request itself, arrived at from the other direction: the request's is a retention setting on the table, and the answers' is a nightly sweep on the same 180-day cutoff that prunes timeline history. Either way, six months is the answer to "how far back can you go" for both trails.
  • Deleting a crew member takes their answer history with them. If someone asks to be erased, erasing them clears the trail too.
  • Both trails are in your account data export, so a request for the full record does not depend on screenshots of a modal.

Which history am I looking at?

1pm has three views with "history" in them, and they cut the data three different ways:

  • Admin history, on the request row, is one request on one event: how the ask itself has changed.
  • The trail under an answer, behind View, is one person's answer to one request: what it used to say.
  • A contact's request history is one person across every event: everything you have ever asked them and what came back, including the per-document History button for a certificate you collect year after year.

If the question is "what did we ask?", it is the first. If it is "why is this number different?", it is the second. If it is "what has this supplier ever sent us?", it is the third.

Still stuck after reading this? Open a help ticket and we'll answer your specific question.