I'm trying to create an app for product owners to go through the checklist with a set of questions before releasing the product.
A Product form will have a checklist type and there will be a set of questions associated to that checklist.
Product table: User enter product details here and the form will have the checklist type to choose from the task table. Pipeline will run and import questions related to that checklist type
Checklist table - Checklist name, type, checklist owner.(we have 37 different checklist)
Questions table- same Question can be used in multiple checklist(all the questions used in the checklist is added to this repository)
Sub questions table- will have sub question details.
Template table - To show checklist , questions and sub questions associated with it
Task table- Pipeline will run and import questions related to that checklist type from Join table to task tale
Please help me with the below questions:
How to set dependency between questions ( questions might have 1 upstream or downstream dependency with another question.)
How to setup sub questions related to questions
Each question has different input types like multiple choice, link, text . How to achieve this
------------------------------ Hema ------------------------------
Best answer by ChayceDuncan
Predecessors don't necessarily have to have a start and end - those are useful if you picture a gantt but a predecessor is just a requirement that something else be done before you can start, thus it's independent of any specific date. If you use native QB predecessor fields then what they will do it provide a work date field that acts as the date that item is unlocked - which is a date but for your concerns you're just trying to make sure that prior items are done - which is just the presence of a date in that case. If you're choosing to use the key field approve - then same logic more or less applies - you don't need a date, you can instead just look at the status of your predecessor tasks to determine if you're able to commence.
Possibly - this would need a form entry though. In your question setup you could make a 'Sub Question Label' - that when you display it in your task you have a rich-text field display like the form label so it feels unique to each question and then have them provide an input.
Grid edit will most likely stray you further way from the subquestion component. Grid Edit is a fixed report of columns so you can't adjust the input or entry based on the question. I might suggest that you leverage buttons and the ability for OpenAsPopup and data-refresh so that your users click a question - answer it in a pop up and save - then close the window back down and refresh or open the next question. With the workflow you've described, Grid Edit will be a little too limiting unless you pare back the dynamic input style you've described.
I've personally done this lot's of different ways so I'll try do my best to explain how I might look at it.
Can you confirm - the Question and Sub-Questions table are children to your checklist correct? So when you pick the checklist on the Product, you are then planning on creating tasks for each question? What then it the Template Table for?
To try and answer your questions though with what information I have:
1. This is the trickiest. One option is to rethink the idea of the 'primary key' on your table when you create a task. So for example - lets say you Product Record ID#1, and you're copying over Question #5. Your would set the key field of the Task to be '1-5' as one example, the join between Project and Question as the string. The idea behind it then - is that if you can build the idea of predecessors using that logic where all of your tasks tie back to the original question. So - if you know that Question 5 is the predecessor to question 6 - then you know in your 'Tasks' you're looking for the Task record with key '1-6'. It's a backend way to never stray very far from the original template. The drawback to this is that its typically harder to make on demand items. This key structure revolves around the initial load so manually creating new ones is a little tricky.
The other option I've seen work well is to use Quickbase predecessor fields in your template and then when you create your tasks - to user formula queries to update what the 'task' equivalents are. The native predecessor field will tie a record to one or more Record IDs in that same table. When you create a task from a question record that has a predecessor - you can reconstruct a formula query that looks at the lookup predecessor value from the question - and splits out to search for all the tasks where the Related Question is listed in the predecessor. You can then make an update to the task to merge what the new Task predecessors would be. This is easier than the first suggestion but doesn't always provide the best visibility depending on your opinion of QB predecessor fields.
2. Are you asking how to create sub-questions against a product similar to how you have Questions/Sub-Questions? If you're using the checklist/question/sub-question as a template that you then pick on a Product to do a Product/Task structure - then you need to mirror the idea of SubTasks underneath tasks. When using this kind of template model in QB you need to match the structure where ever you're loading this template to
3. This will depend on how your users are completing this items. If they're editing through a 'form' - then the easiest is to have a 'entry type' field in the question that you fill out with Number, text etc. Then on the form, you use a form rule on the task where you show/hide the right field type based on the template type that you set. This works for simple types like numbers and basic text, when you get into dropdown values - you will need to think about building out some kind of Master Dropdown table that contains all potential dropdown options across any question. Then you do a conditional dropdown in your task to make sure you're showing the right responses based on the question.
