Sending a terms request

Alongside collecting documents and answers, 1pm can put your terms in front of someone and record that they accepted them. It works as one more kind of Request, so it drops into the same checklist your crew or contractors already work through on their no-login link. You pick which terms to show, choose how firmly you want them to sign off (a tick, a typed name, a drawn signature, or a combination), and 1pm freezes exactly what they agreed to and when. This article covers setting that up and reading the result. For the legal question of whether an electronic acceptance counts, see its companion, Electronic signatures and accepting terms.

Where the terms come from

A Terms / Agreement request shows one of the versioned templates in your terms library, so write the wording there first. Your library keeps a version history, which is the point: when someone accepts, the exact version they were shown is pinned to their acceptance, and any later edit you make starts a new version rather than rewriting what they already agreed to. See Your terms and conditions library for building and versioning templates.

Adding the request

Open the event or Portal, expand the Requests panel, and add a request of the Terms / Agreement kind. Pick the template you want from the picker (only your own account's templates appear), and choose how the person confirms:

Tick to agree is always there. The person confirms they have read and agree.
Require a typed name adds a name field they must fill in as they accept.
Require a signature adds a "sign here" pad they draw on with a finger, mouse, or pen.

These combine freely. A light acknowledgement can be a tick on its own; a contractor agreement might ask for a tick, a typed name, and a drawn signature together. Turn on only what the document warrants.

What the person sees

On their private link the terms appear as a card in their Requests checklist. They read the current version, tick to confirm, type their name if you asked for one, and sign the pad if you required a signature. The pad works on a phone, so someone can sign with a fingertip on the spot, and a Clear button lets them redo a wobbly signature. Someone who can't draw on the pad, because they use a keyboard or a screen reader, can tick a box under it to use their typed name as their signature, and the acceptance is recorded with that name and no drawing. Until every required part is done, the Accept button stays disabled, so no one can half-accept by mistake. If you publish a new version while someone has the terms open, pressing Accept tells them the terms were updated and shows the current version to read and accept, so nobody is recorded as agreeing to wording they never saw.

What gets recorded

Acceptance is captured as an audit trail, not just a fleeting tick. For each acceptance 1pm records:

Who accepted, identified through their own private link.
That they ticked to agree, and their typed name where you required one.
The exact version of the terms they saw, frozen at that moment, with a content fingerprint so the wording cannot be altered after the fact.
The date, time, and IP address of the acceptance.
The drawn signature as an image, where you required one, stored privately with the response.

The record is append-only. A crew member cannot delete their acceptance, and if the same person opens the link and accepts again nothing is double-counted. Once accepted, the request counts as satisfied, so it feeds the completion bar on their link and the Requests dashboard like any other request.

Reading who accepted

On your side, open the request's responses to see each acceptance: the signer's name, the version they agreed to, and the date. Where a signature was required, the drawn image is held privately against that response. This is your defensible record that a named person agreed to a specific version of your terms at a specific time.

About the drawn signature

The drawn signature is there because people expect a "sign here" moment, not because it adds legal weight. The evidence that makes an acceptance binding is the audit trail above: the identity, the frozen version, and the timestamp. A drawn squiggle is comfort and familiarity, so require it when your audience expects to sign and leave it off when a tick and a name already say everything. The reasoning is set out in full in Electronic signatures and accepting terms.

When the document is a PDF

A Terms request shows text from your terms library. If the document already exists as a PDF (a contract from your lawyer, a policy you've been sent), use a Sign PDF request instead: you upload the PDF and each person signs it, with the same typed name and drawn signature options. See Asking someone to sign a PDF.

Electronic signatures and accepting terms covers whether an electronic acceptance is legally valid.
Your terms and conditions library covers writing and versioning the templates a Terms request shows.
Asking crew for documents and info covers the other request types in the same checklist.
Portals and Using 1pm for onboarding and compliance requests cover the onboarding flows a terms acceptance most often sits in.