I’m looking for some guidance on how to build an inspection app.
Questions should be shown or hidden based on parameters within the inspection. More importantly, I need the ability to add, remove, or update questions in the future without having to redesign the app.
Questions can have different answer types, such as:
Yes / No / N/A
Pass / Report
Take an image
Take a note
The ability to add notes and one or more images to any question
After looking around this forum, there seems to be a few possible approaches:
Traditional inspection design
Each question is stored as a separate column in the inspection table.
This is straightforward and intuitive for users, but it becomes difficult to maintain when questions need to be added, removed, or updated.
Relational design
Inspections are stored in a parent table, with inspection questions stored in a child table, where each question is a separate row.
This provides flexibility, but I’m struggling to create an intuitive user experience.
Some options that are suggested:
a. One form per question
Each question is displayed in its own form, and the user moves to the next question after submitting an answer.
This works, but the UX doesn’t feel great especially for longer inspections.
b. Display questions in a table, deck, or card view
Users answer questions using actions associated with each row/card.
c. Use a table in Quick Edit mode
Users answer questions and enter notes directly in the table.
Hybrid approach
Use placeholder question columns in the inspection record and populate them dynamically from a question definition table.
This would provide a more traditional inspection form experience, but it seems like it could be difficult to implement.
I’d be interested to hear how others have implemented inspection apps that require flexible, configurable question sets while keeping it intuitive and efficient
Are you referring to something built on appsheet like the “RedRabbit” Inspection app we use in South Africa. It uses a preconfigured template of tasks for a selected home whereby it has specific checks based on what room your in, like bathroom, lounge, kitchen, etc.
This is possible to build in appsheet however will require a level of relational knowledge in appsheet with looped actions to generate tasks per area..
To add to a good guidance by @Denzil_Snyman , I would tend to lean towards the option 3 you have mentioned
However even with this ( or any other approach) , when you are trying to create a very dynamic inspection form, you may need to consider the flexibility–usability tradeoff that is explained in several blogs if you Google it. Google AI has summarized it as as below
In your approach 3 , you could possibly have a main table which will be used for the inspection checklist and another 1 or 2 tables to have configuration settings of the main table columns such as display names for those questions as users need to see those questions and show_if constraints to decide which columns( from a selection of enum, image , long text etc) in the main table should be shown /hidden in an inspection form.
However even though it sounds straightforward, I am sure it will start throwing unforeseen challenges as you progress.
I meant are you looking for something fully featured like the Red Rabbit app, with all those features built into appsheet or only some of those features.
That’s an interesting paradox and definitely something to think about.
I would have thought AppSheet could easily tackle a dynamic inspection app.
With approach 3, I found it difficult to repeatedly create holding columns for every single question (around 90 in total).
As I understand I would need:
A main inspections table containing holding columns for each question and answer type
A child table for the inspections questions
A separate table containing all questions used to populate the inspection questions table
I’m also wondering whether having so many holding columns would impact app performance.
For now, I’ve gone with Approach 2, which is still quite complex, but less so
I’m curious to know what has worked well for others
With the approach 2 , you have mentioned, it sounds that each question will be in a child table record?
So, is the understanding correct that when user does one inspection there will be one record created in the parent table and as many records as there are questions in the child table? SO if the checklist has 50 questions , there will be 50 child records for one inspection?
One small challenge with such an approach would be that the child table will be thin and tall. By this I mean, I believe there will be very less number of columns but if there are 50 questions in the inspection , with 100 inspections , there will be 5000 rows in the child table. Nothing inherently incorrect in this approach but child table will have very high number of rows.
For each question, I need to make a holding column for a YES/NO answer, a Note answer, an Image answer, with the required constraints and formatting for each, and then repeat that 90 times.
(Maybe that can easily be done with Note Parameters or the CSV upload for column settings you suggested recently?)
Correct
Is it not good for a table to be thin and tall?
This is how i understand a relational database should be structured
Oh okay got it. Yes, then it seems to be a very extensive repetitive task to be carried out 90*3 =270 times. Will each question necessarily have an image and a note?
I’ve gone with approach 2 for now - Relational, and using a multi-form approach where the user cycles through forms for each Related question, which you mention here Dynamically adding fields to a form
If you mean to separate with Page or Section headers, would need to experimant, but not sure how it can be dynamic
90+ questions is total possible question, but a single form would only have a part of those questions, dependant on the inspection type.
Hi the last point where an incomplete questionnaire is possible… Then you would need to build in a Save and Submit status. This will give the user a bit more control and allow them to finish the questionnaire over more than one session. With a larger questionnaire you would want to do this anyway, afterall, not all users can complete a questionnaire in one sitting. This process can also be used in any type of submission form whether it is KPI, Trackers or Incident type applications.
I have an Inspection App for the trucking Industry. It has several levels of permissions and a lot of detail on the inspections, work order for the ones that fail, repaired and finished details in pdf forms. Might be something to look at
My inspection app is very dynamic with over a hundred inspection spots. I solved the time by breaking down the inspection areas into sub pages all with a “ALL PASS” action. So user only focuses on the failed areas with defect drawing and notes. I also added a quicker Complete all pass for entire inspection if it’s verified by an outside source. It’s the only way I could cut the forms down to a manageable size the user could finish quickly. The failures then go to a supervisor for repair approval. Then the supervisor clears the inspection. inspection dates change and a good inspection is logged. With the “ALL PASS” Action any other action can be triggered to fill in data in other forms also.
I’m curious as to how your tables are related.
Are all the inspection points in the parent or in a child table?
And how do you put areas into sub pages?
