Reviewing crew uploads
When you've asked crew to upload a document — an insurance certificate, a signed waiver, a copy of their public liability cover, a photo of their ID — the files arrive in the request panel of the relevant event. From there you decide whether each file is good, needs to be redone, or you simply want to leave it alone. This article covers the review flow: where the uploaded files appear, the Approve and Reject buttons, what happens when you reject a file (including the email that goes back to the crew member), and how to find every outstanding upload across all your events from a single place.
Where uploads appear
Per-crew requests.
If you sent a request to a specific crew member — for example, "Sarah the photographer, upload your public liability certificate" — the file shows up in the crew member's row inside that event's planner. Open the event, open the request panel under that crew member, and you'll see one entry per file they uploaded with a small preview and metadata (file name, uploaded date, file size).
Event-wide requests.
If you sent a request to everyone on the event ("All crew, upload your insurance"), every crew member's submission is grouped under the request itself on the event's Requests accordion. You'll see one block per crew member who has uploaded, each with their files inside.
Both surfaces show the same review controls. The difference is just how they're grouped.
The Requests overview
The live.1pm.app/Requests page is the cross-event view of every pending request across your whole account. It has a section for rejected uploads so you can find them in one place — useful when you want to chase the re-uploads in a batch without hopping between events.
The two review actions:
For each uploaded file you have two buttons: Approve and Reject. They're independent — you can do either, switch between them, or do nothing. Doing nothing is a perfectly valid state ("unreviewed"); 1pm doesn't punish a file for sitting unreviewed.
Approve.
Click Approve to mark a file as accepted. The button flips to show the file is approved, with a small green tick and a timestamp. No email is sent to the crew member; the approval is mostly a note to your future self that you've looked at this file and you're happy with it. Crew see "Approved" on their side of the file when they look at the request again, which gives them quiet reassurance that the document landed.
You can unapprove a file by clicking Approve again — the toggle clears and the file is back to unreviewed. There's no penalty for changing your mind. No email is sent for the un-approval either.
Reject.
Click Reject to send the file back for a redo. This opens a small modal asking for a reason. The reason is required — you can't reject without one. The modal has a textarea (up to 2000 characters), an option to suppress the email (more on that below), and Reject and Cancel buttons.
Type a clear, specific reason. "Out of date" is better than "no good"; "The certificate has expired — needs to be a 2026 one" is better still. The reason gets shown to the crew member, both in the email they receive and on their own view of the request. A vague reason wastes everyone's time on the back-and-forth.
When you click Reject:
The file is marked rejected with the timestamp and the reason. Both Approve and Reject stay visible on the file (you can flip the decision later).
If you didn't suppress the email and the crew member has an email on file, 1pm sends a single notification email to that crew member. The email contains the request name, the file name, your reason, and a link straight to their personalised run-of-show page where they can re-upload.
The file stays in the planner — rejecting doesn't delete it. The previous file remains attached to the request with the rejected flag set. When the crew member uploads a replacement, both will be visible until you delete one.
Editing or clearing a rejection
If you rejected a file and want to change the reason (a typo, a clarification, more context), click Reject again on the same file. The modal opens pre-filled with the existing reason and shows an extra Clear rejection button.
Edit the reason and click Reject to update it. Sending another email is optional via the same checkbox.
Click Clear rejection to undo the rejection entirely. The file goes back to unreviewed. No email goes to the crew — if you cleared a rejection before the original email had a chance to go (suppressed at the time, or you cleared very quickly), the crew member never knew. If they did see the rejection (email went out, or they refreshed their page in between), the cleanest fix is to re-approve the file explicitly so they see Approved on their side.
If a crew member uploaded a replacement file after you rejected the first one, the replacement is a separate row with its own Approve / Reject controls. You usually leave the rejected original alone and review the new one fresh.
The "do not email" option
By default rejection sends an email. The modal includes a Do not email checkbox you can tick when:
You're going to follow up by phone or in person and the email would be noise.
You're rejecting in bulk to organise your end and the crew member knows what's coming.
You've already discussed the issue with them and you're now just recording the decision in 1pm.
You always want the rejection on file even if you don't email — the in-app state (rejected, reason visible on crew's view) is the durable record. The email is the courtesy nudge that prompts a re-upload.
When the email can't be sent.
A few situations override the option:
If the crew member has no email address on file, the email checkbox doesn't appear in the modal at all. A line of text says "no email on file" and explains that the crew member will see the rejection on their run-of-show page when they next open it. The rejection itself still applies.
If your own account email is not verified, 1pm can't reliably send outbound notifications as you, so it disables the email option and shows a banner with a Verify my email link. Verify the address (see the Verifying your email address article) and the option becomes available next time. The rejection still applies in the meantime; the crew member just doesn't get the email.
What the crew member sees
On their side, an uploaded file shows up as approved, rejected (with the reason), or pending (unreviewed). Rejected files have a clear "Please re-upload" prompt with the reason, and a fresh upload control just below.
The crew member's view doesn't expose any other rejection metadata — no count of past rejections, no history of what they've uploaded for the same request previously. They see the current state and what to do about it.
If you've rejected the same upload multiple times (with different reasons across edits), they only see the most recent reason. The earlier ones aren't kept.
Finding every rejected upload across your account
Open Requests in the top navigation. The page lists every active request across all your events, grouped by event. There's a section that surfaces rejected uploads in particular — useful as a punch list.
Use this view when you want to chase a batch of re-uploads in one sitting rather than walking each event in turn. From here you can click into the specific request to see the rejection details, or click the link to that crew member's run of show to remind them in context.
When to approve vs leave unreviewed
You don't have to approve everything. Three reasonable approaches:
Approve only what passed a check. Approve becomes a "yes, I've actually looked at this" signal to your future self.
Approve everything that arrived. If the document type doesn't really need approval (a meal preference response that's just confirmation, not something to verify), approving sweeps them off your to-do list visually.
Don't approve, only reject. Some planners just live with the unreviewed state for fine files and only act when something needs fixing. This is the least work and works fine if your event cadence is light.
There's no system penalty for any of the three. Approve is a tool, not a requirement.
Deleting a rejected file
If a crew member uploaded the wrong file (different request, wrong account, accidentally uploaded their selfie) and you want to remove it entirely rather than reject and have them re-upload, there's a small Delete control on the file. Deleting wipes the file from blob storage and removes the database row. Use this sparingly — if a crew member uploaded a legitimate document that just isn't right yet, reject (with reason) so they know what to do; deleting can leave them confused about whether the file ever arrived.
A small note on auditability
Approve and Reject decisions are timestamped against your account. If a question ever comes up about who said what when ("did anyone ever approve the insurance certificate before the venue check?"), the events list in the planner retains that history per file. The current state is what matters operationally; the timestamps support a paper trail if you ever need one.
For a long-term archive, the account export (see Exporting your account data) includes the metadata of every request, response, and upload — including the rejection reasons. Crew-uploaded files themselves aren't in the standard export by default; see that article for how to retrieve them.
