QuickBase Straight Up

 

Weekends are a completely different (and rather more baffling) story. Saturday and Sunday both show the worst performance times between the hours of 9 PM and 3 AM. The rest of the day is relatively constant at a substantially lower time.

Bottom Line, I was pleased at how consistent QuickBase’s performance is. There will always be some slowdown during peak work times, but performance never is worse that 50% of off-peak, which I think reflects a good job of load balancing on QuickBase’s end.

Every QuickBase application has a list of users, so creating a table of users might seem like a waste of time. And it does mean entering data twice, which we usually AVOID.

But the list of users has only two fields - the user name and role. In many cases, you need to keep track of more information about your users - like what location they work at, what team they are on, or what projects they are working on. When Quickbase has information like that, then it can be told what data the user is authorized to see, and what data should be on the user’s dashboard.

If all the users from any role in your application see the same data all the time, then you don’t need a table of users — the QuickBase list of users will do you fine.

But if you need to slice permissions a little more finely, a table of users is where you need to start. The way you use this table to set up permissions and dashboards will depend on your specific needs. But here is a simple example: 

 

Let’s say you have a database of staff members and the projects they are working on. Some staff, however, have security clearance and their projects should not be listed, except to that person themself. This would be tricky without a users table.

 

But with a table of users you could include a “Security” checkbox on each user record. Pull that value down to the projects table with a relationship, and create a formula field (see below) that yields FALSE unless a project is either being viewed by its owner, or the staffperson Security checkbox is not checked. Then base permission on that checkbox.

 

 

Yes, that is a little complicated, but it allows you to set up permissions beyond what you could do otherwise.

Don’t Mess with Key Fields

Every table has a key field - the unique value that allows QuickBase to keep track of each record. It’s kind of like a Library of Congress number — every book has its own unique number.

In QuickBase, the key field starts out being the Record ID#, and it is usually best not to change it.

Why? Well, let’s say you have a table of Basketball Teams, and you set  the key field to the Team Name. Why not? you think. Every team name is unique. But then the Washington Bullets change their name to the Washington Wizards. Because of the way relationships work in QuickBase, all the players who were listed as on the Bullets are not on your team anymore!

Names can always change, but Record IDs do not, so unless you know what you’re doing, don’t change the key field!

(PS - one exception to this is with the Users table above — in that case, the User field in that table is a good key field.)

Happy clicking —

Eric Segal
The Data Collaborative