Incident reporting across forms, APIs, and data
At CMV Group, I prepared a responsive reporting architecture for a planned rollout to 2,000+ employees across dealerships and workshops.
- Contribution
- CMV Group · System architecture
- Period
- Apr 2024 — Present
- Status
- Architecture prepared
- Planned reach
- 2,000+ employees
Designed around the operating environment.
Employees need a responsive reporting path; operational teams need controlled records, attachments, and review across dealerships and workshops.
- Planned reachMore than 2,000 employees
- EnvironmentDealerships and workshops
- InputStructured reports and attachments
Capture once. Store each thing where it belongs.
Structured records and report attachments cross the same API boundary, then branch into the storage designed for each data type.
- CaptureSharePoint / PlumsailResponsive custom JavaScript form
- API boundaryAzure FunctionsREST interface
- RecordsSQL ServerStructured incident data
- FilesBlob StorageReport attachments
Architecture prepared.Planned, not yet deployed.
The boundary is the design decision.
Azure Functions separates interface behaviour from persistence, while each kind of data keeps an appropriate destination.
Records
SQL Server holds the structured incident data needed for controlled operational review.
Files
Azure Blob Storage holds report attachments without forcing them into the record model.
Architecture prepared. Implementation ahead.
The architecture was prepared for a planned rollout to more than 2,000 employees. At the point covered here, implementation and deployment remained ahead.