Operational problem
Connect scanning, customer records, standardized reporting, and client retrieval.
Documents moved through several tools: customer and operational records lived in FileMaker, Konica scanning software generated PDFs, Word provided the standard report format, and clients needed a controlled way to retrieve completed results. Manual handoffs between those layers created avoidable association and delivery work.
Users and constraints
Support internal staff and external clients without replacing every existing tool.
- Staff needed each generated PDF associated with the correct customer record.
- Standardized reports needed to be populated from FileMaker data and delivered as PDFs.
- Clients needed a client-facing retrieval path for their completed results.
- The application workflow had to coexist with FileMaker, Konica scanning software, Microsoft Word, and the existing operating process.
- The supporting environment spanned three locations, approximately 25–50 endpoints, site-to-site VPN connectivity, and Windows Small Business Server.
How I framed the problem
Integrate around the record of work instead of forcing a platform replacement.
FileMaker already held the customer records, the scanning software already created the PDFs, and Word already defined the standard report. Replacing every tool would have added risk without solving the handoff problem. I focused the requirements on reliable record association, repeatable report population, controlled client retrieval, backup, recovery, and clear support documentation.
How the system worked
A document path from capture to client delivery.
FileMaker records
Customer and operational data remained in the established record system.
Generated PDFs
Konica scanning software produced the document files entering the workflow.
Windows integration
A Visual Basic application associated each generated PDF with the correct FileMaker record.
Report automation
Word VBA populated standardized reports from FileMaker data and produced final PDFs.
Client portal
The client-facing application and integration provided retrieval of completed results.
The integration strategy preserved the tools already supporting the business and added focused automation between them. That reduced migration risk while still creating a coherent record, reporting, and delivery path.
What I owned
Developed the integration, portal, reporting automation, and supporting environment.
- Visual Basic
- Visual Studio
- C# components
- Windows tray apps
- Windows services
- Word VBA
- FileMaker
- PDF workflow
How I tested it
Validate association, generation, retrieval, and recovery as one chain.
I tested whether each scanned PDF reached the intended customer record, whether the standardized report received the correct data, whether the final PDF was produced, and whether the client could retrieve the intended result. Infrastructure checks also covered site connectivity, endpoint behavior, local tape backup, separately located off-site backup, and documented restoration procedures.
Result
A deployed platform used by staff and clients.
The integration and portal connected the document workflow across a three-location Windows environment. Staff used the combined record, document, and reporting path, and clients retrieved completed results through the portal.
What I learned
Focused integration can outlast a premature platform replacement.
The useful boundary was the handoff between systems, not the internal design of every product. A modern iteration would add explicit document identifiers, integrity checks, synthetic workflow tests, role-based portal access, observable job states, and regularly exercised recovery tests while retaining the separation between source records, generated documents, and delivery.