Electronic Signatures

Setting Up Electronic Signatures

Electronic signatures collect a signature over a document — a contract, a consent form, a tenancy agreement, a care plan.

Where to find it

Architect Panel → Forms:

• Signature Types — the kinds of signature and which provider performs each
• Signature Roles — who signs, in what capacity
• Signature Requests — requests in flight and their state

Architect Panel → Data:

• Documents — the document being signed and the signed artefact

Architect Panel → Security:

• User Verification — optional identity assurance before signing

Types and providers

A signature type pairs a kind of signature with the provider that performs it — the same shape identity verification already uses, so if you have configured that this will look familiar.

That separation means you can have a simple type for internal acknowledgements and a stronger type for anything contractual, each going to a different provider, without changing how either is requested.

Signer roles

Signature Roles define who signs and in what capacity — applicant, guarantor, witness, authorised officer. Roles matter because the order and the requirements often differ: a witness may need to sign after the principal, and an authorised officer may need a higher assurance level.

Identity assurance before signing

A signature type can require identity verification before the signing ceremony opens. Where the document has legal consequence, this is what connects the signature to a person rather than to whoever had the link.

Decide this per type. Requiring a passport check to acknowledge a policy document will simply mean nobody acknowledges it; not requiring one on a tenancy agreement is a gap you will be asked about.

The document is the thing signed

Signatures are taken over a document held in document management, and the signed artefact comes back as a document too. That means the signed version is stored as a distinct object rather than a flag on a record — so you can produce exactly what was signed, later, without regenerating it from a template that has since changed.

Setting it up

1. Configure the provider credentials for the type you need.
2. Create a signature type, choosing the provider and whether identity assurance is required.
3. Define the roles that will sign, and their order where it matters.
4. Test end to end with a real document and a real signer — ideally yourself on a personal device, because the signer experience is not visible from the admin side.

Worked example

A housing provider uses two types. "Acknowledgement" is a simple signature with no identity check, used for policy sign-offs by staff. "Agreement" requires identity verification and is used for tenancy agreements, with roles for tenant, joint tenant and authorising officer, signed in that order.

Recommendations

• Match assurance to consequence. Two types is usually enough; five is over-engineering.
• Test as the signer, on a phone, before going live.
• Keep the signed artefact, and never regenerate a signed document from its template.
• Define role order explicitly where a witness or countersignature is involved.

Requesting and Tracking Signatures

A signature request is a document, a set of signers in their roles, and a state you can watch.

Where to find it

Architect Panel → Forms:

• Signature Requests — requests in flight, their signers and their state

Architect Panel → Activity:

• Correspondence — the request and the signed result on the record

Requesting

A request names the document and the signers. Where roles have an order, the next signer is invited when the previous one completes — so a witness is not asked to witness a signature that does not yet exist.

Tracking

Signature Requests shows what is outstanding. Two things are worth watching:

• Requests sent and never opened. Usually a wrong or stale email address, and the fix is to correct the record rather than resend to the same address.
• Requests opened and abandoned. Often the signer hit an identity check they were not expecting, or could not complete on the device they were using.

Chasing

Pair a signature request with an obligation where there is a deadline, so chasing is systematic rather than somebody remembering. A signature outstanding for three weeks with nobody chasing is the normal failure mode, and it is entirely preventable.

When somebody will not or cannot sign

Have a fallback. Some people cannot complete an electronic ceremony — no smartphone, no email, a disability that makes the interface impractical, or simply a refusal. A process with no wet-signature route excludes those people, which is both a service problem and potentially a discrimination one.

Record the alternative on the case so the file shows why a signature was taken differently.

What you end up with

A signed document stored as a document, linked to the record, with the audit trail of who signed, when, and under what assurance. That is what you produce if the agreement is ever disputed — so check once, early, that you can actually retrieve and produce it.

Worked example

A care provider sends care plan agreements for signature with a seven-day obligation. The dashboard lists requests outstanding beyond five days. Where a client cannot sign electronically, a paper copy is signed at the next visit, scanned, and attached with a note — so the file is complete either way and the exception is visible rather than looking like a gap.

Recommendations

• Pair every request with a deadline obligation.
• Have a documented non-electronic route and use it without friction.
• Check the email address before sending, not after three chases.
• Retrieve one signed document as a test before you rely on the process.