Best Practices (Multiple Fields vs. One Field)

Question

Hello! I'm psyched to have been tapped by another team to build a project management tool in their existing QB app, and looking for some building best practices when it comes to situations where there are multiple ways to achieve the building outcome.
Using fields to build a project management tool, sometimes an outcome might be achieved with:

With one comprehensive field; or
With several fields

Approach A seems the most intuitive to me.... but occasionally, it seems like it depends on the situation and whether you'd like to drill in on a specific area of data. (Separately but similarly, I've run into wondering whether I need more than one table that is connected, versus a drop-down field built into one table - so similarly, a choice between one table in that instance, vs. many). When these situations occur, I've often built/rebuilt/unbuilt, realizing there are pros and cons to both given a scenario.
Is there a clear best way to handle these&nbsp;most of the time, understanding it might need to be assessed situationally?
My specific current project: Build the ability to track the status of moving a client file. To do so, employees attempt outreach 2x, then move the file. Sometimes, there's no contact info. They'd like to capture the dates for all of that.
To that end, I was requested to build multiple fields as follows:

Date first contact attempted
Date second contact attempted
After a max of those 2 attempts, was it successful or not
Date we were successful (redundant when the above 3 speak to the answer here)
Date file moved
Checkbox if contact info available

This instance specifically has a lot of redundancy, and categorically could be handled by one "status" field - essentially the stage of the project - with tracks changes enabled to capture the dates, as follows:

No contact info available (or maybe this is the one separate field)
Attempted contact
Successfully made contact
File was transferred

Realistically, this team does insist on option A, which is fine (it's their tool, after all - though I think as a QB-expert-hopeful, in the future I might listen first, build it, and present it.... instead of building it in real time, because folks who don't think like a builder, I think get lost in the weeds). Anyway, I'd like to get a foundational understanding of best practices here to help me learn, and as I move back through what I've already built and clean it up. Thanks in advance!------------------------------Christine Kirk------------------------------

markshnier__you · Answer

Congrats on the soon to be birth of your new Quickbase baby. Very Exciting.
Here are some comments.
These certainly feel like separate fields.

Date first contact attempted
Date second contact attempted

Date we were successful (redundant when the above 3 speak to the answer here)
Date file moved
Checkbox if contact info available

This field sounds like a formula field.

After a max of those 2 attempts, was it successful or not.

The formula would be like not isnull the first two attempts and the isnull date we were successful.

You can probably have a field to calculate the status based on other fields and maybe you want to have a status override field&nbsp;

As for when to get user feedback, one common approach is to do something quickly but maybe not polished,&nbsp; show it to the users when it's 3/4 done to get feedback that you're in the right direction and then finish it off.&nbsp;

As for this: I've run into wondering whether I need more than one table that is connected, versus a drop-down field built into one table -

There are fields with a very limited number of choices like approved or not approved or yes no then those feel like multiple choice fields. But if it's going to be a longer list then typically a relationship is better because it will let your users enter the drop-down choices.&nbsp;

Feel free to post back with any more questions.------------------------------Mark Shnier (Your Quickbase Coach)mark.shnier@gmail.com------------------------------

Forum Discussion

Best Practices (Multiple Fields vs. One Field)