Reviewing crew uploads — Help

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 Requests 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

In the event's Requests panel.

Uploads are reviewed in the Requests panel of the event you asked them on. Open the event, find the request in the Requests panel, and click its responses button (the count next to the request). That opens the responses view, where every crew member's uploaded files are listed, each with the submitter's name and a little metadata (file name, uploaded date, file size). Whether the request went to everyone on the event or was targeted at a subset of crew through a named-crew conditional section, you review the files in the same place, grouped under the request.

On the crew member's row (read-only).

Each crew member's row also carries a Requests summary, a read-only at-a-glance of what's been asked of that person and whether each file is pending, approved, or rejected. It's there to answer "has Sarah sent her certificate yet?" without opening the request. You don't act on files from here, though: the Approve, Reject, and Delete controls live in the request's responses view (and on the Requests page below).

The Requests overview.

The 1pm.app/Requests page is the cross-event view across your whole account, and it's where bulk review actually happens. Its Awaiting approval section lists every upload sitting unreviewed on every event you run, with Approve and Reject on each one, so you can work through two hundred submissions without opening two hundred events. It also has a section for rejected uploads, so the outstanding re-uploads are a list rather than something you have to remember.

Approve on that page is one-way: it approves, and it clears any earlier rejection on the file, but it doesn't toggle back off the way the planner-side button does. Un-approving is a planner-side action.

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 show a "Rejected" badge and the reason in a callout, with a fresh upload control just below so they can send a corrected file.

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 1pm.app/Requests in the top navigation. Four counters run across the top: Awaiting approval, Expiring soon, Rejected, and who you're still waiting on. Awaiting approval is the one that's genuinely yours, since the others are waiting on somebody else.

Below them, the Rejected section is your punch list of files sent back, each with the reason you gave. 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 detail, or open 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 venues 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. Each file carries the timestamp of its current decision (an approved-at or a rejected-at, with the rejection reason). It's the current state rather than a running log: a later decision overwrites the earlier timestamp, it doesn't stack up a history. That's enough for a light paper trail; for anything deeper, the account export captures the request, response, and rejection-reason metadata.

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.