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

Configure the provider credentials for the type you need.
Create a signature type, choosing the provider and whether identity assurance is required.
Define the roles that will sign, and their order where it matters.
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.