Signature Fields

A Signature field lets someone sign a document you keep on a record: a contract, a waiver, a quote approval, a policy acknowledgement. They type their name, confirm they mean it as their signature, and the field locks. From then on the record holds a permanent account of who signed, when, and exactly what the document said at that moment.

Signatures are designed to meet the US ESIGN Act and UETA, the laws that make an electronic signature as binding as a handwritten one.

What you need first

A signature always signs a specific document, so the table needs a Text Area field with its Format set to HTML Rich Text. That field holds the agreement itself: you can type it, paste it, or have an automation fill it in per record.

If your table has no rich text field yet, add one before adding the signature.

Adding a signature field

In a table's Configure screen, open the Fields tab, click Add Field, and choose Signature. Then set:

• Document to sign: the rich text field being signed. Pick carefully: this cannot be changed later. A signature records a fingerprint of one specific document, so allowing it to be repointed afterwards would leave old signatures claiming to cover text nobody ever agreed to. If you picked the wrong one, delete the field and add a new one.
• Email field: where the signer's email address lives, used to send them their copy.
• Consent wording and Signing statement: leave both blank to use the standard wording, which already makes the disclosures the law expects. Replace them only if your legal team has specific language.

A signature field is never marked Required. The record has to exist, with the document written into it, before anyone can sign, so requiring a signature would stop you creating the record at all.

Signing

On a record, the field starts as a locked box reading Click here to sign. Clicking it opens the agreement, which asks you to confirm two things:

1. That you agree to sign electronically.
2. That you intend your typed name as your signature.

Only once both are confirmed does the box unlock and let you type. If you close the agreement without confirming both, nothing unlocks and nothing is recorded.

The name alone is not a signature. A name in a text box could be anything, so the confirmation is what makes it binding, which is why neither box is ever ticked for you. After you agree, a line under the field reminds you what you agreed to, with a Review link. Reviewing lets you withdraw the agreement, which clears the name and locks the box again.

On a signature web form the same two confirmations sit on the page itself, below the document, because there the whole page is the signing.

Once submitted, the field locks. The signature cannot be edited, re-signed, or cleared, by anyone, through the app or the API. Only a workspace admin can reset it (for a signature given in error), and that reset is recorded in the record's activity.

What gets recorded

Alongside the typed name, InfoLobby stores:

• The exact time, taken from our servers rather than the signer's device, so a signature cannot be backdated by changing a computer's clock. The signer's own local time and timezone are kept too, marked as reported rather than verified.
• The signer's IP address and browser, and how the signature was made (in the app, or through the API).
• The wording they agreed to, word for word, so the record proves what was actually shown.
• A fingerprint of the document as it stood at that moment.
• A complete copy of the document, kept separately and never altered.

That last point matters most. A fingerprint can prove a document changed, but it cannot show what the original said. Keeping the copy is what lets you produce the signed agreement years later, which is exactly what the law requires.

If the document is edited afterwards

You can still edit the document after it has been signed. Nothing is silently overwritten: the signature immediately shows a red Document changed since signing warning on the record, and the copy taken at signing time is still available.

This is deliberate. Freezing the document outright would strand records with no way out, and would not stop a change made outside InfoLobby anyway. Making the change loud is more useful than pretending it cannot happen.

You will also see:

• Verified (green). The document is unchanged and the record is intact.
• Cannot be verified (amber). Usually a signature that came from a different InfoLobby account, for example after copying a workspace. It is not evidence of a problem; it just means the tamper check cannot run here. The document comparison still works.

Sending a document out to be signed

Signing in the app is one half. The other is sending the document to someone who has no InfoLobby login, which is what a signature form does. It is one of the three kinds of web form.

Set one up on the table's Configure screen, under the Public tab, and pick which signature it collects. Then open the record holding the document, choose Share from its menu, and copy the link. Send it however you like.

The signer sees the document first, read-only and at full height, with the consent statement, the name box and the confirmation below it. The name box stays locked until both statements are confirmed.

They cannot change the document, ever. Other fields on the form are read-only unless you unlock them, which is how you collect a job title or a reference number along with the signature. See web forms for how.

Each record gets its own link and it stays the same, so an email you sent last month still works. If a link reaches the wrong person, use Reset Link on that record to replace it, or Revoke to switch it off. Other records are unaffected.

Most people send these from an automation rather than by hand: use the {{webform_url:ID}} token in an email body so a quote reaching "Ready to sign" mails its own signing link.

The signer's copy

After signing, the signer can download a certificate of completion: the document exactly as it stood when they signed it, followed by the audit trail. Their link stays live afterwards, so they can come back and download it again whenever they need to.

You can download the same certificate from the record at any time. Open the record and click Certificate under the signature.

The certificate is generated fresh each time rather than stored, which means the verification on it is always current. Download one after somebody edited the document and it says so, in a warning at the top, and still reproduces the copy taken at signing underneath.

Several signatures on one document

A table can hold as many signature fields as you need, all pointing at the same document. A two-party contract typically has a Client Signature and a Contractor Signature. Each is signed independently, in any order, and each records its own signer. They share one stored copy of the document.

There is no signing order: either party can sign first, and neither is blocked by the other.

If you are sending the document out, create a separate signature form for each party. A signature form collects exactly one signature, so the link you send one party cannot be used to sign for the other, and each of them downloads their own certificate.

Declining

Someone asked to sign can decline instead. The refusal is recorded on the field, with a reason if they gave one, and is as final as a signature. That way a record shows the difference between "nobody has signed yet" and "this was refused on 12 March".

What signatures do not do

• They are simple electronic signatures. InfoLobby does not issue certificate-backed signatures (EU Qualified or Advanced eIDAS signatures), which need a trust service provider.
• We do not verify who someone is. The signature proves that whoever was at the keyboard typed that name and agreed to be bound by it. It does not prove they are the person that name belongs to.
• Very large documents cannot be signed. If a document with its images exceeds the size we can retain, signing is refused rather than recorded without a copy, since a signature we could not reproduce would be worth nothing. Shrink the document or its images.

Signatures in grids and public embeds

In a grid, a signed field shows who signed and when, without a verification badge. Checking the document on every row of every page would be slow, so the check runs on the record itself, where it belongs.

On a public embed, a signature shows only the signer's name, the date, and whether it was signed or declined. The IP address, browser, and audit details are never published.