Update FEATURES_UPDATE and NEXT_STEPS to reflect current state
FEATURES_UPDATE.md: rewrote from scratch — was a stub from February describing only docs-writing activity. Now documents all implemented features: CLM generation stack, account/letter config metadata, eSignature browsing layer, infrastructure, and what is not yet built. NEXT_STEPS_DOCGEN.md: expanded from CLM-launch-only scope to cover the full Phase 2 eSignature envelope creation plan (tracking fields, createEnvelope approaches, persistence, UI button) and Phase 3 additional letter types. CURRENT_STATUS.md: fix two remaining absolute /home/paulh/... doc links. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
paulh
parent
546ffd7dcf
commit
c49d127db1
|
|
@ -47,9 +47,9 @@ The project is now a working Salesforce proof of concept for both DocuSign CLM d
|
||||||
|
|
||||||
## Current source of truth
|
## Current source of truth
|
||||||
- product-level summary:
|
- product-level summary:
|
||||||
- [PRODUCT_SPEC.md](/home/paulh/.openclaw/workspace/projects/salesforce-appraiser-review-letter/docs/PRODUCT_SPEC.md)
|
- [PRODUCT_SPEC.md](./PRODUCT_SPEC.md)
|
||||||
- setup and environment notes:
|
- setup and environment notes:
|
||||||
- [SALESFORCE_SETUP.md](/home/paulh/.openclaw/workspace/projects/salesforce-appraiser-review-letter/docs/SALESFORCE_SETUP.md)
|
- [SALESFORCE_SETUP.md](./SALESFORCE_SETUP.md)
|
||||||
- implementation:
|
- implementation:
|
||||||
- Apex classes and LWCs in `force-app/main/default`
|
- Apex classes and LWCs in `force-app/main/default`
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,19 +1,64 @@
|
||||||
# Features / Change Log — Appraiser Review Letter
|
# Features / Change Log — Appraiser Review Letter
|
||||||
|
|
||||||
## Progress Summary
|
## Current state (2026-04-09)
|
||||||
- CLM_TEMPLATE_GUIDE.md: Initial merge/tag logic and edge cases outlined
|
|
||||||
- requirements.md and design.md: Created and populated with core requirements and structure
|
The project is a working Salesforce proof of concept covering both DocuSign CLM
|
||||||
- README.md: Project intro and architecture brief
|
document generation and eSignature API exploration. All items below are deployed
|
||||||
- DEPLOYMENT_AND_TESTING.md: Deployment steps and testing workflow drafted
|
and functional.
|
||||||
|
|
||||||
|
### CLM document generation
|
||||||
|
- `Appraiser_Case__c` with full appraiser identity, address, FHA case number,
|
||||||
|
letter sent date, and CLM tracking fields
|
||||||
|
- `Appraiser_Case_Deficiency__c` child object with number, description,
|
||||||
|
resolution, reference, and blank-record validation
|
||||||
|
- `AppraiserCasePayloadBuilder` — transforms case + deficiencies into CLM merge
|
||||||
|
payload (JSON and XML)
|
||||||
|
- `CLMDocGenCallout` — XML merge task submission, task status polling, document
|
||||||
|
download via separate download credential
|
||||||
|
- `CLMAdminService` — UI orchestration layer: account/letter settings, generate,
|
||||||
|
poll, attach, folder browse; persists all CLM results back to the case
|
||||||
|
- `clmDocGenWorkbench` LWC quick action — full generate → poll → attach workflow
|
||||||
|
with folder browsing, template selection, and letter type selection
|
||||||
|
- `clmRequestPreview` LWC — developer/debug view of the XML merge payload and
|
||||||
|
request body for a given case
|
||||||
|
|
||||||
|
### Account-based configuration
|
||||||
|
- `CLM_Account_Setting__mdt` — per-account CLM and eSignature configuration
|
||||||
|
(named credentials, folder hrefs, template hrefs, account IDs)
|
||||||
|
- `CLM_Letter_Definition__mdt` — per-account letter type definitions with
|
||||||
|
optional folder/template overrides; fallback chain to account defaults
|
||||||
|
- Three active accounts: DTC_CLM_Demo (UAT), DTC_IAM_Enterprise (S1),
|
||||||
|
DTC_HUD_Demo (UAT)
|
||||||
|
- Four letter types seeded (APPRAISER_REVIEW fully configured; NOD, Education,
|
||||||
|
Intent to Remove defined but CLM templates not yet built)
|
||||||
|
|
||||||
|
### eSignature API exploration
|
||||||
|
- `DocusignESignatureService` — read-only eSignature API calls: login info,
|
||||||
|
user info, account list, templates, envelopes
|
||||||
|
- `docusignEsignWorkbench` LWC — browse accounts, templates, and recent
|
||||||
|
envelopes from the Salesforce record page
|
||||||
|
- `AcctDemo_NamedCreds` + `DocusignJWT` external credential — JWT bearer auth
|
||||||
|
for eSignature account server calls
|
||||||
|
- `Esignature_Demo_NamedCreds` — REST API calls (templates, envelopes)
|
||||||
|
|
||||||
|
### Infrastructure
|
||||||
|
- Named credentials: CLMuatNamedCreds, CLMs1NamedCreds, CLMuatDownload,
|
||||||
|
CLMs1Download, Esignature_Demo_NamedCreds, AcctDemo_NamedCreds
|
||||||
|
- External credential: DocusignJWT (JWT bearer, RS256, account-d.docusign.com)
|
||||||
|
- Permission sets: Appraiser_Case_Admin, Appraiser_Case_Access
|
||||||
|
- Record page, quick action, custom app, tabs, layouts
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Next Steps
|
## What is not yet built
|
||||||
- Expand template engine features (nested conditionals, richer formatting)
|
|
||||||
- Clarify integration specifics with Salesforce CLM
|
- Envelope creation and send workflow (eSignature)
|
||||||
- Add more actionable questions in doc footers
|
- Envelope/template detail drill-down UI
|
||||||
|
- eSignature activity tracking on `Appraiser_Case__c` (envelope ID, status,
|
||||||
|
sent/completed dates)
|
||||||
|
- CLM template build-out for NOD, Education, and Intent to Remove letter types
|
||||||
|
- Admin UI for configuration (currently managed through Salesforce Setup)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
_Last updated: 2026-02-26 13:28 PM_
|
_Last updated: 2026-04-09_
|
||||||
_Work in progress: Feature/requirement expansion and blockages/questions to be listed here._
|
|
||||||
|
|
|
||||||
|
|
@ -1,27 +1,91 @@
|
||||||
# Next Steps — DocuSign CLM Launch Path
|
# Next Steps
|
||||||
|
|
||||||
I added a placeholder Quick Action metadata file so there is an explicit place in the project for the document generation launch pattern.
|
## What is done
|
||||||
|
|
||||||
## Reality check
|
The CLM document generation workflow is fully implemented:
|
||||||
|
- `clmDocGenWorkbench` quick action — account selection, letter type selection,
|
||||||
|
folder browsing, template selection, generate, poll, attach
|
||||||
|
- `CLMAdminService` + `CLMDocGenCallout` — full Apex service layer
|
||||||
|
- All CLM tracking fields persisted back to `Appraiser_Case__c`
|
||||||
|
|
||||||
DocuSign CLM launch configuration varies by package and org setup. Because of that, the action in this repo is a scaffold/placeholder, not a guaranteed final production action.
|
The eSignature browsing layer is implemented (read-only):
|
||||||
|
- `docusignEsignWorkbench` — accounts, templates, envelopes
|
||||||
|
- `DocusignESignatureService` — login info, user info, account list, templates,
|
||||||
|
envelopes
|
||||||
|
|
||||||
## Implementation status
|
---
|
||||||
|
|
||||||
### Option B — LWC / Quick action ✅ Complete
|
## Phase 2 — eSignature envelope creation
|
||||||
The `clmDocGenWorkbench` LWC quick action is fully implemented and deployed. It uses `CLMAdminService` and `CLMDocGenCallout` for the full generate → poll → attach workflow.
|
|
||||||
|
|
||||||
### Option A — Screen Flow (alternative entry point)
|
The natural next step is connecting the two halves: after a CLM document is
|
||||||
If a Flow-based launch is preferred (e.g., to add approval steps or prefill inputs):
|
generated and attached to the case, send it for signature.
|
||||||
- Create a Screen Flow that accepts `recordId`
|
|
||||||
- Call `CLMAdminService.generateDocument()` via an Apex Action step, passing account code, template href, destination folder href, and destination filename
|
|
||||||
- Show task status by polling `CLMAdminService.getTaskStatus()`
|
|
||||||
|
|
||||||
### Option C — Button / URL hack
|
### 1. Add eSignature tracking fields to `Appraiser_Case__c`
|
||||||
Not recommended.
|
|
||||||
|
|
||||||
## What to confirm before extending to additional letter types
|
Fields needed on the case to track the envelope lifecycle:
|
||||||
|
- `ESignature_Envelope_Id__c` (Text)
|
||||||
|
- `ESignature_Envelope_Status__c` (Text — Created / Sent / Delivered / Completed / Voided)
|
||||||
|
- `ESignature_Sent_At__c` (DateTime)
|
||||||
|
- `ESignature_Completed_At__c` (DateTime)
|
||||||
|
- `ESignature_Envelope_Url__c` (URL — link to envelope in DocuSign)
|
||||||
|
|
||||||
1. CLM template hrefs for NOD, Education, and Intent to Remove letters
|
### 2. Add `createEnvelope()` to `DocusignESignatureService`
|
||||||
2. Whether those letters use the same destination folder structure or need separate `CLM_Letter_Definition__mdt` folder overrides
|
|
||||||
3. Any differences in deficiency display or field set for those letter types
|
Two approaches depending on workflow preference:
|
||||||
|
|
||||||
|
**Option A — Envelope from template**
|
||||||
|
Use a pre-built eSignature template. Recipients and document are defined in the
|
||||||
|
template; Salesforce passes merge data (tabs) at send time.
|
||||||
|
```apex
|
||||||
|
// POST /v2.1/accounts/{accountId}/envelopes
|
||||||
|
// body: { templateId, templateRoles: [{ email, name, roleName }], status: 'sent' }
|
||||||
|
```
|
||||||
|
|
||||||
|
**Option B — Envelope from uploaded document**
|
||||||
|
Use the CLM-generated document (already attached to the case as a
|
||||||
|
ContentVersion). Download the blob and POST it directly as an envelope document.
|
||||||
|
```apex
|
||||||
|
// POST /v2.1/accounts/{accountId}/envelopes
|
||||||
|
// body: { documents: [{ documentBase64, name, fileExtension, documentId }],
|
||||||
|
// recipients: { signers: [...] }, status: 'sent' }
|
||||||
|
```
|
||||||
|
|
||||||
|
Option A is simpler if a matching eSignature template exists.
|
||||||
|
Option B gives more control but requires managing recipient configuration in code.
|
||||||
|
|
||||||
|
### 3. Persist envelope result to `Appraiser_Case__c`
|
||||||
|
|
||||||
|
On success, write the envelope ID, status, and sent timestamp back to the case
|
||||||
|
(same pattern as `CLMAdminService.persistDocGenResult`).
|
||||||
|
|
||||||
|
### 4. Add send action to `clmDocGenWorkbench`
|
||||||
|
|
||||||
|
After "Attach Generated Document" succeeds, enable a "Send for Signature" button
|
||||||
|
that calls the new `createEnvelope()` method. Show envelope status alongside
|
||||||
|
the existing task status display.
|
||||||
|
|
||||||
|
### 5. Add envelope status polling (optional)
|
||||||
|
|
||||||
|
Mirror the CLM task status pattern: a "Check Signature Status" button that calls
|
||||||
|
`GET /v2.1/accounts/{accountId}/envelopes/{envelopeId}` and updates the case.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Phase 3 — Additional letter types
|
||||||
|
|
||||||
|
Three letter types are defined in `CLM_Letter_Definition__mdt` but have no CLM
|
||||||
|
templates yet:
|
||||||
|
- `NOD_LETTER` — Notice of Deficiency
|
||||||
|
- `EDUCATION_LETTER` — Education correspondence
|
||||||
|
- `INTENT_TO_REMOVE_LETTER` — Intent to Remove notification
|
||||||
|
|
||||||
|
For each:
|
||||||
|
1. Build the CLM template `.docx` and upload to the CLM account
|
||||||
|
2. Update the `Default_Template_Document_Href__c` in the corresponding
|
||||||
|
`CLM_Letter_Definition__mdt` records
|
||||||
|
3. Confirm whether deficiency display or field set differs from the appraiser
|
||||||
|
review letter (if so, extend `AppraiserCasePayloadBuilder`)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
_Last updated: 2026-04-09_
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue