A contact's request history — Help

Most of the time you work with requests from inside an event: you open the run of show, you see who has uploaded their insurance and who hasn't, you approve or chase. But there's a second question that doesn't fit the per-event view. When a supplier you use across a dozen events a year sends you something, you sometimes want the opposite cut: not "who on this event still owes me a certificate", but "what has this particular supplier ever sent me, and is any of it out of date". That's what the Requests tab on a contact answers.

This article covers the Requests tab on the contact record: how it groups a contact's whole request history by event, what each row shows (the files they uploaded, the answers they gave, the scope and the status), and how to walk back through a long history.

Where to find it

Open any contact from the Contacts list (or from a crew row on an event). The contact form has a row of tabs across the top: Events, Emails, and Requests, among others. The Events tab lists every event the contact is on. The Emails tab lists every email 1pm has sent them. The Requests tab is the one this article is about: every request you've ever sent that contact, across every event, with what came back.

The tab is read-only. It's a record of what happened, not a place to send new requests or review uploads. Sending a request and approving or rejecting an upload still happen inside the event, in the request panel, which the Open-event button (below) takes you to.

Grouped by event

The tab reads as a stack of events rather than a flat list. Each event the contact has requests on gets its own heading, and all of that event's requests sit underneath it. The headings run newest event first, so the most recent work is at the top.

Each heading shows:

The event name, large and bold, so the section reads like a printed run sheet heading.
The date, beneath the name.
A recency note for past events: "1 day ago", "12 days ago", so you can see at a glance how long it's been without doing the arithmetic.
An Open event button, on the right of the heading. It takes you straight to that event's run of show, which is where you go to send a new request, approve an upload, or chase a missing one. The button sits once per event rather than on every row, because that's the natural place to act.

Past events are not dimmed or faded. This is deliberate. A public-liability certificate, an ID, or a signed waiver uploaded months ago is usually still the current document, so an old event's requests stay as readable as an upcoming one's.

What each request row shows

Under each event heading, one row per request. Every row carries four things.

The request, and the files attached to it. The request label, and beneath it the files the contact uploaded. Each file is a chip you can open in a new tab. An uploaded image shows as a thumbnail so you can recognise it without opening it; other files show a document icon. Each chip also carries:

The upload date.
An expiry date, if the request asked for one. Once an expiry has passed, the date turns red and reads "Expired", so a lapsed insurance certificate stands out in the history rather than hiding as a green tick.
An Approved or Rejected badge, if you've reviewed the file. (You do the reviewing inside the event; the badge here reflects that decision.)

The answer they gave. For requests that ask for text or a choice rather than a file (a shirt size, a dietary note, an arrival time, a yes/no), the actual value the contact submitted shows in its own column. File-type requests answer with the uploads above, so this stays blank for them.

The scope. A small badge says whether the request was a Crew one (asked of this contact specifically) or Event-wide (asked of everyone on the event). It's useful context when you're working out why a contact does or doesn't have something: an event-wide ask they never saw reads differently from one sent straight to them.

The status. A status badge for where the request stands overall, using the same language as the request panels inside the event: nothing submitted yet, submitted and awaiting review, approved, or rejected.

Walking back through a long history

A supplier you book often can build up dozens of requests across a year. The tab doesn't load all of them at once. It shows the most recent batch first, then gives you a Load more button at the bottom to pull in the next batch, and so on back through the history.

This keeps a heavily-used contact fast to open. The grouping survives the page boundary too, so an event whose requests span two batches doesn't repeat its heading when you load the next one. You get one clean heading per event no matter how the history is paged.

How it differs from the per-event view and the Requests overview

Three surfaces touch requests, and they answer different questions:

The request panel inside an event is where you do things: send a request, see who has and hasn't responded, approve or reject an upload. It's scoped to one event.
The 1pm.app/Requests overview is the cross-event view of outstanding work: what's still pending or rejected across your whole account, so you can chase in a batch. It's scoped to a status, across events.
The Requests tab on a contact is the per-person record: everything one contact has ever been asked and everything they sent back, across all their events. It's scoped to one person, across events.

When you want to vet a supplier before booking them again, or check whether their public-liability cover is still in date, or remind yourself what they answered last time, the contact's Requests tab is the one screen that holds it all.