Mortgage origination: one case type, parallel assessment, and portal safety

I would use one MortgageApplication case type with stages: Intake, Document Verification, Assessment, Decision, and Completion. Assessment contains two parallel processes, Underwriting and Valuation, because completion must wait for both but neither should block the other. The missing-document rework becomes an alternate stage, Missing Documents, that returns to Document Verification when resolved; the declined-valuation rework becomes Valuation Review, which can return to Assessment or proceed to Decision with a condition. The 5-day SLA should be set at stage level: 1 day for document verification, 2 days for assessment, 1 day for decision, and 1 day buffer for completion, with escalation at 80% of each goal. Product-specific fixed, variable, and buy-to-let sections should be circumstanced UI and validation, not three case types. The tradeoff is a more complex flow, but it eliminates the 60% duplicated UI and inconsistent statuses caused by separate case types.

Use a case-level MortgageApplication data class with embedded Applicant, Property, Document, Valuation, and UnderwritingDecision data classes. Product-specific fields belong in a ProductDetails data class linked by product code, not duplicated across case types. Brokers should access a separate broker portal and access group with a read-only case view that uses a filtered data page exposing only status, outstanding documents, and decision outcome. Internal underwriting notes must be stored in an internal-only data class or property with ABAC, not merely hidden on the form. Validation should be declarative: required documents by product and applicant type, and a completeness check before Document Verification can close. Every status change should write to case history with operator, timestamp, old status, new status, and reason. The tradeoff is extra data classes and security testing, but UI hiding alone would fail the audit and the broker-confidentiality requirement.

Build scenario tests around decisions and state transitions, not screens. Cover: valuation completes before underwriting; underwriting completes first; valuation declined and reworked; documents missing twice; broker submits a duplicate application. For each, assert stage entry and exit, parallel process completion, SLA pause and resume, and audit records. Use data transforms to create test data with 18 documents and each product variation. Run the suite at the 1,200-application daily volume in a performance environment to confirm the 5-day SLA is not consumed by queue delay. Include a negative security test where a broker attempts to query an internal underwriting note by URL or data page. This is more test data work than screen-level testing, but it is the only way to catch a broken rework loop before release.