Automation of (org) status change - Admin Panel

[Benbaillou]

Overview

Project team: PM: @Benbaillou Eng: @entrotech Design: @fancyham UXR: TBD

Type of project: New feature

What User Problem are we solving? Currently, Admin volunteers manually select the organisations that were "Approved" to move them to "Needs Verification". They face the problems of

1. Spending a lot of time to manually check the date of the last approval
2. Making errors by forgetting several organisations if manual check is incorrectly proceeded (ex: some organisations are closed temporarily and needs to be checked once possibly open again)
3. Lowering the quality of the data displayed on the map

What are we building? We are building a feature that automatically changes the status of the organisations from " Approved" to "Needs verification" in the administration panel: When the admin volunteer connects to the admin panel, he can see which organisations need to be updated from " Approved" to "Needs verification" status.

Notes:

• Status changes after
  • 6 months* for all organisations
• Exceptions
  • 12 months* if the organisations was classified as "Permanently closed"
  • 2 months* if the organisations was classified as "Temporarily closed" (*) time TBC with another User Interview

Source of the solutions User interview with Jordan Smith (LA Work) 12 Jan 2022

Questions

1. Should we create 3 steps - Why => because some organisation may include more exceptions that the one above that need a manual check
   1. The organisations is identified as "To be changed to Needs Verification"
   2. The admin volunteers are notified of the status to be changed for the organisations
   3. The admin volunteers can manually confirm the need of status changing or amend the need
2. Should we stretch the automation to "Submitted" status - why => it looks like some organisations have been submitted for verification for more than a year.

What a success looks like - What are our Goals? (TBD)

We want to increase the accuracy of our data A metric could be to measure the number of organisations with a "Approved" status of > or < 6 months A success could be to have x number of organisations with " Approved" status < 6 months

Action Items

• [x] create the issue - PM
• [x] create a mock up to be shared to Dev team - PM
• [x] Discuss the feasibility and the size of the solutions - PM + Eng
• [x] Implement the design of feature in the admin panel - Designer
• [x] Confirm with the users the pertinence of the metrics and the criterias - PM
• [x] Figure out if we can do this in stages
• [x] — Stage 1: Automatically uncheck org's "Confirmed" checkboxes when org state is changed to "needs validation"
• [ ] — Stage 2: Add a calculated "Published" date and display it in the critera filter results, and allow sorting
• [ ] — Stage 3: ? Adding filter presets
• [ ] — Stage 4: ??? Full automation if that makes sense
• [ ] Build and Test the solution - Eng - UX R - PM
• [ ] Launch full product - Eng

Resources/Instructions

Admin Panel => Status highlight

Admin Panel => Date of approval

Organisation details => Closing status

[Benbaillou]

New Jordan's feature Hi @gigicobos, @entrotech @fancyham - Here is the created issue for the Jordan's new feature suggestion => automate the status of the organizations after a certain amount of time. ex: "Approved" => "Needs verification" after 6 months

Please let us know your comments.

[Benbaillou]

@souronion - here is an issue I created. I would love your design comments on this one.

[sei1122]

I made a note on Figma based on Github issue #1150. https://www.figma.com/file/9hPmNSsyaH2VMGNz5mffmI/Suggestions-Admin?node-id=640%3A106

Green color comments are my questions and I’d like to clarify. Especially this section.


Questions

1. Should we create 3 steps - Why => because some organizations may include more exceptions than the one above that need a manual check 1.1 The organisation is identified as "To be changed to Needs Verification" 1.2 The admin volunteers are notified of the status to be changed for the organizations 1.3 The admin volunteers can manually confirm the need for status changing or amend the need

2. Should we stretch the automation to "Submitted" status - why => it looks like some organizations have been submitted for verification for more than a year.

[fancyham]

Hi all — Could you describe Jordan’s exact goals and (if possible) how it might translate into the filter criteria for an organization search?

For example, it’s unclear to me what the ‘exception for 12 month old permanently closed’ rule would do for Jordan and how it translates into an if-then or search criteria statement?

Gotta translate Jordan’s ‘business rules’ into computer logic, so first to understand exactly what he’s trying to do, how he does it now, and then we can see how to translate that into designs and code.

If possible, could you write the rule logic super-explicitly (which will also identify where we have gaps in understanding what he needs)

For example, something like:

0. For each org in database:
1. If org is permanently closed and is < 12+ months, then ignore it. Stop execution. (this ignores things we know are closed)
2. If org is temporarily closed and was approved < 2 months ago, then ignore it. Stop execution. (this lets us check if it’s still closed every 2 months)
3. Automatically change state when (Org == ‘approved’ AND NOT(“permanently closed”) AND NOT(“temporarily closed” AND is has been approved for more than 6 months) to ‘Needs verification” (this makes sure that items get checked every 8 or 9 months… because it usually takes 3 months to get in touch with orgs)

I think that would help us be really specific about what needs to be built.. start with the human rules then we can move to the logic.

Also, something to consider is perhaps a solution would be building a single report table with these three rules as pre-canned filters… Then the admin can press a button to enter the search criteria, get the list of matching orgs, and then batch change them manually to ‘needs verification’?

That might allow us to reuse existing code, rather than building customized stuff where the logic is hidden away inside the program.

[fancyham]

Also, side thought: Please consider putting all our sketches into the main Figma document, so it’s not easily lost and it’s perhaps easier for collaboration?

[fancyham]

What I think I’m reading is:

Jordan needs to: A. Re-validate ‘permanently closed’ places every 12 months or so to make sure they’re still permanently closed B. Re-validate ’temporarily closed’ places every 2 months to see if they’ve reopened C. Re-validate all other places every 6 months to ensure their info is up-to-date.

Is that right?

If that’s the case, I think group A would be an enormous list and I’d suggest double-checking that rule. If a listing is permanently closed, why re-check it?

[sei1122]

Thank you @fancyham. I read your comments and these are great insights. I will move the sketch to the main Figma document.

It would be good to meet with Jordan and learn his goal. So we understand his goal and solve the right problems. I still try to understand the requirements.

[Benbaillou]

Thanks @fancyham for your comments

Your understanding for group A, B and C is correct.  The exceptions for permanently (A) and temporarily (B) closed means that those organisations will not be checked after 6 months, but after 12 and 2 months respectively.

Best would be to schedule a call with Jordan indeed.

Action

• [ ] Set up a call with Jordan to better understand his needs

[fancyham]

From our meeting:

Seems like Jordan may really be looking for a ‘last published date’ which currently doesn’t exist (‘accepted date’ gets erased when org is changed to ‘needs verification’ so is not useful for his purposes).

A ‘last published date’ can be calculated using records in the database from multiple fields. If that field is added to the table and in the criteria/filter dialog, Jordan can sort by that date. (Still probably useful to have shortcuts for things like “older than 12 months” or “older than 2 months” so filter shortcuts/buttons may still be useful)

[sei1122]

@Benbaillou, @fancyham, @entrotech Created 3 key screens based on the last meeting discussion. https://www.figma.com/file/D3oq9QOXl0rFkwrEUJbABs/FOLA-Design-System?node-id=4525%3A8835

Questions

• Who is currently publishing the site and what is the process? Is there a version of the timestamps?
• Closed & temporary closed places are not on the Food Oasis website? If so, is the sorting still work from the published date?

[sei1122]

Key screens are updated. https://www.figma.com/file/D3oq9QOXl0rFkwrEUJbABs/FOLA-Design-System?node-id=4675%3A8847

I need to talk to Jordan to get feedback.

[fancyham]

Adding screenshot of design for easy reference:

[sei1122]

@fancyham, Thanks! I will attach screenshots next time!

[sei1122]

Script for Feedback Session with Jordan https://docs.google.com/document/d/1509JrScM7dA-QhCEWiL0X1Ds-mAjzzV6H-3BZmgfXmQ/edit?usp=sharing

[sei1122]

Feedback session on March 11, 2022.

Attendees: Jordan, Seiko, John, Bryan This session is recorded: https://drive.google.com/file/d/1-2-wv_7WIRMIA1D-T4h4UYelb_2FC5bd/view?usp=sharing

What is Jordan really looking for? He wants full automation. When the time comes, the Approved status changes to Needs verification automatically.

Clarify how often status is verified

• 6 months for opening organizations.
• 12 months if the organization was “Permanently closed”’ ( 1 time only )
• 3 months if the organization was classified as “Temporary closed” ( every 3 months until the status changes either opening or permanently closed )

Jordan’s current workflow Video: around 12:30 https://drive.google.com/file/d/1-2-wv_7WIRMIA1D-T4h4UYelb_2FC5bd/view?usp=sharing Figma: https://www.figma.com/file/D3oq9QOXl0rFkwrEUJbABs/FOLA-Design-System?node-id=4819%3A8996

1. Go to Admin panel
2. Sort by Approved date
3. Select organizations that have old approved dates
4. Click the Needs Verification button in the top left
5. Click the OK button to confirm the status
6. Click the Criteria button
7. Use the dropdown menu to select Needs Verification then click search
8. Click the Modified tab to sort the most recently modified organizations to the top
9. Click on an organization that you modified the status in step 4
10. Uncheck all 5 confirmed checkboxes on the Identification tab
11. Save progress
12. Click on the Business hours tab then uncheck confirmed buttons
13. Save progress
14. Click on the More details tab then uncheck confirmed buttons
15. Save progress
16. Back to admin panel and make sure the organization's critical % is now 0% NOTE: if it is not 0% you have missed a checkbox

Post meeting with Bryan, John and Seiko

We are going to build this in stages instead of going to full automation right away. We have some concerns about full automation. For example, it is difficult for a user to undo a mistaken action. Also, the admin user doesn’t have much control.

Why are we going to build this automation in stages?

• Simpler design, easier to build and test.
• Each stage we will have a chance to test and iterate while going towards full automation.
• Each smaller step can be impactful sooner and improve the current admin's workflow while full automation would take time.

Stages:

1. Confirmed checks should be automatically unchecked when changing the status from Approved to Needs verification.
2. Add a Published Date
3. Add a control panel for admin users. Ideas for the control panel:

• Preset buttons for quick search criteria.
  • Open & 6 months since published
  • Temporary closed & 3 months since updated
  • Permanently closed & 12 months since updated
• Choose the top N oldest number of organizations by approved date not just organizations 6 months or older. Jordan sometimes runs out of organizations to verify and this approach may help.
• Admin volunteers can change the repeat rate of the verification. E.g. every 6 months opening organizations -> every 8 months
• It may be good to have an option to turn on and turn off the feature.

4. Full Automation

[sei1122]

I took screenshots from the video and made Jordan's current workflow. We can save around 17 clicks for one organization by automating uncheck confirmed checkeboxes. https://www.figma.com/file/D3oq9QOXl0rFkwrEUJbABs/FOLA-Design-System?node-id=4819%3A899

[sei1122]

Meeting Note: March 17, 2022 @entrotech, @sei1122, @fancyham

Next Steps: Dev team starts development: Confirmed checks should be automatically unchecked when changing the status from Approved to Needs verification.

Seiko: start designing control panel for volunteer admin

[sei1122]

Meeting note: April 20, 2022 Preset filter and the edit screen designs

https://www.figma.com/file/D3oq9QOXl0rFkwrEUJbABs/FOLA-Design-System?node-id=5110%3A907 2

[sei1122]

Preset filter edit screen design iterations. @fancyham

https://www.figma.com/file/D3oq9QOXl0rFkwrEUJbABs/FOLA-Design-System?node-id=5136%3A9285

[entrotech]

Created Issue #1228 to implement the "Stage 1" step in the issue description above.

[sei1122]

Meeting note July 28: When we finish developing the published date column on the Verification admin table, We schedule a meeting with Jordan. We'd like to ask

• How does he think the Auto uncheck confirm feature (this has already been implemented and published)
• What does he think about adding filter options on Criteria Search?

[rylantalerico]

@entrotech Ready for dev tasks!

[staceyrebekahscott]

Added John as assignee as this is ready for Dev work.

[staceyrebekahscott]

@entrotech Following up on this, as it was approved for dev tasks by Rylan 3 weeks ago. Is this in your pipeline to proceed on with the dev team?

[entrotech]

Created Issues #1272 #1273, #1373 to get started on development.