/ VoteCal Statewide Voter Registration System Project
Use Case: UC03.43.01 / Undo Accepted Duplicate Voter Match Case through VoteCal

Use Case: UC03.43.01 / Undo Accepted Duplicate Voter Match Case[IV&V1] through VoteCal

Attribute / Details
System Requirements: / S1.3.1 VoteCal must provide SOS administrators with the ability to, with respect to any voter:
  • Update basic voter registration data (e.g., name, street address, mailing address, phone numbers, partisan affiliation, date of birth, etc.);
  • Modify voter status;
  • Merge and unmerge potential duplicate voter records;
  • Add comments to a voter record; and
  • Add entries to voter activity history, such as contacts with the voter.
S2.1 VoteCal must provide functionality that enables authorized county and state users to add new registered voters and to update data associated with existing registered voters.
S9.3 Should it subsequently be determined that registration records were incorrectly merged into a single record, VoteCal must permanently provide SOS Administrators and authorized county users with the capability to “un-merge” such records into separate registration records and appropriately apply UIDs to the voters.
S10.10 VoteCal must provide the capability for authorized county users to cancel match-based transactions that have been automatically applied, or to not accept such automatic transactions. In such instances, VoteCal must reverse any changes that have been applied to the record and handle the transaction as a confirmed non-match for that process.
Description: / The purpose of this use case is to reverse AaDuplicate VoterMatch Case that was previously accepted is reversed, through VoteCal.[BMc2]
Actors: / SOS User[IV&V3], County User
Trigger: / A previously accepted Duplicate Voter Record Match Case is determined to have been accepted erroneously and must now be reversed.
System: / VoteCalApplication (This can be alternatively accessed through the local EMS per its integration with the EMS Integration Web Service).
Preconditions: /
  • A voter record was previously merged as the result of an accepted Duplicate Voter Match Case.
  • All global preconditions apply.

Post conditions: /
  • The status of the applicable Duplicate VoterMatch Caseis changed to Rejected.
  • Changes applied to the voter records as a result of the match case being accepted are undone.
  • Items are added to the EMS Message Queue to indicate to the local EMS to make updates accordingly.
  • All global post conditions apply.

Normal Flow: /
  1. User accesses the Work Item Management area of the application.
  2. System presents UI999.XX Work Item Summary Screen. This screen displays the various types of work items that exist with the corresponding count of open items for each type.
  3. User elects to work with the Accepted Duplicate Voter Match Case work item type.
  4. System presents UI999.XX Duplicate Voter Match Case List. This screen displays page 1 of a list of currently “Accepted” [BMc4]Duplicate Voter Record Match Cases, regardless of whether the match case was accepted manually or automatically. Each column of the list is sortable. Fields appear at the top of the screen that allow searching/filtering on the columns to narrow the number of cases displayed.
  5. User selects a case from the list for review.
  6. System presents UI999.XX Duplicate Voter Match Case Detail. This screen displays the record details of each of the voter records in side-by-side panels to that the user can easily inspect them visually. Each voter’s detail panel provides a link to drill down to see the full detail of that voter record. A buttons is present to allow the user to undo the acceptance of the match case.
    *NOTE: This screen can be alternatively accessed from the Voter Detail Screen by selecting the Accepted Duplicate Record Match Case voter activity item.[BMc5]
  7. User issues the Undo command.
  8. System confirms the user wants to proceed with the action.
  9. User chooses to proceed.
  10. System takes the following action:
  11. A Duplicate Record Match Undone Voter Activity item is appended to the Active (Surviving) Voter Record.
  12. The child records are dissociateddisassociated from the voter record by deleting the copied child records and “unhiding” the original child records. The voter record is re-validated in its new state to determine if the First Time Federal Voter flag needs to be set.
10.1.This record is dissociated from all history and activity records that were merged in from the duplicate record. The voter record is re-validated in its new state to determine if the First Time Federal Voter flag needs to be set.
10.2.10.3.A message is added to the EMS Message Queue for the County that owns the Active Record indicating that a local update must be applied.
10.3.10.4.The duplicate (Cancelled) Voter Record is “unhidden” androlled back to the version it was on prior to the application of the match case. A Duplicate Record Match Undone Voter Activity item is appended to thisrecord.
10.4.10.5.A message is added to the EMS Message Queue for the County that owns the restored record indicating that a local update must be applied. This may involve other processes for the voter record in the EMS.
10.5.10.6.The match case is set to the Rejected state.
Alternative Flows: / N/A
Exceptions: / N/A
Includes: / N/A
Frequency of Use: / TBD
Business Rules: / N/A
Assumptions: / N/A
Notes and Issues: / N/A

Revision History

Date / Document
Version / Document Revision
Description / Revision Author
01/25/2010 / 0.1 / Initial Draft / Chad Hoffman
01/26/2010 / 0.2 / Revision / Scott Hilkert
01/26/2010 / 1.0 / Minor edits and release to client. / Maureen Lyon
02/03/2010 / 1.1 / Incorporate Client Feedback / Chad Hoffman
02/03/2010 / 1.2 / Document Revisions / Chad Hoffman
02/04/2010 / 1.3 / Document Revisions / Chad Hoffman
02/04/2010 / 1.4 / Submit to client for review / Maureen Lyon
02/12/2010 / 1.5 / Accept Changes / Chad Hoffman
03/19/2010 / 1.6 / Incorporate Client Feedback from Discovery Sessions / Kimanh Nguyen / Kalyn Farris
03/24/2010 / 1.7 / QA and Release to Client for Review / Don Westfall
mm/dd/yyyymm/dd/yyyy / 1.x2.0 / Update with client feedbackSubmit to Client for Review / Only if needed{Name}
mm/dd/yyyymm/dd/yyyy / 2.02.1 / Submit to Client for Review (Deliverable 2.3 Draft)Incorporate Client Feedback / {Name}{Name}
mm/dd/yyyymm/dd/yyyy / 2.13.0 / Incorporate Client FeedbackSubmit to Client for Approval / {Name}{Name}
mm/dd/yyyy / 2.2 / Submit to Client for Approval (Deliverable 2.3 Final) / {Name}
02/1203/2619/201004/01/2010
Version: 1.765 / Page 1

[IV&V1]Paula: No comments for this use case.

[BMc2]Not clear whether you mean ‘do the reversal through VoteCal’, or that only duplicates ‘previously accepted in VoteCal’ can be reversed. (The latter would be incorrect.) Please reword to clarify ambiguity.

[IV&V3]Art: It was my understanding that SOS users did not have the option to reverse a previously accepted duplicate voter match. If I am correct, they should not be an actor.

[BMc4]I am concerned with term ‘Currently accepted’. As you can imagine, the list of accepted match cases will grow HUGE very quickly. On the other hand, most duplicate match cases that need to be undone will not be discovered until an extended period of time after the match was made (such as the next election two years or more later!)

[BMc5]I’d wager that in reality this will be the method used the vast majority of times. Perhaps this should be presented as the primary approach.