6 — Make Decision (Approve / Reject) — MVP
- Dominant language
- JavaScript
- Stars
- 23
- Forks
- 62
- Avg merge
- 24m
- Merged PRs (30d)
- 1
Description
## Problem (WHY)
Registry analysts need to make a clear decision on a Transfer Upon Death (ToD) filing request.
Today, mailed-in packages create scanning backlogs and delays. Analysts must be able to record an **Approve** or **Reject** digitally so the request can be finalized in the system, with a minimal audit record.
## Epic Description (WHAT — MVP)
Enable an **assigned analyst** to finalize a filing request as either **Approved** or **Rejected**, with a point-in-time capture of what was filed.
- **Value (who benefits & how):**
- Analysts can complete their work without generating mail-ins.
- Operations reduce scanning backlog.
- Filer outcomes (notice, refund, resubmission) are handled in Epic 7.
- **Statuses (nouns):** Approved, Rejected
- **Actions (verbs):** Approve, Reject
- **Outcomes:**
- At decision (Approve or Reject), the filing request is captured “as-is” for historical record.
- Approval flows to Epic 8 (file registration and verification statement).
- Rejection flows to Epic 7 (refunds and notices).
## Goals (outcomes)
- Analysts can finalize decisions in-app with minimal audit.
- Requests are recorded “as-is” at the point of any final decision.
- Mail-in volume and scanning backlog are eliminated.
## Product Personas (in scope)
- **Registry Analyst** — primary staff user deciding outcome.
- **Operations** — benefit from reduced manual scanning of packages.
- **Filer (Qualified Supplier)** — outcome is received, but rules, notices, and refunds are out of scope here (see Epic 7).
## Context
- **Where:** Analyst queue and request detail view.
- **Before:** Filing request is assigned and ready for decision.
- **After:** Status becomes Approved or Rejected; request is recorded and locked; next steps flow to Epic 7 (Reject & Refund) or Epic 8 (File Registration & Notify).
## Design Reference Link (Design-owned)
https://www.figma.com/design/rbiPKU4yAW8PqDDjFRBVKQ/Intake-Queue?node-id=2633-6981
---
## MoSCoW — MVP scope clarity
- **Must (MVP):**
- Record a decision as Approved or Rejected.
- Capture the filing request at point of decision (Approve or Reject).
- Store a minimal audit (who/when/decision).
- **Should:**
- Standard list of rejection reasons (per MHA s.10.1).
- Analyst note entry (staff-only, not visible to filer).
- **Could:**
- Change log history view.
- **Won’t (out of scope for this epic/MVP):**
- Hold status (decision made to exclude).
- Automated refund handling (Epic 7).
- Filer-facing notices or resubmission flows (Epic 7).
- Email of verification statements (Epic 8 policy review needed).
---
## Roles & Triggers
- **Roles:** Registry Analyst (decides); Operations (audit/ops impact).
- **Triggers:** Analyst clicks Approve or Reject on a reviewed request.
---
## Risks & Notes
- Risk: Policy clarity needed on rejection reasons (Epic 7).
- Risk: If request capture fails, decision cannot be fully recorded.
- Note: Mail-ins and scanning backlog eliminated only if all ToD filings are handled digitally.
---
## Dependencies & Systems
- Depends on Epic 5 (status management).
- Depends on Epic 7 (refunds and notices for rejections).
- Depends on Epic 8 (file and verification statement for approvals).
- **Auth/audit guardrails:** Must capture who/when decision was made.
## Dependencies — **BCROS products** (cross-product)
- **PPR:** lien status reference (inbound; not blocking).
- **DRS:** document retention (bidirectional; not blocking).
---
## Compliance & Accessibility (guardrails)
- **FOIPPA:** Staff-only audit; filer sees only outcome in Epic 7.
- **Accessibility:** WCAG 2.2 AA basics (keyboard, visible focus, no colour-only states, AT announcements).
- **Auditability:** Minimum — who, when, decision, captured request.
---
## Post-MVP Candidates
- Editable resubmission of rejected filing by filer → Epic 7.x.
- Enhanced rejection reason catalogue and reporting → Epic 7.x.
- **Epic Parking Lot (revisit later):**
- Analyst workflow templates.
- Automated policy validation.
- **Epic Exclusions (explicitly not doing):**
- Hold status (closed as non-MVP).
- Error handling beyond basic “Unavailable.”
---
## Linked MVP Stories (IDs and titles)
- **6.1 — Approve Filing Request**
- **6.2 — Reject Filing Request (with reasons/notes)**
- **6.3 — Capture Point-in-Time Record of Approved or Rejected Filing Request**
- **6.4 — Capture Audit Log of Approve/Reject Decisions**
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with linked stories 6.1–6.4 and the Analyst queue/request detail context, then review the referenced Figma design. Confirm how Epic 5 status management and the audit and record-capture requirements connect to the workflow. Done means an assigned analyst can approve or reject a request, the decision and point-in-time filing record are retained, and the request is locked.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- full-stack
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100