Search Applicant Profile

[lmullane]

• As an IAO analyst
• I want to search for an applicant profile
• so that I can match an applicant to an existing applicant profile

Assumptions & Scope What are the assumptions for this story?

Applicant profiles from AXIS will need to be migrated into FOI Mod

Every applicant will require a profile.

Updating an applicant profile will not update the applicant contract details for Closed requests.

When an analyst updates an applicant profile, they will have the option of updating the contact details for other Open requests.

Only IAO analysts can view, search, match, create and update Applicant Profiles.

When an applicant makes a request they will provide their name and contact information. Upon review of the request, the IAO Intake analyst will need to search and check if the applicant previously has made FOI request(s) and if they already have an applicant profile in the system. The IAO Intake analyst will attempt to match the applicant name and contact information manually with existing applicant profiles and contact information already in the system. If there is no match, the Intake analyst will create a new applicant profile for the applicant.

Searches will match the information provided by the applicant when making the request ( First Name; Middle Name; Last Name; Date of Birth; Email; Primary Phone) with the same data fields for applicant profiles already on file.

Closest matches will be displayed at the top of the search results.

Assumption - searches in the Search Applicants profile will be client side and only search existing results to narrow the existing search, rather than start a new search. Confirm with team that is correct?

What is IN scope? Searching for an applicant profile

What is NOT in scope? View and select existing Applicant Profile #4761 Creating a new applicant profile Searching and selecting profiles for On Behalf of requests Adding an additional applicant category profile (i.e. different applicant type) #4763 Updating an existing applicant profile Request History for an applicant Applicant Contact History

Acceptance Criteria

Scenario 1: Search Applicant Profile from Request View

• GIVEN an IAO analyst is on a Request View
• AND an Applicant Profile has not been selected for the request
• WHEN the IAO analyst opens Address and Contact Details
• THEN the 'Search Applicant Profile' link will be there https://jacklyn808742.invisionapp.com/console/share/3W2O64AP5C/663873000

Scenario 2: Click on 'Search Applicant Profile - No match

• GIVEN no Applicant Profile has not been selected for the request
• AND there are no matches
• WHEN the IAO analyst clicks on the 'Search Applicant Profile' link will be there
• THEN the Search Applicants modal will open
• AND there will be no results returned in the search
• AND there will be a search bar and buttons to 'Create New Profile' and 'Cancel'
• And columns for: First Name; Middle Name; Last Name; Date of Birth; Email; Primary Phone https://jacklyn808742.invisionapp.com/console/share/3W2O64AP5C/987389728

Scenario 3: Click on 'Search Applicant Profile - 1 or more matches

• GIVEN no Applicant Profile has not been selected for the request
• AND there are matches
• WHEN the IAO analyst clicks on the 'Search Applicant Profile' link will be there
• THEN the Search Applicants modal will open
• AND the results will be returned in the search
• AND there will be a search bar and buttons to 'Create New Profile' and 'Cancel'
• And columns for: First Name; Middle Name; Last Name; Date of Birth; Email; Primary Phone
• AND these columns will be filled if that data has been captured in the profile
• AND the existing Applicant Profile with the most matches (First Name; Middle Name; Last Name; Date of Birth; Email; Primary Phone) will be displayed at the top of the results
• AND the existing Applicant Profile with the least matches (First Name; Middle Name; Last Name; Date of Birth; Email; Primary Phone) will be displayed at the bottom of the results https://jacklyn808742.invisionapp.com/console/share/3W2O64AP5C/987389727

Scenario 4: Cancel 'Search Applicant Profile' modal

• GIVEN the IAO analyst is on the the Search Applicants modal will open
• WHEN the IAO analyst clicks on the 'Cancel' button
• THEN the modal will close
• AND the IAO analyst will remain on the Request View
• AND no Applicant Profile will be matched with the Request

Scenario 5: Search from 'Search Applicant Profile' modal

• GIVEN the IAO analyst is on the the Search Applicants modal
• https://jacklyn808742.invisionapp.com/console/FOI---Intake-ckpq19frj032r013q6gpm8t1m/clp8r0umw0g3m016n9wh9gobi/play
• WHEN the IAO analyst enters information in the Search Bar (e.g. DOB, Primary Phone, Email, etc.)
• THEN search will update with the refined results

...

Dependencies? What is the impact of this dependency? (If so, link dependency in the ticket, make it visible in a team´s backlog)

Validation Rules? (If yes, list here)

Design @xxx - please link the Design here

Definition of Ready

1. [ ] Is there a well articulated User Story?
2. [ ] Is there Acceptance Criteria that covers all scenarios (happy/sad paths)?
3. [ ] If there is a user interface, is there a design?
4. [ ] Does the user story need user research/validation?
5. [ ] Does this User Story needs stakeholder approval?
6. [ ] Design / Solution accepted by Product Owner
7. [ ] Is this user story small enough to be completed in a Sprint? Should it be split?
8. [ ] Are the dependencies known/ understood? (technical, business, regulatory/policy)
9. [ ] Has the story been estimated?

Definition of Done

1. [ ] Passes developer unit tests
2. [ ] Passes peer code review
3. [ ] If there's a user interface, passes UX assurance
4. [ ] Passes QA of Acceptance Criteria with verification in Dev and Test
5. [ ] Confirm Test cases built and succeeding
6. [ ] No regression test failures
7. [ ] Test coverage acceptable by Product Owner
8. [ ] Ticket ready to be merged to master or story branch
9. [ ] Developer to list Config changes/ Update documents and designs
10. [ ] Can be demoed in Sprint Review
11. [ ] Tagged as part of a Release
12. [ ] Feature flagged if required
13. [ ] Change Management activities done?

[lmullane]

As discussed, On Behalf of will be a different story that will include this AC:

Scenario 2: Search Applicant Profile from Request View

• GIVEN an IAO analyst is on a Request View for a personal request
• AND the request is On Behalf Of
• AND an Applicant Profile has not been selected for On Behalf of person
• WHEN the IAO analyst opens on Behalf Of
• THEN the 'Search Applicant Profile' link will be there https://jacklyn808742.invisionapp.com/console/FOI---Intake-ckpq19frj032r013q6gpm8t1m/ckpx6mtxp0128013ecxv9f3nw/play

[abin-aot]

Search Applicant Profile#4758 - 13/21 ############################################# front end

develop react components for "Search Applicants" - default to max 100(config) - same listing of Queue and client side search - 8

back end

Analyze unique of applicant on Back end - FOIRequestApplicants,FOIRequestApplicantMappings, RequestorTypes - from General, Personal Request - if there is problem, need to fix - 3

Develop Search API - takes the input from request details!- FirstName, LastName, email etc? - 5

[abin-aot]

Based on the analysis on implementing Applicant profiles as per the current design, information. Below are issues development team is trying to highlight to business, @JHarrietha-AOT , and this section is followed by the suggested business rules, which development team is waiting a approval and/or other flows in UX as per @JHarrietha-AOT 's opinion.

Main points around Applicant Profiles, how it is handled in AXIS vs FOI MOD application.

1. In AXIS, Applicant Profiles(Person Name, Contact Info etc.) are Mandatory, and to be created/selected to Open/ run a life cycle of a FOI request. Also, in AXIS Contact Information is tied up with Person On the other hand , on FOI MOD Contact Information is tied with the FOI Request and a Person linked to his/her contact info via a FOI request. This is based on the fact that, a person can create FOI request for his personal and /or official needs and can be fully anonymous while he/she requests a FOI records
2. Because of the above reason, AXIS have a process which involves communication with the applicant that can fair, good amount of information which can almost have realistic data. So till this date, this is not an issue even with AXIS Sync to FOI MOD.
3. Now to coming to the main point, when we start implementing this/current UX design based on our current back end implementation, issue is like we will be listing will have many entries on search results of applicant profiles if the search is NOT following a near to unique identifying business rules. - Find our business rules on the section below.
4. Also, as per the current UX design based on our current back end implementation, Updates to a contact information can mistakenly applied to another request, without FOI analyst knowing where(or what all requests!) this contact information will get updated. This is because on FOI MOD, contact information is tied up with FOI request , not to person whose identity cant be validated - known to all business team, devs etc.

Suggested business Rules, User flow.

1. Search applicant profiles will only list applicant details as per [FirstName and/or LastName] **AND** (Email or Phone) provided EMAIL and/or Phone is NOT null on search filter coming from the request or criteria deciding . Address we can defer when we have confidence on Address data This will reduce the risk of listing users with similar names and mistakenly update contact info.
2. We actually need a Link Contact Information between FOI requests so that the original business problem of updating contact information is for single user to multiple requests will get resolved.
3. Also, this way business know how many requests has a particular user has created.

cc: @lmullane , @m-prodan , @nkan-aot , @richard-aot

[abin-aot]

During the meeting on 04/Dec, these are points we discussed and decided - as per my current understanding

1. The business rule to show up applicant search results will be based on Email by default. Means the requests from applicants who has not provided Email will NOT show up in search even though their FirstName and LastName matches in the system, this is the default behavior.
2. There will be an alternative option on the system, @JHarrietha-AOT brings up to the current wireframes, which will allow FOI Analyst to override the default action of searching profiles/requests by email ,like toggle or something, to allow analyst to search applicant profile by FirstName, LastName of her/his choice which has no emails, phone provided.
3. Dev Team indicated that, this alternative option will bring unrelated applicant profiles on the search results , since there is no unique identification in the system, cant rely just on names. Also, going with the alternative option results and updating it can bring issues, but business is ready to take risk and those results will not be much, as per stats @m-prodan shared(<1%). This situation will be more specific after decommissioning of AXIS though.
4. @nkan-aot has brought up the concern POST linking situation of profiles and indicated that Names will sync'd without any audits left back and inquired what should we do for closed requests, Yes that was a valid concern. @richard-aot , other members suggested a versioning logic for applicant profiles and sys, generated comments for open requests. and closed requests should be left as is. Business indicated this will be a new user story as per priority. @abin-aot , suggested its better to do along with this, but @m-prodan , @lmullane , and other business will decide the priority soon
5. The auto-sync of contact information, based on the email on FOI MOD can be done as an exercise on test-marshal, and demo to the business once we reach a logical end on these tasks if they are OK, then we will make it PROD release step. cc: @abin-aot
6. So from UX/UX design perspective, Team will require UX for toggling default search by Email based business rule and by open ended results of user specific search criteria. Also, additional UX updates to make analyst know while updating Address and/or any contact information on FOI MOD on applicant profile that will be impacting other requests, or any wording of that lines

cc: @JHarrietha-AOT @richard-aot @nkan-aot @lmullane @m-prodan

[nkan-aot]

12/5 standup

• search applicant process should be mandatory before moving request form intake to open (add to AC)
• remove email or address validation from unopened to intake state change
• intake still needs to be able to manually search even if no existing results return
• if an applicant profile has different contact info (email/phone/address) from the request form, highlight the fields in the modal (Jackie to provide color)

@JHarrietha-AOT @abin-aot

[abin-aot]

Applicant Profile Sample.xlsx This is the sample data file team used to explain various Person to multiple contact info scenarios(Work vs Personal), then multiple Personal addresses based on life situation, but same email and/or phone - which derived the above mentioned business rule

[nkan-aot]

12/11/2023 standup

• clarified create new profile modal state not needed. info is the same as on the request form and user can make any necessary edits there before saving. new profile will be automatically created when moved to open state
• save change modal prompt can be skipped if there are no changes to the existing profile
• in applicant contact history, the dates signify when the value was changed (e.g. email: john.doe@gmail.com 12/11/2023 means before 12/11 the email was john.doe@gmail.com, then on 12/11 it was changed to a new value)

[nkan-aot]

12/12/2023 standup

• clarified, update all button on applicant profile must be clicked before saving if there are differences between request and profile
• request form fields related to applicant will not be editable after opening. any changes needed to contact info will be made in the applicant profile modal

[KyEggleston]

From stand-up today - One thing to be mindful of, with our fees process, sometimes users need to place a request 'On Hold', or beyond, without sending the automated fee email. Right now this is done by removing their email, saving, placing request 'On Hold', then adding the email back. This will bypass the automated email being sent. If we remove their ability to edit this field after opening, there may be side effects / issues (they would need to do this in the applicant profile then).

[richard-aot]

Latest code committed to test-marshal-RQ-4758

Endpoints:

• [x] Search (auto/manual)

• [x] Create applicant (with applicant version)

• [x] Save changes to all open requests and applicant(with applicant version)

• [x] Fetch applicant profile based on applicant id (for after request has been opened)

• [x] Fetch request history by applicant ID

• [x] Fetch applicant history

• [x] Create profile hook for intake to open (if create new profile, save info to db if existing profile, pass applicant id along with save request object after open state, disable any edits to applicant information)

• [x] update existing functions to save applicant mapping row with latest applicant version id

[nkan-aot]

my branch for front end is test-marshal-NK-4761

[nkan-aot]

https://miro.com/app/board/uXjVMtjQyiU=/

[richard-aot]

Made a few changes on backend:

1. Added "applicantprofileid" to "FOIRequestApplicants" as the unique identifier for applicant profile
2. Removed version from "FOIRequestApplicants" and "FoiRequestApplicantMappings"
3. New process for updating applicant profile: 3.1 Create a new row in "FOIRequestApplicants" if any of the "FOIRequestApplicants" column values got updated, and link the new row to old ones with "applicantprofileid"; then add new mapping in "FoiRequestApplicantMappings" 3.2 Create a new version in "FOIRequests", "FOIMinistryRequests" if any of the column values in those two tables are updated; then add new mapping in "FoiRequestApplicantMappings"