Structured data
Work orders, sites, assets, approvals and immutable activity records are separate related entities.
Practical proofInspect the thinking, controls and delivery detail
These demonstrations use anonymised organisation names and synthetic data. They are not client case studies or claims of measured client results. They are working examples of how Solvanto approaches process design, Power Platform delivery, integration and supportability.
Evidence boundary
No client identity, confidential implementation, invented testimonial or implied before-and-after result appears here. Real results will only be published with permission and a defensible basis.
01 · Anonymised demonstration
A Power Apps work-order experience, using synthetic data
The anonymised “UK Facilities Group” team receives requests from three sites. The demo shows the information architecture and controls we would validate before styling a production app.
UK Facilities Group Work Hub
Anonymised name · synthetic recordsOpen work
18
Due this week
7
At risk
2
Within SLA
94%
My operational queue
Select a record to inspect its controls and history.
| Reference | Site | Request | Priority | Owner | Due | Status |
|---|---|---|---|---|---|---|
| North Depot | Safety inspection | High | Jordan P. | 16 Sep | In review | |
| Central Office | Access request | Standard | Morgan L. | 17 Sep | New | |
| South Depot | Equipment repair | Critical | Taylor R. | 15 Sep | At risk |
Selected record
WO-1042 · Safety inspection
- Asset / location
- Loading bay 2
- Approval route
- Area manager review
- Current owner
- Jordan P.
Audit trail
- Inspection submitted · 10:42
- Assigned to Jordan P. · 10:44
- Evidence requested · 11:08
Process automation
Routing, reminders and escalations respond to state changes without hiding accountable decisions.
Role-based access
Requesters, reviewers, engineers and service owners see only the actions and records they need.
Operational control
SLA timers, exception queues, failure alerts and ownership make the app supportable after launch.
02 · Annotated redesign
From shared spreadsheet to governed app
This is a design review, not a claim that every spreadsheet needs replacing. It shows what must change when a workbook becomes a multi-user operational system.
| Workbook behaviour | Why it matters | Governed redesign |
|---|---|---|
| Free-text site, owner and status columns | Misspellings and inconsistent values break filters and reporting. | Reference tables, required fields and controlled status choices. |
| Rows overwritten to show the latest position | No reliable history of who changed what or when. | Separate activity history with timestamps, actor and reason. |
| Approval confirmed in email | The decision is detached from the record and easy to lose. | Recorded approval outcome, comments and escalation path. |
| One workbook shared with every user | People can see or alter records outside their responsibility. | Role-based views and least-privilege access to the data source. |
| Weekly report assembled with copied formulas | Manual preparation creates delay and silent calculation errors. | Agreed measures calculated from structured, validated records. |
Design gate: keep the spreadsheet if the process is low-risk, single-owner and genuinely easier to support there. Replace it when concurrency, permissions, auditability, validation or integration justify the extra system.
03 · Architecture walkthrough
A supportable order integration—including the failure path
A happy-path diagram is not enough. This example pattern shows how an order event can move between systems while remaining traceable, retryable and safe from duplicate processing.
01
Accept and identify
Receive the event through an authenticated endpoint. Assign a correlation ID and reject malformed payloads before processing.
02
Validate and transform
Check required fields and business rules, then map the source contract to a stable internal model rather than coupling systems directly.
03
Process idempotently
Use the source event ID as an idempotency key so a retry cannot create a duplicate order or repeat a financial action.
04
Deliver and observe
Write to the destination, record duration and outcome, and expose a useful business identifier in logs and alerts.
Transient failure
Retry with bounded exponential back-off. Preserve the correlation and idempotency keys.
Invalid business data
Do not retry forever. Quarantine the message, explain the validation failure and assign an owner.
Operational signal
Alert on sustained failure or ageing work, not every technical wobble. Link the alert to a runbook.
04 · Decision tool
Should we automate this?
Answer four questions to find a sensible starting position. The result is a prompt for discovery, not an automatic business case.
Question 1
Is the process stable and clearly owned?
The rules and expected outcome should be understood before they are encoded.
Technical reasoning
Trade-offs, failure modes and maintainability decisions
These articles explain when a focused change is enough, when a stronger system is justified, and why the data and support model matter as much as the front end.
A useful first conversation
If you have a similar process, send us a short description and we’ll suggest the first three questions worth answering.
No obligation to start a project and no assumption that a new app or automation is the answer.