Form Submission Storage

[shaunburdick]

Value Statement

As a Veteran

I want to be confident that my submission was received and stored

So that any issues that arise can be handled without their involvement

---

Background Context

• Currently, when a form is submitted, the content of the form is sent to the downstream providers and not retained locally
• This makes any validation or remediation difficult, usually resulting in having to reach out to the submitter to re-submit.
• PSEC has updated guidance such that we can retain form data securely for 60 days once the submission has be accepted by the downstream provider.

Outcome, Success Measure, KPI(S), and Tracking Link

• Securely store form submissions in our database, with additional fields to indicate status and timestamps to show compliance with PSEC requirements

Acceptance Criteria

• [ ] All form submission data is retained in secure table(s) in the database

Designs and Build Notes

• Add here

Enablement team (if needed)

@ member of team

Out of scope

• Status Updates and polling, handled by #84332
• Trimming expired data and longer term storage, handled by #84348

Open questions

• How do we store this securely - Encrypted fields
• Convert an in progress form to a submitted form
  • 1:1 conversion of fields?
  • submitted_at TS
  • status Number
  • last_updated_at TS
  • expires_at TS // 59 days after a success status

Tasks

• [ ] Create an initial PR with DB/Schema updates
• [ ] Create a PR with code changes to store form submissions

Definition of Ready

• [ ] Clear value description
• [ ] Testable acceptance criteria
• [ ] Accessibility added to acceptance criteria
• [ ] Approved designs attached
• [ ] Sample data provided where appropriate
• [ ] Estimated to fit within the sprint
• [ ] Dependencies and blockers linked

Definition of Done

• [ ] Meets acceptance criteria
• [ ] Passed E2E testing (90% coverage)
• [ ] Passed unit testing (90% coverage)
• [ ] Passed integration testing (if applicable)
• [ ] Code reviewed (internal)
• [ ] Submitted to staging
• [ ] Team approved production verification process
• [ ] Reviewed and approved by product and/or design

[dfong-adh]

Notes from discussion with Thomas Blackwell:

Historically, SavedClaim is used to persist form data after submission.

• claims extends SavedClaim as needed https://github.com/department-of-veterans-affairs/vets-api/blob/master/app/models/saved_claim.rb
• model doesn't contain User Information (either submitter or Veteran, can be different)
  • open ticket to improve the model: https://github.com/department-of-veterans-affairs/va.gov-team/issues/84546

Relevant efforts to add additional tracking:

• FormSubmission

  • original intention was to be general purpose, but is only used by Benefits Intake API claims currently

• Form526Submission

  • evolved over time to do a lot, previous discussions regarding refactoring/replacing it but no active plans

• SavedClaim can be sufficient, once User/Vet info is added

Current flow:

• User submits form data

• Saved Claim created from form data in Controller

• InProgressForm deleted

• Sidekiq job uses SavedClaim data to process submission

• SavedClaims are NOT deleted currently, previously had discussions around adding a finite lifespan to them

[dfong-adh]

https://docs.google.com/document/d/16aitrO4_LJ5A1dh9b4KvqYE5C9mu2qMr7mihT3HjSvw/edit