Checklist Item Response - NA Locks out item
* Original + Attribution:
quick question. I can't seem to undo a N/A response in a QAQC checklist. Am i the problem or is that not possible in the system?
PD - NA locks out the checklist item just like when Allow Multiple is not allowed.
zhughes@andersen-const.com
What problem are we solving?
Users are selecting NA by mistake and then not able to undo their selection and therefore cannot complete that checklist item by adding a pass or fail response.
Who are we solving it for?
Andersen users who are using checklists primarily, and secondarily external users doing checklists.
What should happen?
Option 1: make the NA response can be marked and "un-Marked. I think the UI for this would be making the NA button a "toggle" that if pressed once it is NA and then if pressed again it undoes the NA response.
NA does not need to be counted.
This suggestion works for both Safety, Equipment and Quality inspections
How will we know it’s done?
After pressing NA, either of the other two responses can still be selected after pressing NA a second time.
Article(s) to Publish
notes / constraints:
Does the NA response need to be recorded/counted? The suggested fix above makes NA more of a "state" that a item is in and does not record a count for metrics or reports.
Emailed Scott and Chad on 5/6
Log in to comment and vote
Comments1
sfreeman
May 13
•Merged request
•1 vote
QC Checklist "N/A" lockout feature
Currently if “N/A” is selected and not immediately canceled, it locks out all future responses. This has caused issues with some who later realize it was a mistake to click N/A and now need to choose pass/fail.
It would be better if users could still multi-select pass or fail to avoid unintentional irrevocable lockouts. The N/A option was intended only to identify the item as not needed on a particular checklist yet still count as a completed checklist item for the sake of metrics (to show the checklist 100% complete). The current lockout functionality doesn’t gain us anything, but does cause problems, so better to remove it.
Not a critical high-priority issue but something we’ll eventually want to clean up.