Tracking one document across every event — Help

A supplier sends you their public liability certificate. Then their cover renews and they send a fresh one. Then you book them again the following year and they send another. Three years later something goes wrong at an event and you need to prove what cover they had on the night, which means finding the certificate that was current at the time, not the one sitting on their record today.

1pm keeps every one of those files. What it needed was a way to recognise that all three are the same thing. That is what a document type does: it is the label that says "these all answer the same question", so a certificate collected on a 2023 event and one collected on a 2026 event line up as one history instead of two unrelated uploads. This article covers setting a document type up, connecting your existing requests to it, and reading the history that results.

The problem document types solve

A contact's Requests tab groups everything by event, which is the right shape for "what did we ask this supplier for on the gala". It is the wrong shape for "show me their insurance over time". The same certificate asked for on five events sits under five separate headers, and nothing on screen says they belong together.

They are not connected in the data either, and that is the part worth understanding. Each event carries its own request, worded however you happened to word it that year. One event asks for a "Certificate of insurance", another for "Please upload a copy of your public liability insurance", a third just says "COI". To a person those are obviously the same ask. To software they are three unrelated rows with nothing in common but a vague family resemblance, and matching them on wording alone would be a good way to file a supplier's ID under their insurance.

A document type is the missing piece. You define it once, point each request at it, and from then on every file collected against any of those requests belongs to that one type.

Setting up a document type

Document types are Upload custom contact fields, so they live with the rest of your fields. Open Fields from the sidebar, add a field, and choose the Upload type. Name it for the document rather than for any one request: "Public liability certificate" rather than "Certificate for the spring gala".

Tick "Require an expiry date" while you are there if the document expires, which insurance and most licences do. That forces whoever attaches the file to say when it runs out, and it is what turns a filed document into one you can actually track. See custom contact fields for the full set of field types and what else they can do.

Connecting requests to it

A document type is only worth having once your requests point at it. There are four ways to make that happen, and which one you want depends on whether you are setting up something new or connecting years of existing events.

When you create the request. Add an upload request to an event and pick the document type from the Document type list on the request. New requests are best handled here, because it is one choice at the moment you are already thinking about the ask.

On a request that already exists. Open the request in the event's Requests panel and set its Document type. This works on requests that have already collected files, and it is the fix for everything you set up before you had document types. The files come with it: they were always stored, they just had nothing to belong to.

The same request on other events. Once a request is linked, a Link elsewhere button appears next to it. It looks for requests on your other events with exactly the same wording and offers them in a list, with the event each one is on and how many files it holds. This is the quick win when you have duplicated an event several times and the wording came along for the ride.

Everything at once, from the document type. The most useful one for a real backlog. Open Fields, find the document type, and click Link requests. That lists every upload request across your whole account that is not yet connected to a type, whatever each one is called, with its event and file count. Tick the ones that belong and link them in a single pass. Because you have already chosen the document type and you can see what each request collected, wording does not have to match at all, which is exactly what makes this the one that copes with five years of differently-worded events.

Anything you link can be unlinked, from the same screen or from the request itself. Linking does not move, copy, or alter a single file. It only records what the ask was for, which is why it is safe to try.

Reading the history

Once requests are connected, a History button appears anywhere a contact's field is shown: on the document type itself in the contact's Details tab, and on any request row in the contact's Requests tab that is linked to a type.

The history lists everything that contact has ever sent for that document type, newest first, across every event. Each entry shows the file, when it was uploaded, its expiry date, and whether you approved or rejected it. Underneath, the event it arrived through and what the ask was called at the time, which matters more than it sounds: when the wording has changed over five years, "asked as COI" is often the detail that tells you which certificate you are looking at.

Answers work the same way. A document type holds files, but the same history is available on your text, choice, date, number, and time fields, and there it shows what the contact answered on each event. If a supplier gave you one licence number in 2024 and a different one in 2026, both are there, along with the value currently sitting on their record.

Which file counts as current

The contact record shows one file per document type: the current one. Current means the most recent file you have not rejected.

That distinction matters when a supplier sends something wrong. If you reject their latest upload, the previously approved certificate goes back to being what they have on file, which is the honest answer, because a rejected document is one you have said does not count. The rejected file has not gone anywhere; it is in the history with its rejection showing. If you find yourself wondering why the contact is showing an older certificate than you expected, the history is where the newer, rejected one will be.

Expiry is shown but does not change which file is current. An expired certificate stays on the record, marked as expired, rather than quietly disappearing and leaving the contact looking like they never sent anything.

One thing to know about files you attach yourself

You can attach a document to a contact yourself instead of waiting for them to submit it, which is the usual path when a supplier emails you the certificate rather than using their link.

Files you attach this way keep only the most recent one. Replacing a document you attached overwrites it. Files that arrive through a request are all kept, so the reliable way to build up a history is to collect documents through requests wherever you can, and to treat direct attachment as the exception for when someone will not use their link. The history screen says this on the entry itself, so you are never left guessing whether something went missing.

Custom contact fields covers defining fields, the types available, and letting crew fill them in for you.
A contact's request history covers the per-event view of everything one contact has been asked.
Asking crew for documents and info covers building a request in full.