Chasing expiring documents
Public liability certificates expire. So do food safety certificates, RSA cards, licences, working-with-children checks and insurance schedules. Collecting them once is the easy part. The hard part is knowing, in March, which of your forty suppliers has a certificate lapsing in April, and chasing them before it does rather than on the loading dock the morning of an event.
1pm records an expiry date against a document when it is collected, then gives you two ways to work the list and an email to send when you do.
This article covers capturing the date, the two chase surfaces and when to use each, the reminder email, and one gap worth knowing about.
Capturing the expiry date
An expiry is only useful if it is always there, so ask for it at the point of collection.
On a request. When you build an Upload request, turn on the option to require an expiry date. The crew member cannot submit the document without one, which means you are never left with a certificate and no idea when it runs out. Asking crew for documents and info covers building requests.
On an Upload contact field. The same flag exists on the field itself, under Contacts, then Fields. Tick Require an expiry date when you create the field, or toggle it afterwards; flagged fields carry an Expiry required badge in the list. This one governs what you have to enter when you attach a document on someone's behalf, which happens more than you would think: people email a certificate through instead of using their link, and you file it for them.
The two flags are siblings rather than one setting. Turning it on for a contact field does not turn it on for a request that maps to the same field, so if you collect a document both ways, set both.
The two chase surfaces
There are two, and they answer different questions.
The Requests page is the account-wide view: everything expiring across every event and portal you have, in one list. It starts at a 30-day window and it is the "what needs me right now" screen you open on a Monday. It carries two filters of its own, which narrow the list together: Expiring within (30, 60, 90, 180 or 365 days) and Hide if prompted within (14, 30, 90, 180 or 365 days, off by default). Documents that have already expired are included rather than hidden, and the list leaves out anything you have rejected or ignored.
The Uploads report, under Operations in Reports, is the narrowed one. It answers "what expires on these events within N days, excluding anyone I have already chased". Use it when you are working a specific portal, a specific week, or preparing a compliance pack for one client.
The report gives you more control:
- Events and portals. Pick one, several, or leave it empty for all.
- Expiring within. 7, 14, 30, 60, 90, 180 or 365 days. The short end is the useful bit and is finer than the Requests page, because a certificate lapsing inside a fortnight is a different problem from one lapsing in six months.
- Hide if prompted within. Drop anyone you have already nudged in the last 3 to 365 days, so a second pass through the list is genuinely the people who have not heard from you.
- Group by contact, tag or status.
Two things about how it is ordered. Grouped by contact, the most urgent document floats each contact to the top, so the top of the page is the work to do first rather than everyone called Adams. And documents that have already expired are included and shown in bold as overdue rather than hidden, because a lapsed certificate is the most urgent line on the page. The report prints in full black, so that urgency reads on paper too.
Like every report, it exports to CSV and has a print layout.
The reminder email
Both surfaces let you send the prompt rather than writing it yourself. On the Requests page, View prompt email shows exactly what the person will receive before you send it.
The wording is yours. It is the Expiry date prompt email under Automations, editable like every other system email, and it merges in the document name, the expiry date and the person's own private link so they can replace the file without an account or a password.
Sending a prompt is also what the "hide if prompted within" filter reads, so the two work together: send today, and that person drops out of tomorrow's list until the window you chose has passed.
Four things stop a prompt, and each one says so on the row rather than failing quietly. The crew member has no email address on file. 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.
Retiring one document
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 crew member; it just stops appearing on the expiring list. Ignored rows collect in a Previously ignored section at the foot of the Requests page, collapsed and only shown once there is something in it, so a decision you made six months ago is still one click away.
This is the per-document off switch. Archiving a contact field, further down, is the per-field one.
Documents you filed yourself
Not every certificate arrives through a share link. Plenty get emailed over, and you file them on the contact yourself. Those count too: the Uploads report lists planner-attached files alongside crew submissions, so a document is chased whichever way it reached you.
They behave slightly differently, because a file on a contact has no booking behind it:
- The event column reads "On the contact" rather than naming an event, because there isn't one.
- Narrowing to particular events keeps them for contacts who are crew on one of those events, listed once however many they are on. So a portal-specific chase list still includes that contractor's licence, and leaves out everyone who is not on it.
- They have no status, since a crew status belongs to a person on an event. Grouped by status, they collect under "(No status set)".
- "Hide if prompted within" never hides them. There is no request behind them to prompt against, so they have genuinely never been chased through 1pm and stay on the list until the file is replaced or the expiry passes.
Files on a field you have since archived drop off the report. Retiring a field is how you stop chasing its documents.
The account-wide expiring list on the Requests page still reads crew submissions only, so the report is the fuller view of the two.
One narrower exclusion: documents collected under the retired per-crew requests system are left out. Both surfaces now read the consolidated requests table alone, so those old rows appear on neither.
Related articles
- Asking crew for documents and info covers building the request that captures the date.
- Custom contact fields covers Upload fields and the require-expiry flag.
- The requests dashboard covers the per-event scoreboard, which is a different screen from the account-wide Requests page described here.
- Reviewing crew uploads covers approving or rejecting what comes in.
- Reports covers the rest of the suite, including where Uploads sits.
- Using 1pm for onboarding and compliance requests covers the whole workflow this fits into.