Business systems / Design practice
Follow the bond record through the work
Open a bond record and the work quickly spreads beyond that screen. A document needs the case and parties. A renewal needs dates, terms, and recipients. A receipt changes an invoice balance and leaves a ledger entry. The same record supplies context to all three.
That makes the record a useful starting point for modernization. Follow it through an ordinary day before deciding how many screens to replace. The atlas below uses a fictional bond to show which details each operation reads and which records it changes.
Illustrative example · fictional bond
A bond record in three working views
Choose Documents, Renewal, or Receipt to see the inputs and record changes for the same fictional bond.
- CaseUsed in this view
- Illustrative matter · B-014
- Related partiesUsed in this view
- Principal and obligee linked
- Invoice term
- Current term ends 30 April 2027
- Invoice recipientUsed in this view
- Designated invoice contact
- Invoice balance
- Open premium awaiting receipt
- Ledger
- No sample receipt entry
This work creates or updates
Prepare the package
- Package jobOwner and processing status
- Generated filesTemplates filled from bond context
- Delivery resultDownload or email, tracked separately
Document work reads the case, related parties, and recipient. Its output is a tracked package with files and a delivery result.
An address has a job to do
A bond connects a case, parties, dates, status, and premium terms. Some of those facts belong to the bond itself. Others belong to related people, firms, or delivery instructions. The distinction becomes practical as soon as somebody asks where an invoice should go.
The implementation stores principal and obligee relationships alongside invoice-recipient information. That lets downstream work ask for the relationship it needs. An address associated with the case is not automatically the invoice address, and a document recipient may be different again.
A redesign should preserve those meanings even when it simplifies the form. Walk a record through package preparation and billing, then imagine changing the recipient. Which outputs should change, and which should stay as they were? This small exercise exposes accidental copying between fields before it becomes an operator’s problem.
A package keeps working after the click
Document generation has a life beyond the request. The application creates a package job with an owner and status, sends it to a queue, and combines templates with the bond context. Results can be downloaded or passed to email delivery. Success, failure, and partial success have different meanings for the person waiting.
Suppose a package contains several documents and one fails. The operator needs to identify that unfinished item without losing the successful output. A generic “done” message would hide the remaining work. The same principle applies to files used as email attachments: they must remain available until the asynchronous send has finished using them.
Advancing the date changes what is owed
The renewal service finds qualifying bonds, derives an invoice term, creates the invoice and ledger entries, resolves recipients, and assigns delivery batches. It also updates anniversary information. Those changes describe one business operation spread across several records.
This is why a scheduler alone cannot explain the renewal design. The term must agree with the invoice, and the recipient must agree with the delivery batch. A renewal run should check that invoice terms do not overlap. Testing should also cover interruption and repeated execution, because an operator needs a clear answer when a batch stops halfway through.
In the atlas, select Renewal and watch the emphasis move to term, recipient and balance. The case still exists, but it is no longer the most important input for this task. Showing that shift helps a team decide which details belong on a renewal screen and which can stay one click away.
Retry the part that failed
Receipt validation and receipt posting are separate operations in the implementation. Posting locks the referenced invoices within a transaction, updates paid and open amounts, and creates ledger entries. Notifications and other follow-on work run after the posting.
The distinction matters when a later message fails. The receipt may already be posted. Repeating the posting operation to fix delivery would repeat the wrong piece of work. A recovery screen needs to preserve the completed financial state while identifying the unfinished message.
Select Receipt in the atlas above. It shows two separate status lines. Post the sample receipt, then retry the failed notification. Only the notification changes on the second action. Queues can deliver a message more than once, and message locks and settlement can fail, so handlers must tolerate repeated delivery.