Document attestation for a regulated business: publish a policy, make sure the right people read it, and prove they did.
Financial Services · Compliance2 weeks
- 01Draft
- 02Publish
- 03Attest
- 04Prove
- 05Maintain
The film · 2:21 · narratedFrom upload to locked evidence, step by step
Introduction
Attest Hub is a document attestation platform built on Salesforce by SyntaxWise. Admins publish controlled documents, every assigned person reads and confirms them, and compliance can prove exactly who confirmed which version, and when.
- Year
- 2026
- Industry
- Financial Services · Compliance
- Timeline
- 2 weeks
- Client
- Withheld at the client’s request
- Scope of work
- Solution ArchitectureLightning Web ComponentsApex ServicesData ModelSecurity & AccessScheduled AutomationEmail Notifications
Challenge
Policies were shared, but nobody could prove who had read them, which version they read, or what was overdue.
In a regulated business, sending a policy by email is not enough. Auditors ask a harder question: can you show that each person confirmed the right version, on a specific date, and that nobody can quietly edit that record afterwards?
Documents were being circulated manually, versions were replaced without a clean trail, and there was no single place to see who still had something outstanding. The goal was to build that place directly inside the existing Salesforce org, with no external tools, and to make it simple enough that every member of staff would actually use it.
What was built, in numbers
What it had to do
Control what gets read
One governed library, grouped by category, with owners, versions, review dates and a clear status on every document.
Reach the right people
Assign by Salesforce role, optionally including everyone below in the hierarchy, or send to all staff. Know the head-count before you publish.
Prove it afterwards
Every confirmation is stamped by the server with who, when, which version, which file and which wording, then locked for good.
Admin hub
Stage 1 of 5:DraftOne hub to manage every document, grouped by category.
Administrators work from a single page. Documents sit under numbered categories, and every row shows the document number, type, version, status, validity, owner, next review date and a live Confirmed / Assigned count. Active, Expired and Archived views separate what is live from what needs attention, and a category and validity filter plus free-text search narrow any list.
Status and validity are separate. A document can be Published and still be Due for Renewal or Expired, so nothing silently disappears from staff while admins catch up.
Category grouping keeps a growing library navigable, with a select-all per category for bulk actions.
Access is permission-driven. The hub is gated by a dedicated custom permission, so only the people who should manage documents can.
Upload & publish
Stage 2 of 5:PublishUpload as a draft. Nobody is assigned until you publish.
New documents are saved as a Draft, so an admin can check the file, owner and audience before anything reaches staff. Publishing is a separate, deliberate step that creates one confirmation request per person and notifies them.
5 steps, scroll sideways or use the arrows
Real Salesforce roles
Choose all staff or pick roles from the org’s actual hierarchy. Each role shows how many people are in it, and one toggle includes every role below the selection.
Working-day due dates
Admins set how many working days staff have to read and confirm. The due date is calculated from a business-hours calendar, not simple calendar days.
Explain every new version
A summary of changes is shown to staff. Admins decide whether people who confirmed an earlier version must confirm again, and must give a reason if they don’t.
Preview before you commit. Publishing first calculates who is eligible, how many open requests on older versions will be superseded, and any problems that would block it.
All or nothing. Publishing runs as one transaction. If any step fails, nothing is committed, so there are no half-assigned documents.
Safe to repeat. Requests are keyed per person and version, so running a publish twice cannot create duplicates.
Email never blocks. Assignment emails go out on publish, but a mail problem can never stop a document from being published.
Lifecycle
A version and its requests move through clear states.
Two state machines run side by side. The version moves through Draft, Published, Superseded and Archived. Each person’s request moves from Outstanding to Completed, or is closed with a precise reason, so reports never have to guess what happened.
Document version
- Draft
- Published
- Superseded
- Archive, from Draft, Published or Superseded. Completed evidence is never touched.
- Restore returns it to its previous state, or to Superseded if another version is now live.
Confirmation request · one per person
- Outstanding
- Overdue
- CompletedLocked · audit evidence
- Completed is reached from Outstanding or Overdue, and only through the confirm service.
- Open requests are closed with a reason when the version is archived or replaced: “Archived – not completed”, “Superseded – not completed”.
Archive & email
Stage 5 of 5:MaintainRetire documents without losing the audit trail.
Documents can be archived one at a time from the row menu, or in bulk by ticking several rows. Archiving takes a document out of circulation, closes the work that is no longer relevant, and leaves completed evidence untouched.
Open requests are closed, not deleted. People who hadn’t confirmed are marked “Archived – not completed” and the item disappears from their list.
Completed attestations are never touched. They are audit evidence and stay exactly as they were.
Restore is safe. A version returns to its previous state and the closed requests re-open. If another version went live in the meantime, it returns as Superseded, so a document never has two live versions.
Send documents to colleagues without leaving the page.
Tick one or more documents and open the composer. Pick a saved template or start from scratch, choose recipients, and send with the documents attached. The same composer is on both the admin hub and the staff view.
People & history
Stage 4 of 5:ProveSee compliance by person, then drill into every document.
The People view flips the question from “which document?” to “which person?”. It summarises documents assigned, declarations done, open and overdue for each person. Opening a person shows every document and version they were given, with shared date, due date, read state, declaration state and request status.
Role-aware. Each person’s role is shown, so managers can see patterns by team.
One click to the proof. The Details button on any row opens the complete record for that person and version.
Gated access. The history view has its own custom permission, granted to the Administrator and Oversight read-only sets.
Staff view
Everyone gets a simple view of what they need to read.
Every member of staff sees the same clean screen, with no admin controls. All Documents lists everything published and its validity, so people can always find the current policy. My Documents shows only what was assigned to them, with clear counters and a deadline on every item.
Overdue, pending, attested
Three numbers answer “what do I owe?” in a second, and a friendly banner confirms when nothing is pending.
Date due and date attested
Each row shows the attestation deadline and the date it was completed, so people can see their own record.
Newer version, clearly flagged
When a document is replaced, earlier confirmations show as “Attested – newer version issued” and unfinished ones as “Superseded – not completed”.
Review & attest
Stage 3 of 5:AttestOpen it, read it, sign it. In that order.
When a document is published, it appears in each person’s My Documents as Pending Attestation, with a deadline. One action opens the Review & Attestation Portal, a short guided screen that makes the person open the document before they can sign.
1One item pending. The counters update the moment a document is published.
Step 1 of 7. Pick a step to see its screen; click the screen to read it at full size.
The same flow, end to end.
No shortcuts. The sign button stays off until the document has been opened and the declaration accepted. The server checks this again, so it can’t be bypassed from the browser.
The wording is explicit. They agree to having read, understood and complied; that they know how to raise concerns; and that false statements may lead to disciplinary action.
Deadline visible throughout. The date to attest by is on the row and in the portal.
A way out. With a question, they can send it to the compliance team from the same screen instead of signing.
Evidence by design
Confirmations are proof, and proof can’t be edited.
The most important rule in the system: only one code path can complete a confirmation, and it runs on the server. A person can only act on their own request. The browser never decides who confirmed what or when. The moment a request is completed, it is locked.
- Who
- The signed-in person who owns the request
- When
- Server timestamp, not the browser’s clock
- Which version
- The exact document version assigned
- Which file
- The file that was viewed, plus its fingerprint
- What they agreed to
- The full declaration wording and its version number
- How long it took
- Working days between assignment and confirmation
- Where from
- Source network address and first-opened time
- Tamper evidence
- A hash over the evidence, stored with the record
Must open before confirming. The first time a person opens a document is recorded, and confirmation is refused until they have.
Declaration is versioned. Each confirmation stores the wording it was signed under, so older confirmations keep their original text when the wording is later strengthened.
Locked on completion. After completion, any edit or delete is rejected. There is deliberately no bypass switch for these guards.
Append-only audit log. Assignments, first opens, status changes and completions go to an event log whose rows can be inserted but never updated or deleted, by anyone.
Staff are read-only by design. Staff only have read access to attestation records. The confirm service performs the write on their behalf, in a controlled way.
The Details dialog, part by part
Automation
Stage 5 of 5:MaintainValidity is watched every night, not remembered by a person.
Every published version carries a next review date, and its validity is calculated live as Live, Due for Renewal (30 days before review) or Expired. A scheduled job runs each morning and tells the right people the first time a version crosses each line.
One published version, over time
= the nightly check- 30 days before review: first email, sent once.
- Review date passes: second email, sent once.
Scheduled batch
Checks every Published version. Drafts, superseded and archived versions are ignored, because nobody relies on them.
No repeat emails
One notice at 30 days before review and one at expiry. Per-version flags guarantee each email goes out exactly once.
Recipients by group
Notifications go to a named group of administrators, looked up by name, so the audience can change without touching code.
Documents stay visible. A published document past its review date remains available to staff. The email is how administrators find out and renew it.
Fails safe. If the notification group doesn’t exist yet, nothing is sent and no flags are set, so the emails still go out once it is created.
Under the hood
Thin screens, focused services, strict guards at the data layer.
The interface is built from Lightning Web Components. Each action goes through a small Apex controller into a dedicated service that does one job. Triggers and handlers at the data layer enforce the rules, so they hold no matter which path writes the data.
- L1Lightning Web ComponentsThe screens
- Admin hub
- Staff view
- Person history
- Email composer
- L2Apex controllersThin, permission-checked
- Document manager
- My documents
- User history
- Attestation
- Email composer
- L3ServicesOne job each
- Publish
- Archive / Restore
- Audience
- Confirm · the only path to Completed
- Notification
- L4Triggers & handlersRules that always hold
- Lock on completion
- No delete
- Append-only audit log
- Controlled status transitions
The data: four objects, one chain
- DocumentCategory, owner, type
- VersionDraft → Published
- AttestationOne per person
- EventAppend-only log
Four objects, one chain
A Document has many Versions. A Version has many Attestations, one per person. An Attestation has many Events. Each link carries only what that level needs.
Three roles, two permissions
Administrator, Reader and Oversight (read-only) permission sets, plus separate custom permissions for managing documents and viewing a person’s history. Requests are owned by the person they belong to, under a private sharing model.
Services, not scripts
Publishing, archiving, audience, confirmation and notification each live in their own service, so each can be tested and changed on its own.
The choices that make the audit trail trustworthy.
Most of the value is in what the system refuses to do. These are the decisions we would defend in front of an auditor.
- 01One path to “Completed”A guard rejects any attempt to complete, or create a completed request, outside the confirm service. There is exactly one place to review and test.
- 02Administrators don’t need edit rightsServices write evidence in a controlled system context, so the admin who publishes never holds permission to edit attestations by hand.
- 03Idempotent by keyA unique key per person and version makes publishing safe to retry, and prevents duplicate requests.
- 04Real roles, not a copyThe audience comes from the org’s live role hierarchy and active users, so there is no second list to keep in sync.
- 05Notifications are best-effortEmail is a convenience layered on top. A failure is contained and can never block publishing or confirming.
- 06Configuration over codeRecipient groups, categories and templates are looked up by name or metadata, so operations can adjust them without a release.
Outcome
One place to publish.One click to confirm.A record nobody can rewrite.
Provable compliance
For any document, version and person, the organisation can show what was assigned, what was opened, what was agreed and when.
Less chasing
Counters, deadlines and overdue highlighting replace spreadsheets and manual follow-up, for administrators and staff alike.
Safe change
New versions, archiving and restoring all preserve completed evidence, so the library can keep evolving without breaking the audit trail.
Built with
Client details withheld at the client’s request.- Salesforce
- Lightning Web Components
- Apex services and controllers
- Apex triggers and handlers
- Batch Apex and Schedulable
- Custom objects
- Custom metadata
- Permission sets and custom permissions
- Public groups
- Business hours calendar
- Email services
