Discussions

 View Only
  • 1.  To Make a New App or Not to Make A New App

    Posted 03-18-2020 17:48
    That is the question!

    I have a very detailed Project Management App that is in full force at this point (built last summer and at this point just ironing out some last bugs before transitioning to new features).  In addition to client based Project Management needs it has a Team Members table which is all of our internal employees and their contact info....

    We want to build an IT asset management app.  We dont need much at all.  Just need to store what devices are assigned to what user and their matching computer names, model, etc. so we know....  Date bought, etc.

    My initial though was it should be a separate app because it is not at all related to the current app....  But, the team members table would be useful in both plus my users are there...  I could just add an IT table and have it be a related table to Team Members so it connects users to their IT assets.

    What is best practices here?  Is there any reason to separate the apps?  I am not sure what other apps or functionality not related to project management I might need in the future but I could always see a reason to connect to that Team Members table.

    ------------------------------
    Ivan Weiss
    ------------------------------


  • 2.  RE: To Make a New App or Not to Make A New App

    Posted 03-18-2020 18:15
    I would make a separate app.  That way you get to use the Dashboard. This sounds like a very different app from your main app.

    For the Team Members, if you are at all concerned about performance, say if you have like 100+ users or the main app has some large tables with lots of data, then I would make a Sync table of the Team Members Table to keep the app separate.  

    Else do a cross app lookup.

    ------------------------------
    Mark Shnier (YQC)
    Quick Base Solution Provider
    Your Quick Base Coach
    http://QuickBaseCoach.com
    mark.shnier@gmail.com
    ------------------------------



  • 3.  RE: To Make a New App or Not to Make A New App

    Posted 03-18-2020 20:46
    Ivan,

    I vote new App and do a cross app relationship to the Team Members in your core ERP system application.
    The big benefits are:


    • Keeps your data normalized
    • Unique Roles
    • New Dashboards
    • Limited Users


    ------------------------------
    Don Larson
    Paasporter
    Westlake OH
    ------------------------------



  • 4.  RE: To Make a New App or Not to Make A New App

    Posted 03-19-2020 06:41
    Thanks Don, Thanks Mark!  One more follow-up question as it seems like a no brainer that the app should be separate.

    My Team Members table key field is the user field.  Not all users will have access to the IT app.  I do not think that matters because they are two completely distinct things....  But I wanted to confirm that? 

    And I am assuming that by doing this on the Team Members App (in my current app) can I see what hardware is associated with each user (a report link) or will I need to build that separately in the IT app?  I am just not sure how thorough cross app relationships are compared to in app relationships.

    I have 51 users right now so I do not think performance is going to be a major issue and only 2-3 people are planned to have access to the IT app.

    ------------------------------
    Ivan Weiss
    ------------------------------



  • 5.  RE: To Make a New App or Not to Make A New App

    Posted 03-19-2020 07:58
    Ivan
    For this question:
    And I am assuming that by doing this on the Team Members App (in my current app) can I see what hardware is associated with each user (a report link) or will I need to build that separately in the IT app?  I am just not sure how thorough cross app relationships are compared to in app relationships.

    The main difference when you make a cross app relationship, is that for some technical reason which seems difficult for Quick Base to solve, you can only "see" the relationships on the child side. The parent app will not see that the relationship exists.  That can be very confusing to the  Admin and it also means that if, for example you had a field on the Parent table that you were thinking of deleting or changing the field type on (say something innocuous like changing from a text field type to a Rich Text field type), and went to the Usage Tab, it would not say that it was used as a cross app lookup.  That will then cause problems for the cross app lookup field.  (And it will certainly cause problems for the lookup field if you delete the Parent table field, thinking it was no longer used)

    But you certainly can have report link fields working normally even though it is a cross app relationship.

    For myself, since Sync tables came out a few years ago, I have moved completely away from cross app relationships even if I'm not concerned about Performance.  I set up a "service account userid" (ie one that is not tied to a particular person, but is a robot userid owned by the IT department) and have that be the owner for any Sync table connections and Automations.  It is really super fast to set up a Sync table.

    I like the idea of an app having its own tables for the shared data like say a master list of customers or employees or items or whatever, as opposed to making a web of cross app relationships.  I have found that it makes the app easier to visualize for you as the admin and you do address future performance issues ahead of time and you are not hopping back and forth between apps.  In many cases, an app will work better from a user interface point of view if it has its own table of those master file type tables.  

    A factor too to consider is that the if you Sync across an Employee table where the key field is the QuickBase userid, it will Sync across in text format. That should not cause a problem with the exception of a change in the user's email address.

    So, you will need to decide on the 60/40 decision for you if you want to go expedient with a cross app relationship, or arguably Best Practice with a Sync table. ie its not a no brainer so you need to decide which is the 60 and which is the 40 in your situation. I think that thinking at Quick Base is to keep your apps separate as a matter of principle, now that Sync tables work so well, especially for data which is quite stable like Employee Masters and Customers and Items.  A once an hour refresh is typically plenty good enough.

    ------------------------------
    Mark Shnier (YQC)
    Quick Base Solution Provider
    Your Quick Base Coach
    http://QuickBaseCoach.com
    mark.shnier@gmail.com
    ------------------------------



  • 6.  RE: To Make a New App or Not to Make A New App

    Posted 03-20-2020 16:28
    Mark, based on that it sounds like sync table is the way to go but a few questions:

    1. Does the schema sync as well or do I need to remember to make any changes in both places to the table design?
    2. You mentioned it syncs text...  If the user is in both apps will it "recognize" that or since it goes to text are we losing all of the functionality of that user key field?
    3. If I am an admin and a user any reason not to use my username as the sync user?

    Thanks!  To your point in this case the table rarely changes, even synchronizing once a day is plenty.

    ------------------------------
    Ivan Weiss
    ------------------------------



  • 7.  RE: To Make a New App or Not to Make A New App

    Posted 03-20-2020 17:48
    You may need to convert your text-user back into a real user with a formula. This is what has caused us to go other directions than sync tables for certain things, like where the user is a key field. We ran into a large issue doing this. It ended up not being able to sync the table properly though and I want to say it was because of nicknames in Quick Base. When a user sets that in user preferences AFTER your have already had the sync table going the key field for that user is suddenly different and wrong as it switches from their email/user to be the nickname. So your first record for them does not get updated and now you have a duplicate.

    I believe we have gone the way of Pipelines for doing that specific thing now and are actually looking into other solutions as well.

    Other than that connected tables have worked wonderfully for us. Just be careful what you use for the key field. Hopefully I explained the issue I had well enough above or didn't miss any parts of it.


  • 8.  RE: To Make a New App or Not to Make A New App

    Posted 03-20-2020 18:24
    A Sync Table will only bring across the fields you initially select, as often you may just want a few fields from the source table.  So if you add fields then you need to decide if you need them in the Sync table. If you change a field type on the source it will probably break the Sync.

    So I guess to answer your question, no the schema is not mirrored.

    The issue of the userid coming across the sync in text format is not a problem, as in any relationship, on the child table, you can have a formula field connect to the employees sync table and you can convert back and forth with formula fields between a userid and a  text version of the userid.

    If you build the Sync under your userid and you find that you will not be with the company forever, then eventually the Sync connection will need to be transferred to another user.  Setting up a "service" account userid will avoid that in the future.

    .....................  BUT having said all that, I'm rethinking my advice, given that the source table has a Key field which is the userid.   I now suggest just a cross app relationship if performance is not an issue.  There is some hassle value if the user changes their email address (e.g. gets married or unmarried) or even if they learn they can give themselves a username as opposed to signing in with their full email address.  That change would break relationships with child tables which are using the text equivalent of their userid id field on the table and create Orphan child records.

    So I guess my new advice on Sync table vs cross app lookup is if performance is not an issue then for that case where the userid field is the key field, use a cross app lookup.

    If the Key field of the source is not a userid field, then use Sync. 

    If the Key field is a userid field and performance is an issue, then that is where the 60/40 decision comes into play.




    ------------------------------
    Mark Shnier (YQC)
    Quick Base Solution Provider
    Your Quick Base Coach
    http://QuickBaseCoach.com
    mark.shnier@gmail.com
    ------------------------------



  • 9.  RE: To Make a New App or Not to Make A New App

    Posted 03-23-2020 09:37
    Thanks everyone.  Cross app lookup is where I will head for this.  Maybe I will try some sort of documentation to help remind me of the connection to avoid what was raised as a potential issue

    ------------------------------
    Ivan Weiss
    ------------------------------