Welcome to Quickbase Straight Up

QuickBase Straight Up is a newsletter and blog containing tips and tricks to help you get the most out of QuickBase. Click the "Join Our Mailing List" image on the right to subscribe to the newsletter and start learning about all the QuickBase features you've been missing.

QuickBase Straight Up is published by The Data Collaborative, which works with both developers and users to locate areas where QuickBase instruction is needed.

More QuickBase Best Practices

June 10th, 2010
Create a Table of Users
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.

Users Table

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.
 
Secure Formula
 
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.

key field

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  

Tags:
Posted in Articles | 1 Comment »

QuickBase Best Practices, Part I

January 24th, 2010
Best Practices for QuickBase - Part 1
In the world of QuickBase consulting, at least half of our work involves applications that customers have already started. Sometimes customers do a great job, but most of our customers are experts in the area of their business — not databases.

So as a public service, we’d like to give you a few guidelines for putting together your QuickBase. If you can put these into practice, then when the time comes to work with a consultant, we promise you’ll hear some nice comments on the other end of the phone - “Nice job, you really know what you’re doing!”

I know you’re busy so we will keep this brief — a few here and then a few more next issue.

1. Understand Relationships - Never Enter Data Twice
Most of a database’s power, and most of its complexity, is in the relationships between tables. If your application has one table in it, that is a clear sign that you are missing out on the jelly in the QuickBase doughnut. Relationships are important!
You need to learn how QuickBase deals with relationships, but even before that, you need to see why relationships are important. A good starting point is the article here. This is specifically about MS Access, but the article is still good for QuickBase users and it is way easier to understand than the Wikipedia article!
2. Keep it in One Application
In most cases, it’s best to keep your company’s work in a single QuickBase application. That’s because tables often relate to each other. For example, if you have one application for Order Entry and another for Customer Satisfaction, they are both going to use your Customer List, your Employee List, and probably other tables too. You don’t want to have two Customer lists so that means that one application will need to hold the Customer list, and the other will have to use a cross-application relationship to see it. Cross-application relationships are OK, but they have some limits. Better to keep it all in one application.
Of course, there are exceptions to this. If your applications are owned by different people, or they just get big and un-manageable, it’s best to separate them. But don’t do it unless you have a good reason.

3. Know what you’re doing with Proxy Fields
Almost every time you set up a relationship in QuickBase, a “proxy field” is created. That’s so when you pick a parent record, you see a dropdown that is meaningful to you.
For example, if you have a relationship between Projects and Customers (one Customer to many Projects), the real relationship is between the Project and the Customer’s Number. But a Customer Number (1,2,3) is probably meaningless to you. What you really want to see is the Customer Name. So in a case like this, you want the Customer Name to be a proxy field in the relationship.


The Infamous Proxy Field - Should it be banned?

However, Proxy Fields are problematic. In the example above, if you had both the Customer Name field and the Related Customer field on the same form, they would cancel each other out and neither would work! And Proxy Fields can create problems when they are used for filtering records in a Report, too.
At Data Collaborative, our general practice is not to use Proxy Fields. But we are QuickBase geeks - we eat and breathe this stuff. Our advice to you is this: pick one strategy and stick with it. If you use Proxy Fields, be careful about mixing a Proxy Field and a Lookup Field on the same form. If you don’t use Proxy Fields, learn how to use Record Picker fields to make the lookup dropdown have meaningful values.

Tags:
Posted in Articles | No Comments »

QuickBase November 2009 Release

December 8th, 2009

We were planning on a second issue of QuickBase best practices, but that will have to wait - QuickBase surprised us with a November release so let’s all get up to date on the new features!

 
Overview
 
The main beneficiaries of this release are QuickBase customers with many users. Customers can now manage large numbers of users at once, and most importantly, there is now a “sandbox” for making changes to applications  without affecting current operations. This feature, however, is only available to Enterprise users (around $1,500/month).
 
User Management

 
You can now import and provision any number of users by just importing from a comma delimited (csv) file. And once they are imported, you can search by name, type of user or other criteria, and then deactivate, deny use, or email all the users you have selected.
 
Reporting

 
In the past, if you had two or more filters for a report, you could only delete the bottom one. Now, using the red light/green light icons, you can add or delete filters at any point in the stack.
 
Insert or Delete a Row
These insert/delete icons appear when you float your mouse over filter lines during report setup.
 
Sandbox

 
This one is important. It has always been difficult to make changes to QuickBase applications that are in production — there has always been the risk of accidentally breaking an important app during development.
 
Now, Enterprise users can create a “sandbox” — a development environment where they can make changes without affecting the active application. When development and testing are done, you press a button, and all your changes are applied to the active application.
 
This does not solve all the issues related to development. For example, you cannot make any destructive changes to the sandbox application. You can’t delete fields or tables, change data types, etc. So if your changes involve any deletions, the sandbox will not help you.
 
But still, for Enterprise customers at least, it is a big step forward!

 

Happy clicking –

Posted in Articles | No Comments »

« Older Entries
Newer Entries »