4 logged considerations
Back to case index
CASE 004Investigation depth Architecture notes Evidence items
Phlo Systems — trade-finance workflows
In progressFiled under Enterprise fintech / workflow UX
Frontend work on regulated trade-finance and operations surfaces: long-running cases, document-heavy steps, and dashboards where operators need current status without fighting the UI. Filed while the implementation is still evolving inside the organisation.
Lab register
3 structural threads
3 collected signals
Bottleneck & intervention map
Step through operational phases to see friction, constraint, intervention, and measured result. Evidence and tradeoffs re-tag to the bottleneck you select; comparisons stay concrete, not abstract.
Phase intensity
Relative emphasis on this pass—select a phase to load the intervention file and evidence rail.
Comparison
Dashboard freshness
Live regions align with committed server events; incremental updates reduce the stale-queue failure mode on the hottest operations views.
Filtered evidence
Phase “queue-dashboard” tags evidence to this bottleneck cluster.
- Evidence 01
Approved implementation record
The public evidence record documents the configurable Cost of Sales migration: 965 lines removed, 148 fields migrated, 90+ xUnit tests, and two calculation paths preserved.
Related signals
Still part of the case file—shown with lower emphasis while you explore other combinations.
- Evidence 02
Organisation context is public
Phlo’s product focus on trade and trade finance is documented on the company site; this file does not claim proprietary implementation details.
- Evidence 03
Status is explicit
Marked in progress so the archive stays honest: a partial fourth file is more useful than pretending every internal initiative is closed.
Jump to section
Case briefing
Section I
Phlo Systems builds digitised international trade and trade-finance software; day-to-day engineering includes workflow-heavy React and .NET surfaces where a case can span KYC, credit, collateral, and operational checks. Constraints are typical of regulated fintech: auditability, least-surprise behaviour, and consistency across modules that did not all ship at once. The work under this file was triggered where batch-style refresh patterns collided with operators who move between queues and instrument detail throughout the day.
Initial signal
Section II
Symptom
What broke first
Operators relied on views that only advanced on slow polling or manual refresh, so queue depth and instrument state could look idle while backend processing had already moved—especially painful for time-sensitive queues where the UI understated urgency. A secondary failure mode was duplicated step and form scaffolding across instrument families, which slowed each new workflow variant because validation and navigation were re-wired instead of shared.
Evidence collected
Section III
Full evidence archive for quick scanning—independent of the lab canvas filters above.
Approved implementation record
The public evidence record documents the configurable Cost of Sales migration: 965 lines removed, 148 fields migrated, 90+ xUnit tests, and two calculation paths preserved.
Organisation context is public
Phlo’s product focus on trade and trade finance is documented on the company site; this file does not claim proprietary implementation details.
Status is explicit
Marked in progress so the archive stays honest: a partial fourth file is more useful than pretending every internal initiative is closed.
Investigation path
Section IV
Phase-by-phase friction lives in the lab canvas—below is the public investigation transcript and constraint notes for readers who want the full log.
- Log 01
Measured the cost of polling-first dashboards versus push-based updates for the hottest queues; ruled out increasing poll frequency alone because it raises load without guaranteeing ordering against rapid successive events.
- Log 02
Evaluated SignalR (already part of the surrounding stack) against long polling for incremental updates—tradeoff: connection management, reconnect, and back-pressure handling versus simpler but stale HTTP-only models.
- Log 03
Reviewed how workflow shells (headers, step lists, document panels) could stay stable while step content varies by product, to avoid copying the same layout scaffolding per instrument type.
- Log 04
Acknowledged confidentiality: detailed schemas, customer data, and internal service names stay out of this file; the public record here is architectural shape and problem class, not proprietary identifiers.
Constraint notes
Tradeoff 01SignalR vs. long polling
Long polling is simpler to reason about fail-mode-wise but still races rapid updates; SignalR shifts complexity to connection lifecycle while improving timeliness for operators juggling multiple queues.
Tradeoff 02Public record vs. internal detail
Schemas, customer data, and internal service names stay out of this file; the portfolio captures problem class and architectural shape consistent with public Phlo positioning, not proprietary identifiers.
Resolution
Section V
Dashboard freshness
Observed friction
Manual refresh or slow polling as the primary signal of queue movement—higher poll rates add load without guaranteed ordering against rapid successive events.
Engineering response
Live regions align with committed server events; incremental updates reduce the stale-queue failure mode on the hottest operations views.
Workflow delivery
Observed friction
Repeated one-off wiring for step navigation and document panels when standing up a new instrument workflow.
Engineering response
Shared primitives for shells and validation patterns where product rules converge; bespoke only where the instrument genuinely diverges.
Active view
- Action 01
Align live regions of the UI with server-authoritative events so operators see queue and status changes while staying inside authenticated sessions.
- Action 02
Push repeated layout and validation patterns toward shared workflow primitives where product rules allow, without forcing unsuitable abstractions on genuinely different instruments.
- Action 03
Keep changes reviewable in small slices: connectivity and freshness first, then consolidation of duplicated step wiring where it reduces defect surface.
- Action 04
Document outcomes in internal channels and PR history rather than in this portfolio at vendor-detail granularity.
Active view
- Structure 01
Client applications are TypeScript React against .NET services; high-churn dashboard and queue regions use real-time channels (SignalR) so the browser does not simulate liveness by hammering REST lists. Boundaries separate shell navigation from step content so document and approval panels can load independently of the outer workflow frame.
- Structure 02
Authorisation and tenant scope remain server-side; the UI reflects permissions but does not implement policy. State updates from live channels are treated as hints to refetch or patch known query caches rather than blindly trusting every payload as a full snapshot.
- Structure 03
Operational concerns—loading states, error surfaces on reconnect, and degradation when sockets are unavailable—are treated as part of the feature, because finance operators need clarity when the line goes quiet.
Outcome
Section VI
Long-form result
This case is filed as in-progress: the direction is verified (live updates for critical dashboards, fewer duplicated workflow shells), but quantified rollout metrics stay internal. The public evidence log records a separate, approved Cost of Sales refactor from the same engineering context; it supports implementation depth without being presented as a metric for this workflow initiative.