Tracking a document across portals

A contractor sends their public liability certificate when you onboard them. A year later their cover renews, they go through a new portal, and they send another. Do that three or four times and you have a pile of files with nothing saying they are the same document.

A document type fixes that. It is the label that says "these all answer the same question", so every certificate that person has ever sent lines up as one history, whichever portal collected it.

Why the contact's Requests tab is not enough

Open a contact and the Requests tab lists everything they have been asked, grouped by portal. That is the right shape for "what did this person send on the spring intake". It is the wrong shape for "show me their insurance over time", because the same certificate sits under a separate heading for every portal.

They are genuinely unconnected underneath. Each portal carries its own request, worded however you worded it that year: "Certificate of insurance" on one, "Please upload a copy of your public liability insurance" on the next. To you those are the same ask. WorkZerk does not guess from the wording, because a wrong guess would file somebody's ID under their insurance.

Setting up a document type

Document types are Upload fields, so they live with the rest of your custom fields. Open Fields under Contacts, use Add field, and pick the Upload type.

Name it for the document, not for the portal that collects it. "Public liability certificate" stays true for years.

Tick Require an expiry date if the document expires, which insurance and most licenses do. That makes you enter an expiry date when you attach a file to a contact yourself. Files that arrive through a request get their date from the request instead: tick Require expiry when you create it, or on the request row afterwards. The expiry date is what makes a certificate trackable rather than merely filed.

Connecting requests to it

A document type does nothing until requests point at it. There are four ways, and which you reach for depends on whether you are setting something up or connecting portals you already ran.

• When you create the request. Add an upload request to a portal and pick it under Document type. If the type does not exist yet, choose New document type at the bottom of the list and name it: it is created along with the request.
• On a request that already exists. Expand the request in the portal's Requests panel and set its Document type. This works on requests that already collected files, and it is the fix for everything you built before you had document types. The files come with it.
• The same request on other portals. Once a request is linked, a Link elsewhere button appears beside it. It finds requests on your other portals worded exactly the same way and offers them in a list, with the portal each is on and how many files it holds. Useful when you duplicated a portal and the wording came along.
• Everything at once, from the field. The one that copes with a real backlog. Open Fields, find the document type, and use Link requests. That lists every upload request across your whole account that is not linked yet, whatever each is called, with its portal and file count. Tick what belongs and link it in one pass. You have already chosen the document type and you can see what each request collected, so the wording does not have to match at all.

Anything linked can be unlinked, from the same screen or from the request. Linking moves, copies and alters nothing. It records what the ask was for, which is why it is safe to try.

Reading the history

Open a contact and click History on the field under Details, or on any linked request row in the Requests tab.

It lists everything that person has sent for that document type, newest first, across every portal. Each entry gives the file, when it was uploaded, its expiry date (in red once it has passed), and whether it is approved, rejected or awaiting review. Below that, the portal it arrived through and, where the request was worded differently from the field, what it was called at the time: "asked as COI" is often what tells you which certificate you are looking at.

If document retention has deleted a file, its entry stays in the history with the date it was deleted, but no longer opens.

Answers work the same way. Document types hold files, but History is on your Text, Choice, Date, Number and Time fields too, and there it shows what the person answered on each portal, alongside the value currently on their record.

Which file counts as current

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

That matters when someone sends the wrong thing. Reject their latest upload and 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 is still in the history with its rejection showing. If a contact is showing an older certificate than you expect, that is where the newer 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 vanishing and leaving the person looking like they never sent anything.

Files you attach yourself

You can attach a document to a contact directly instead of waiting for a submission, which is what you do when someone emails you the certificate rather than using their link.

Files attached this way keep only the most recent one: replacing overwrites. Files that arrive through a request are all kept. So collect documents through requests where you can, and treat direct attachment as the exception. The history says this on the entry itself, so nobody is left wondering whether something went missing.

Getting help

Email [email protected] if a document type is not picking up files you expected, and say which field and which portal.