The Requests page
image: in docs/help/_metadata.yaml 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 colours 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 Onboarding section below. It reflects only the portal selected in that section, not your whole account. When nobody holds a link yet, it settles at a plain zero and reads "no links out yet".
Awaiting approval 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.
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.
Onboarding: 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 to one portal at a time, picked from the dropdown on the right, and it remembers your choice between visits. That is a deliberate trade rather than a shortcut. Working out who is outstanding has to run through the same engine that decides what each person sees on their own link, which is several queries per event. Asking that question for the event you are actually working is cheap. Asking it for every event on the account, on every page load, would not be.
The picker is labelled Portals because it spans both kinds: your events, and your onboarding portals. When you have a mix, they are grouped under two headings, with events first. The section does not render at all until at least one of them has links out.
Across the top sits a completion ring and a bar broken into three:
- Finished. Nothing required is outstanding. Somebody who was never asked for anything required counts as finished, because there is nothing to chase them for.
- In progress. They have sent something, and something required is still missing.
- 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. "Finished" 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 not finished. Finished, In progress and Not started each cut to one bucket, and Everyone drops the filter.
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, and whether they have opened their link at all. 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 and they used to look identical.
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 Need your review, how many were Rejected, and how much is Not in yet. 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.
Awaiting your approval
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 50, 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.
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.
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 prompted within. Drop anyone you nudged 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.
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, Prompted is when you last nudged them about it.
The list shows the 100 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 ignored.
Prompting for a fresh copy
Prompt 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. View prompt email at the top of the page shows you exactly what goes out before you send anything.
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 prompt, 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 prompted them 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 cap of 200 emails, or run out of monthly allowance; Your monthly email allowance covers both.
A successful prompt stamps the row, and that stamp is what the "hide if prompted within" filter reads. Send today, and that person drops out of tomorrow's list until the window you chose has passed.
Ignore, 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.
Ignore, beside Prompt 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 ignored 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. Ignore 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 Prompt 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 file you have explicitly rejected, most recent first, 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.
A rejected row usually means one of two things. Either they have re-submitted, in which case there is a fresh upload waiting in the approval queue above, or they have not, and it is worth a follow-up. Open this request on the row opens that request's responses on the event, where you can approve the new file or clear the rejection.
What the colours mean
The page uses five colours 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. "Awaiting your approval" and "Needs your review" are the same state seen at two different scales, which is why they share a colour.
- 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 colourless. Age is not a status, and a coloured 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 colour on the page is paired with a written label, so nothing here depends on being able to tell two colours apart.
When this page is not enough
The Uploads report, under Operations 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.
Related articles
- 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 Uploads 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.