From wet ink to one signed record.
At Jefferson County Clerk's Local Board of Appeals hearings, decisions had to move from the room into signed records and result letters. We built a responsive iPad web workflow that captures the board's signing action and carries it through to the result.
A board decision, signed and carried through to its letter.
Appeal records begin in the Louisville PVA system and arrive at the Clerk through a daily import. We built the Local Board application around the next part of that process: review the imported case, record a decision, capture the board's signing action, and generate the result from the same record.
The work replaced wet-ink signing, paper decision sheets, and after-hearing scanning. The application also had to track who was serving on a board and keep results aligned with the PVA system.
The final handoff still depended on paper.
Appeal records start in Louisville PVA, not in the Clerk's board app. Once the imported record is available, the board reviews the case and records a decision. The last steps still relied on a paper decision sheet: collect wet-ink signatures, then scan the pages after the hearing. That left a paper handoff between a decision in the system and the result that needed to leave the hearing room.
The board sits as a group, while roughly eight to ten iPads are shared among members who sign in and out of both the device and app. A shared screen alone could not establish identity. The workflow had to resolve who was clocked in, show exactly who would be included when a member signed, and produce the correct record and letter. Identity and hearing operations mattered as much as signature input.
A layered application around the hearing workflow.
Delivery ran in stages from late November 2025 through mid 2026. A first logo pass came before the iPad signature features and repository migration to GitHub. We then completed signature and upload work, built out the Local Board application, and addressed printing and template issues. A separate test environment came before the April 2026 production cutover. Later additions included a payment report, roles, exports, and board member instructions.
The browser client is an Angular 21 single-page application in ClientApp. It is responsive and designed to behave like an app on the iPad, but it is not a native iPad application. The server side is an ASP.NET Core application organized into Model, Domain, Data, Services, and UI layers, with SQL Server for application data. Numbered SQL migration scripts include rollbacks, so each database change has a corresponding way to reverse it.
The application runs on IIS on a county network host. Environment-specific appsettings keep configuration separate, with CountyClerkDesktop used for production. GitHub Actions deploys through a self-hosted Windows runner.
From the board member's browser to the stored hearing record and county deployment path.
ClientAppOperations around the core included per-member hearing clock-in and clock-out, per-board daily-rate payment tracking that feeds the Order of Allowance report, and a calendar for incoming cases. Excel decision exports preserve locked column widths and numeric and date formats. The board member guide covers login, clock-in, case review, saving and signing a decision, and clock-out.
A web signing surface with a record behind it.
The responsive web UI uses HTML5 Canvas with touch and pointer events, supporting a finger, stylus, or Apple Pencil. Landscape gives board members a larger signing surface. This is a browser workflow, not a native iPad app.
On signing, a base64 PNG is stored in SQL Server beside signer email, UTC timestamp, IP address, and a SHA-256 hash for tamper detection. Signature rendering feeds the existing DinkToPdf result-letter generation, so the signed decision sheet and printed or emailed letter come from the same record.
We designed around ESIGN-style intent, attribution, and record retention, without claiming a certification or audit. The stored signature and attribution stay together with the decision.
Make the signing group visible before saving.
The board works as a group, so signing is a group action. When a board member signs, the system resolves which members are clocked in for that board and includes only those names. A confirmation dialog shows exactly who will be included before the signature is applied.
Per-member clock-in and clock-out is the source of truth for who is serving. If a Super Admin overrides that state, the audit record marks it as Administrative Override. Role-based permissions separate Super Admin, staff, and board member access. The application tracks members signing in and out on roughly eight to ten shared iPads because both signatures and payment tracking depend on who is in session.
The Clerk app consumes appeals and returns results.
Louisville PVA is where an appeal record starts. Louisville PVA sends records to the County Clerk through a message bus with a daily import. The Local Board application consumes the imported record, and hearing results flow back so the PVA side stays aligned. The Clerk app is one part of a two-system workflow, not a replacement for the PVA system.
Integration work included a neighborhood field that moved from integer to string, requiring changes on both sides. The API side also had to use TLS 1.2 in Azure before partial-ID updates would be accepted.
Rehearse the real workflow before hearing day.
Requirements took shape over several Microsoft Teams meetings with Clerk staff, not one large specification up front. We refined the flow for case review, saving and signing decisions, and clock-in and clock-out. Printing and template fixes were part of the same work, so the digital record still produced the required documents.
We stood up a test environment alongside production with its own database and a parallel IIS site on a second port, reached through a /test redirect. It used the same certificate, copied production IP restrictions, and had its schema compared with the live database.
Before hearing day, board members rehearsed from home. They logged in, entered values, applied a saved signature, and clocked in and out. They confirmed the flow from a home kitchen table. Hearing day ran without the paper step.
The record now carries the decision through to the letter.
The wet-ink step, paper decision sheets, and after-hearing scanning are gone. Signatures carry audit metadata, and the signed decision sheet and result letter are generated from the same stored decision. Clerk staff stopped chasing paper between the hearing and the follow-up work.
Clock-in and clock-out, signing confirmation, payment tracking, the incoming-case calendar, and formatted exports support work around each hearing. Results flow from imported appeal through decision and signature back to PVA. The Clerk is happy with the result.
Design around the hearing, not the signature pad.
Three decisions shaped the work:
- Shared hardware needs explicit identity. A tablet can move from person to person, so per-member clock-in and clock-out, session tracking, and a visible signing group matter more than treating the device as the signer.
- Generate documents from the record that was signed. Reusing the existing DinkToPdf result-letter path kept the signed decision sheet and its printed or emailed letter tied to one saved decision rather than splitting the workflow across copies.
- Integration and rehearsal are part of delivery. A field type change and a TLS requirement affected the handoff between systems. A separate test database and a home rehearsal let board members try the actual clock-in, decision, and signing flow before a hearing depended on it.
This was a hearing workflow, not a paper process with a canvas added. Its interface, group rules, database record, generated letter, and system handoff had to agree.
Working through a paper-heavy process?
Tell us about the workflow your team needs to bring into one reliable record.
Talk through your workflow