Building inspection app

Hello Glide Apps Community,

I’m in the process of creating a building inspection app, and I’m looking for advice on how to structure my tables effectively for different navigation items.

The key components of my app include:

  1. list of projects added by the user (inspections can also be assigned to)
  2. completed inspections that can be reviewed and edited if needed
  3. template checklists with items included in a form component

What would be the best approach to organize my tables to ensure a smooth user experience and efficient data management within Glide Apps?

I’m mainly having trouble with the template checklists, as there are currently 26 stages (checklist) and some contain close to 50 items to check.

Your insights and suggestions would be greatly appreciated!

Thank you in advance!

Hi Blake, welcome to the forums. You’ll probably get a few good responses here but I’ll do my best to chime in.

With the checklists, you’re saying there are 26 stages, with up to 50 checklist items per stage?

Everything is basically lists of lists, in the data. Maybe we call the stages tasks, so we have a Tasks table. Perhaps things like Flooring, Plumbing, Lighting. And the checklist items we can put in an Items table.

This is fairly simple if these were one time use tasks and items, like in a non-recurring to do list. Add items, mark complete.

But for templates, I’m assuming people are adding projects or inspections, that consist of these same tasks and to do items. I’d rather not write rows for all of these things, for every project.

Rather, we create a new project/inspection (a new row in a Projects table), and we choose which standard tasks we want to be done on this project. You could use a choice component with multiple select on. Then it’s easy to list those tasks on the project.

For the Items though, if we use a checklist collection on the Tasks details screen, checking those is checking the Items themselves, on the Items table… and not instances of those items that are associated to the given project. Instead of the checklist collection then, we need an action that either writes the item completed to the projects table, or we need to write to the Item table that that item was done for that given project. The later might be easier because actions clicking on the Item are expecting to write to the Items data. You could add or remove the Project ID to a column that lists Projects IDs for which the item has been completed. To have access to the Project ID, I’d suggest an action that writes project ID to a column in the users table, called “Project in View” anytime a project details screen is opened.

The other option is writing the item completed, to the projects row. In the users table I’d lookup the completed items for the project in view. And in the items table I’d have an add and remove element column, adding and removing the Item ID. Then the check/uncheck action of clicking the item on the list, goes to an action that either adds or removes the item by printing either the add or remove set, to the projects table.

Either of these two methods I believe should work. Writing to the projects table is safer IMO, because it seems less likely for multiple users to be checking items off the same project at the same time, than users checking off the same item from different projects at the same time. And with this method, if two users are writing to the same project or item at the same time, one users action could undo that of another.

I suppose another option to avoid that, could be that every action is writing a row to an actions table… that might be the easiest to set up actually. Sounds like with the number of your items, you’d definitely want to use a big table for that.

Hopefully this helped give you some ideas. I’m curious to hear others opinions on this as well!

1 Like