It's likely that your application has a variety of intended audiences, each of whom requires different access to your information. For example, say you created an application to track car sales at your auto dealership. A sales person needs to be able to add and edit records, manipulating pricing and requests for special features. The Service department needs to see sales information too so they can have a purchased car ready for a customer to pick up. But you don't want prep workers to be able to edit a record. Nor would you want them to see the purchase price and sales commission figures.
You can arrange all this easily in QuickBase, using Roles. A role controls the level of access a user has to information in an application. When you share an application with other users, you assign a role to each one. (Or you can gather like users together in a group and assign a role to that group.) The role you assign determines what a user can see and do within the application.
When you create an application, QuickBase creates three roles automatically. These roles are usually Viewer, Participant, and Administrator. However, if you use a QuickBase template to generate an application, the default role names may be different. You can use any of these existing roles (and change them to suit your needs) or create your own custom roles from scratch.
Each role has its own set of access permissions, or properties, that you define. By creating and configuring roles, you can:
Limit a user's power to view, modify and add records. You can tell QuickBase what a user should be able to do. For example, say a client should only be able to view records, but not modify. Your assistant should be able to add records but not to modify existing records. Your boss, on the other hand, should be able to view, add and modify. You can create a role for each scenario and assign it to the appropriate user as you share your application. (In fact, QuickBase won't let you share your application with a user unless you select a role.)
Limit exactly what records a user can access. You can set the parameters outlined in the previous bullet point according to very specific criteria. For example, say you want your client to see only those records where her company is the customer. You could easily set this custom criteria. Or maybe you want a user to see only tasks you've assigned to him. No problem. Just create a custom rule. Does your application include some super secret information? If so, you can even hide specific fields and tables from a role.
Limit a user's access to menu options. You can also control user actions by hiding some menu features. For example, maybe you don't want users to be able to edit multiple records at once. No problem. You can turn off this ability for a role. You can also hide the "Add a record" button.
Note: It's possible for a user to have more than one role within an application. (Read more.)
The ability to create applications in a billing account is not governed by any of the permissions you set up in roles. Permissions assigned to roles are specific to the application in which the role resides. Therefore, you cannot give someone the permissions required to create applications using a role. Billing Account Administrators assign create permissions to users using the Manage Billing Account option.
© 1999-2010 Intuit Inc. All rights reserved.