← All help articles

Asking someone to sign a PDF

Asking someone to sign a PDF

A Sign PDF request puts a PDF in front of someone and records their signature on it. Use it for a document that already exists as a PDF: a contractor agreement, a photography release, a venue policy, an NDA. It is one more kind of request, so it sits in the same checklist on their private link as their uploads and questions, on an event or a Portal alike.

For terms you keep as text in your terms library, a Terms request is the better fit. See Sending a terms request.

Adding the request

Open the event or Portal, go to the Requests panel and pick Sign PDF. Give it a name, choose the PDF from your computer, and decide how the person signs:

  • Require a typed name asks them to type their full name.
  • Require a drawn signature adds a pad they sign with a finger, mouse or pen.

Both are on by default, and so is Required. Untick it if signing is optional. After the request is added, the two signer options sit on its row as Require typed name and Require signature, where you can change them.

The PDF has to be uploaded to the request itself, up to 10 MB. A file from your Files library can be edited later, and a link can change without anyone knowing, so neither is accepted: the document people sign has to stay exactly as it was.

What they see

On their link the request shows the PDF's name and an Open button. The PDF opens in a new tab, which works reliably on a phone. Once they've opened it, they tick that they've read it and agree, type their name, draw their signature and tap Sign. The Sign button stays disabled until every required part is done.

After signing they see who signed and when, their signature, and a link to download their signed copy.

What gets recorded

For each signature 1pm records:

  • Who signed, identified through their own private link.
  • That they ticked to confirm they read and agree to the document.
  • Their typed name and drawn signature, where you asked for them.
  • The exact PDF they signed: the file itself, kept as it was, and its SHA-256 fingerprint.
  • The date, time, IP address and browser they signed from.

Once signed, the request counts as done on their completion bar and on the Requests page.

The signed copy

Open the request's responses and each signature has Download signed copy (PDF). The file is the PDF they signed, with a signature page added at the end listing the document, who signed, when, from which IP address and browser, the drawn signature, and the document's SHA-256 fingerprint. The person who signed can download the same file from their link. An earlier signature kept in the response history has its own signed copy too, but its signature page has no IP address or browser, because the history does not keep them.

If the original PDF can't be combined with the signature page (a damaged or password-protected file, for example), the download is the signature page on its own. It still carries the fingerprint that identifies the document.

The fingerprint is how you prove which document was signed. It changes if even one byte of the PDF changes, so anyone can check a copy of the document against the value on the signature page.

Replacing the PDF

To swap in a new version, remove the current PDF with the cross on its name on the request row, then upload the new one with the attach button. There is no replace-in-place, so until you upload the new file the row warns that nobody can sign. People who already signed keep their signature, and the PDF they signed is kept with it, so their signed copy still shows exactly what they agreed to. They stay marked complete.

If someone has the old PDF open on their link when you replace it, their signature is not recorded against a document they never opened. When they press Sign, they are told the document was replaced and asked to open the new one and sign again.

Earlier signatures are told apart by the PDF's fingerprint, not its name, so uploading an identical file flags nobody. After a real change the request shows how many people signed an earlier PDF and names them, with a button to email each of them a link to sign the current one. Anyone already sent that email in the last hour is skipped, so a second click, or a colleague pressing the same button, does not email them twice. No email goes on a closed portal or a cancelled booking, because nobody can sign there. On their link they see that the document has been replaced, and Sign again lets them sign the new PDF. Their earlier signature stays on record in the response history, and signatures there are never pruned.

They stay marked complete until they press Sign again. From then on, a required request counts as outstanding for them until they sign the new PDF.

Removing the PDF works the same way: existing signatures and their PDFs are kept, and nobody can sign until you upload a PDF again. Sign again is hidden on their link while there is no PDF. A request with no PDF attached also doesn't count towards anyone's completion bar, and the automatic reminders don't chase anyone for it, because there is nothing they can do yet. It becomes a normal request again as soon as you attach a PDF.

In a request pack

A Sign PDF request can go in a request pack. Pick the PDF from your Files library in the pack. When you add the pack to an event or Portal, 1pm copies the PDF onto that event, so editing the library file afterwards never changes a document someone is signing.

Is it a real signature?

Yes, for the documents 1pm is used for. The typed name, the tick, the recorded time and the fingerprinted PDF together make an electronic signature under the laws of most countries. See Electronic signatures and accepting terms for the detail and the few document types that still need wet ink.

Still stuck after reading this? Open a help ticket and we'll answer your specific question.