# Requirements — Appraiser Review Letter Platform

This document now serves as a short requirements summary. The full current product specification is in [PRODUCT_SPEC.md](/home/paulh/.openclaw/workspace/projects/salesforce-appraiser-review-letter/docs/PRODUCT_SPEC.md).

## Functional requirements
- A user can generate an appraiser review letter from an `Appraiser_Case__c` record in Salesforce.
- The generated CLM document merges property data and a repeating deficiency list from Salesforce.
- The user can choose a configured CLM account instead of hardcoding environment-specific values.
- The user can browse CLM templates and destination folders in the UI.
- The user can track CLM task status and attach the generated document back to the case.
- The system can browse core eSignature account data, templates, and envelopes for configured accounts.

## Non-functional requirements
- Account-specific configuration must be deployable and maintainable through Salesforce metadata.
- The solution must support both UAT and S1 CLM/eSignature account setups.
- The primary document-generation path must be test-covered in Apex.
- The solution should remain usable as a proof-of-concept platform for additional DocuSign API work.

## Canonical requirements decisions
- Canonical parent object: `Appraiser_Case__c`
- Canonical child deficiency object: `Appraiser_Case_Deficiency__c`
- Canonical CLM generation path: XML merge via `documentxmlmergetasks`
- Canonical config source: `CLM_Account_Setting__mdt`
- Structured property address fields are the source of truth; `Property_Address__c` is legacy

## Current open product questions
- What should the first production-grade eSignature workflow be: template detail, envelope detail, draft creation, or send?
- Should eSignature activity be persisted back onto `Appraiser_Case__c` the way CLM activity is?
- Should the eSignature workbench remain a testing/admin surface or evolve into a business-user workflow?

---
Last updated: 2026-04-09