The Requests page

Requests is the one screen in 1pm that looks across every event and portal at once. It answers "what needs me right now" in four numbers: who has not finished, what is sitting waiting on your approval, what is about to expire, and what you have sent back.

Two things share the name, so worth separating them before anything else. This article is about the account-wide page at 1pm.app/Requests, reached from Requests in the sidebar. The scoreboard that lives on a single event's planner page is a different screen with a different job, and it is covered in The Requests dashboard.

This article covers the four tiles, each section down the page, what the colors mean, and where to go when this page is not enough.

The four tiles

Four counts run across the top, and clicking any of them scrolls you to the section it belongs to. They sit above the sections deliberately, so you land on "here is what needs me" rather than reading four cards to discover that three of them are empty.

Waiting on is people who still owe you something. It is the only number here that cannot be worked out when the page loads, so it arrives a moment after everything else, along with the Waiting on section below. It reflects whatever is selected in that section: one event or portal, or all of them. When nobody holds a link yet, it settles at a plain zero and reads "no links out yet".

Needs review is uploads with no decision on them.

Expiring soon is documents running out inside the window you have chosen, and its caption switches to "N already expired" the moment something has actually lapsed.

Rejected is files you have sent back that are still waiting on a replacement, or whose replacement is waiting for your review.

Every count is the true total from the database, not the length of the list underneath it. The lists are capped, so counting rows would under-report the moment you had more than a screenful.

Waiting on: who still owes you something

The first section is the only one on the page about work that has not arrived yet. Everything below it is triage of things already in the door, which is why this one leads: a chase you never think to make is the one that costs you.

It is scoped by the dropdown on the right, which has an orange border because everything in the section answers for what it shows. It remembers which event or portal you picked between visits. By default it opens on one event or portal, the one with the longest wait. Working out who is outstanding runs through the same engine that decides what each person sees on their own link, which is several queries per event, so a single event loads quickly.

The first option, All portals (or "All events and portals" when you have both), lists everyone across all of them in one list, longest wait first, with the portal named under each person. It covers the 100 events or portals that have waited longest and says how many more it left out; the report linked under the heading covers everyone. It takes longer to load than a single portal, so it is not remembered: the next visit opens on one event or portal again. It shows the By person view only, because each portal asks for its own items, and it has no "Remind everyone" button, so a reminder never goes out across every portal from one press. Pick a single portal for those.

The picker spans both kinds, your events and your onboarding portals, and is labelled for both. When you have a mix they are grouped under two headings, with events first. An event drops out of it 30 days after its date; a portal stays until you close it. The picker lists the 100 that have waited longest, and past that a Find by name box appears beside it to reach the rest. The section does not render at all until at least one of them has links out.

The heading matches its tile on purpose. Every count across the top scrolls to a section and shares its wording and its icon, so you can tell at a glance which number took you where.

Across the top sits a completion ring, captioned "N of M complete", and a bar broken into four:

Complete. Every required item is in and none is waiting for your review. Somebody who was never asked for anything required counts as complete, because there is nothing to chase them for.
Waiting for your review. Everything required is in, but a required upload has not been approved or rejected yet. These people do not count as still owing and get no reminders: the next move is yours.
In progress. They have sent something, and something required is still missing. A required document you rejected counts as missing, and so does a request with fewer files than it asks for, exactly as their own page shows it.
Not started. Nothing at all has come in from them.

Three things about how that is counted. It runs over the people who hold a link to that portal, not everyone in your contacts, so the bar is not diluted by people who were never asked. "Complete" is measured against required items only, so an optional question left blank does not hold somebody in progress. And the ring never rounds a partial result up to 100, so a full ring always means genuinely everybody.

The chips under the bar filter the list below. Still owing is the default and means anyone who still has something required to send. Complete, Waiting for your review, In progress and Not started each cut to one bucket, and Everyone drops the filter. Once anyone has a request past its due date, an Overdue chip appears too, showing just those people. See Due dates on requests.

By person, or by item

Two tabs give you the same portal cut two ways, both off a single pass, so switching between them is instant.

By person is the chase list. One row per person, what they still owe ("2 of 5 required items outstanding"), how long they have been waiting, how many of their requests are overdue (on a portal, their due date, red once it has passed), and whether they have opened their link at all. Overdue people come first, then the soonest due date. That last badge is the one that changes what you do next: somebody who has never opened it needs the link resending or the address checking, and somebody who opened it a fortnight ago and stalled needs a nudge. Those are different jobs.

The nudge is on the row. Click Email a reminder on a person who has not finished, without opening the row, and confirm: it emails them your Outstanding requests reminder straight away and then says when the next automatic reminder goes. The wording is the Outstanding requests reminder on the Automations page; edit it there and it changes for both the automatic chase and this button. Each person can be reminded this way once in 24 hours, counted from the last time their link was emailed. Inside that window the button is replaced by the time you can send the next one, and it counts towards your email limits like any other send. The automatic reminder counts from the same moment, so a reminder you send by hand puts the next automatic one back. To chase everyone at once, click Remind everyone not finished above the list. It queues the same reminder to everyone on that event or portal who still owes something, leaving out anyone with no email address and anyone emailed in the last 24 hours, and tells you how many it left out and why. Nothing sends straight away: the reminders wait as a batch on the Emails page, where you can cancel them, exactly as a bulk invite does. Anyone who finishes while the batch waits is not reminded. See Batched emails.

Each outstanding person also shows when the automatic chase will next email them, as a small badge such as "Next automatic reminder Tue 7 Oct", or "Reminded 30 Sep" once the last reminder has gone. Hover over it to see which automation sends it. Nothing shows when chasing is switched off or the person has finished. So the reminders run themselves, and you step in with Email a reminder when something is getting urgent.

Click a row and it expands in place to show what that person has actually sent, without sending you off to the event. There is also a link straight to their own portal, which answers the question the list raises next: having read what they sent, what are they actually looking at? Longest waiting leads, and the tab shows the 15 longest with a line telling you how many more there are.

By item turns that on its head and asks what is holding everybody up. One row per request, with a bar showing how many are In, how many show Needs review, how many were Rejected, and how much is Not in yet. Open a row to see everybody it was asked of; a person whose file needs review has a Review button that opens it. Nine crew all missing the same public liability certificate becomes one row saying so, instead of nine rows saying it separately. Optional requests are badged as optional. Ordering is worst first: required before optional, then whatever has the most still to come. Same cap of 15.

Needs review

Uploads with no decision yet, oldest first, with Approve and Reject on each row so you can work a queue without opening an event per file. It shows up to 25, with the true total on the tile above, and the card stays on the page even when it is empty so you can find it and see what it is for before anyone has sent anything. When files are waiting on two or more events or portals, the Show list above the rows narrows the section to one of them, with the number waiting on each. Review then works through that one's files and closes after the last.

The filename opens the actual document in a new tab, which is how you check a certificate's contents against the expiry date somebody typed. If the request asked for an expiry, that date sits on the row too, flagged when it has already passed, which is a reason not to approve as-is.

Beside that date is what the AI expiry date check found when it read the document: AI check: matches the document, AI read with the date it found when that is a different date, AI could not read a date. Check it yourself., or AI check pending while a new upload is still waiting to be read (about 10 minutes). That badge updates when the result is in, without a reload. AI check not run means the file was not sent to AI: the check is switched off for that request, the file is not a PDF or an image, or it is a PDF of more than 10 pages. When the date AI read is different from the date entered, Approve on that row is switched off. Open the file, check which date is right, then either reject it or tick I checked the date to approve it with the date entered. The Review window shows both dates side by side with the same box.

A rejection needs a reason, and it emails the person. Reviewing crew uploads covers what approve and reject actually do and why the reason is compulsory.

Uploads expiring soon

Public liability lapses, food safety certificates run out, working-with-children checks need redoing. Any upload carrying an expiry date feeds this list, across every event and portal, soonest first. Already-expired documents are included rather than hidden, because a lapsed certificate is the most urgent line on the page.

Two filters sit above it and narrow together:

Expiring within. 3, 7, 14, 30, 60, 90, 180 or 365 days. It starts at 30.
Hide if reminded in the last. Drop anyone you emailed a reminder in the last 3, 7, 14, 30, 60, 90, 180 or 365 days, so a second pass through the list is genuinely the people who have not heard from you. Off by default. Same ladder as the window beside it, plus an "All (no filter)" entry at the top.

Both stay as you set them when you click Email a reminder, Stop tracking or Restore on a row, so you can work down a filtered list without setting them again.

Each row carries a badge for how long is left, and the filename and the Open file badge both open the document in a new tab. Nothing else on the row navigates. If you do want the event, Open this request under the filename takes you to that person's requests there, opened, so the document in question is on screen rather than buried under a collapsed row.

Two columns to the right are easy to confuse, so they are kept apart on purpose: Expires is when the document runs out, Last reminder is when you last emailed them about it ("none" when you never have).

The list shows the 25 most urgent, and it does not reach back further than a year, so a certificate that lapsed in 2023 is not here. It also leaves out anything you have rejected, since that is already in the section below, and anything you have stopped tracking.

Emailing a reminder for a fresh copy

Email a reminder emails that person straight away asking for a current copy, with a link that drops them on their own page with no password to remember. Preview reminder email at the top of the page shows you exactly what goes out before you send anything. The person can upload the new copy as soon as they open their page, even though they cannot delete a file you approved: an approved document you have sent a reminder about, or is within 30 days of its expiry date, no longer counts towards the request's file limit. The old file stays on their row and in your records. A file you have not approved yet still counts, and the person deletes it themselves to send another.

The wording is yours. It is the Expiry date prompt email under Automations, editable like every other system email, and it fills in the document name, the expiry date and their private link on each send.

Four things stop a reminder, and each one says so on the row rather than failing quietly. The person has no email address on file, which the row also flags before you click. You already emailed them a reminder today, which is the guard against a double click sending twice. They have no active share link on that event, so the email would land them on a revoked page. Or you have hit the daily ceiling of 300 emails, or run out of monthly allowance; Your monthly email allowance covers both.

A reminder that sends stamps the row's Last reminder, and that stamp is what the "hide if reminded in the last" filter reads. Send today, and that person drops out of tomorrow's list until the window you chose has passed.

Stop tracking, and Previously ignored

Not every expiring document is worth chasing. A certificate that has been superseded, or one where the date was typed wrong, is noise on a list you want to trust.

Stop tracking, beside Email a reminder on each row, retires that one document from expiry tracking. The file stays exactly where it is and stays visible to the person who sent it. It just stops appearing here.

Ignored rows collect in a Previously ignored section at the foot of the page, collapsed, and only there once you have stopped tracking something. It is an audit trail rather than a bin, so a decision you made six months ago is still one click away.

Nothing there is final. Each row keeps the expiry date it had, shown beside the filename, and a Restore button puts the document straight back on the expiring list at that same date. Stop tracking a certificate you meant to chase, or park one and change your mind a month later, and it takes one click to undo. Restoring does not send anything or replay a reminder you missed while it was parked; use Email a reminder for the chase you want to make now.

A handful of documents ignored in earlier versions of 1pm did not keep their date. Those ask you to type one in beside the Restore button, because a document back on the list needs a date to be on it for.

Rejected uploads

Every rejection still waiting on a replacement, or whose replacement is waiting for your review, with your reason shown inline so you do not have to open anything to remember why. The section only appears once there is something in it.

The list is in two groups. Waiting on a replacement comes first: nothing new has come in since you rejected these, so they are the ones to follow up. Replacement received is the rest: the person has sent a new file. Review the replacement on the row opens that file beside Approve and Reject. Once you approve it, the rejection leaves this list and the Rejected tile count. A new file that answers a rejection also carries a Replaces a rejected file badge in the Needs review list, and the review window prints the reason you gave, so you can check the new file against it. Open this request on a row opens that request's responses on the event, where you can clear the rejection.

What the colors mean

The page uses five colors and each one means exactly one thing, which is worth knowing because the same person can appear in more than one section wearing more than one of them.

Green. Done. In, finished, approved.
Pale green. Part way. They have sent something and still owe a required item. It is the same green at half strength on purpose, because part way and finished sit on one continuum.
Blue. Your move. It has arrived and it is sitting in your queue. "Needs review" on the list of uploads and on the By item bars is the same state seen at two different scales, which is why both are blue.
Amber. Their move. Nothing is wrong, somebody just has not done it yet.
Red. Known bad. The document is unusable: you rejected it, or it has lapsed.

Red stopping at "lapsed" is the part that surprises people. A certificate expiring on Friday still works on Friday, however much you want it renewed, so it wears amber and only turns red once the date has actually passed. Keeping red for the genuinely dead ones is what makes them findable in a long list.

The "waiting 12 days" and "submitted 3d ago" chips are deliberately colorless. Age is not a status, and a colored chip sitting beside a status badge only argues with it. Past a fortnight the chip takes weight instead, which still catches the eye on a scan. Nothing is lost by that: both lists are ordered longest-waiting-first, so position already carries the urgency, and the chip prints the actual number.

Every color on the page is paired with a written label, so nothing here depends on being able to tell two colors apart.

When this page is not enough

The Expiring documents report, under Requests in Reports, is the narrower and fuller view at the same time. It filters by event, groups by contact, tag or status, exports to CSV and prints. It also includes documents you filed on a contact yourself, which this page does not: the expiring list here reads crew submissions only.

Use this page for "what needs me right now" across the account. Use the report when you are working a specific event, a specific week, or building a compliance pack for one client. Chasing expiring documents covers both surfaces together and when to reach for each.

The Requests dashboard is the per-event scoreboard, which is a different screen from this one.
Asking crew for documents and info covers building the requests that feed this page.
Reviewing crew uploads covers approve and reject in detail.
Chasing expiring documents covers the expiry stack end to end, including the Expiring documents report.
A contact's request history covers what one person has sent you across every event.
Portals covers onboarding portals, which appear in the picker here alongside your events.
Using 1pm for onboarding and compliance requests covers the whole workflow this page sits inside.