Forum Discussion
DonLarson
6 years agoQrew Elite
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:
------------------------------
Don Larson
Paasporter
Westlake OH
------------------------------
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
------------------------------
IvanWeiss
6 years agoQrew Captain
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
------------------------------
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
------------------------------
- MarkShnier__You6 years ago
Qrew Legend
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
------------------------------- IvanWeiss6 years agoQrew CaptainMark, based on that it sounds like sync table is the way to go but a few questions:
- Does the schema sync as well or do I need to remember to make any changes in both places to the table design?
- 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?
- 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
------------------------------- AustinK6 years agoQrew CommanderYou 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.