10 Quickbase Application Best Practices | BEGINNER

When developing a Quickbase application internally or for a client, you should follow best practices to prevent technical debt or produce a better outcome for the client.

Why Use Best Practices?

Best practices are a set of rules/guidelines to ensure positive development outcomes. They’re universally useful regardless of application or use case. Following them will benefit both the developer and the client.

Keep in mind that the client may request a developer not implement an item listed among these best practices. While it’s a developer’s duty to inform the client on why this is a best practice, the client has the final decision on their development.

Best Practices exist in several different areas of the application. Make sure you implement these development/design choices in every case.

10 Quickbase Best Practices

1. Take Away Delete Capabilities From All Users (Except for the Developer)

You can set the delete functions per table in the User Roles permissions. With an unknown number of users in any system and the problems that can arise from deleting parent records with child records, it is best to remove this function from ALL other Users except for the Dev/Admin role unless a client requests otherwise.

Example: Deletion capabilities here have been removed from several critical tables within the Role Permissions. The Green checkmark identifies the few remaining places users in this role CAN delete records.

2. Stick to Uniform Formatting

You should format every table form, regardless of anticipated use by non-admin users, similarly (section headers, tab coloring, etc.).

As developers, we often have to demo/screen share our work. Inevitably, you will find yourself on a functional table that is not ordinarily for end-user consumption. Formatting these forms takes seconds and prevents them from looking disorganized and sloppy to our clients.

Example: In this application, it is highly unlikely that an end user will ever travel to the Documents table, as it is available as an embedded report in many other forms.

However, it is formatted to match other forms (with the client’s logo coloring and stylized section headers) since the capability of visiting the table has not been blocked.

3. Use Comments to Avoid Confusion

Add comments to field settings to describe how/where you use the fields, especially when you use them in formulas.

With proper documentation, other people, even non-developers, can understand how/where/why you use different formula fields and various functions within those formulas. This can be essential in troubleshooting errors and preventing accidental deletion of critical fields.

Example: A comment was added to the Invoice # field to explain how it should and should not be utilized. Note that the developer also identified that they use this field in a Pipeline, which is not always clear from the field Usage tab.

Example: This formula contains commentary explaining its purpose within the overall workflow of the application, which may not be clear from the field title.

Commentary within the formula field is identified by “//” which does not allow the string of text to interfere with the rest of the formula syntax. This can be done at the top or bottom of the formula window, or within the formula between lines.

4. Take Away Shared Reporting Capabilities

Similar to deleted permissions, this best practice can prevent problems that arise when users remove or edit critical common reports.

Note: You can also set reporting permissions in the User Role permissions.

With an unknown number of users in any system, we generally do not want them to create unnecessarily complex reports for teams. Taking away reporting capabilities will also prevent users from saving edits to common reports with filters in place. Instead, limit report creation/deletion to Dev/Admin roles unless requested by client.

Example: You can make this rule for individual reports on each table, or you can disable reporting capabilities in their entirety within the Role User Interface setup. Neither of these options prevents end users from creating personal reports. They only affect reports already created within the app.

5. Never Leave Default Dashboards Empty/Blank

Inevitably, clients will eventually add users into a role not meant for them. When that happens, landing on a blank page does not look good.

During development, if client end users access the app, they should land on a dashboard that provides information. This gives them the impression that you are making progress.

In contrast, a blank looks like you have not done your work (even if you did). That is because relationship diagrams and other back-end work do not mean anything to end users, visuals do.

Example: In this case, the developers created a complex series of Tables, Table Relationships, and Pipelines to support an invoicing process. However, the Default Dashboard was blank, so end users could not see the intricate architecture. To them, it looked like little work had been accomplished in this build.

6. Separate Administrator and Development Roles

Setting this feature will help control visibility, even if the permissions are identical.

• Developers should see everything at all times, every table, testing report, record, and all still-in-development items, especially when there will be a knowledge transfer later.
• Administrators are the eventual recipients of the application. They do not need to see items still in development and functional background tables not intended for the end user. This keeps their view clean and professional-looking.

Example: In this client application, the Administrator still has all capabilities. However, because they are separated, the Developer can easily hide essential tables that are not for end-user consumption. Without this feature, these tables would unnecessarily bloat the Table list, making navigation more difficult for the Administrator.

You can set this up easily by making a copy of the Administrator role and assigning it to all developers within the app. Then, maintain the Administrator role to limit visibility in the role permissions.

7. Limit Access to User Tokens

User Tokens visibility (especially those created by Administrators and Developers—who have full access to everything within an application) should be limited to those with the corresponding role.

Tokens in plain text in your code pages, emails, or other areas are a security risk because they expose administrator access.

Example: In this case, a developer User Token is in a custom button. Hovering over this button allows anyone with this URL link to see and record the User Token. This would grant them the same level of access as the developer, creating a security risk.

8. Never Use Automations and Quickbase Actions

In some Client realms, access to Automations and Actions is still available. A sufficiently knowledgeable Developer could access them via URL in almost any realm. However, Quickbase will will eventually sunset these items. Additionally, and there is nothing these features can do that a Pipeline or Webhook cannot.

These features create tech debt and could cause issues down the road when Quickbase finally removes these deprecated automation tools. If you still use them, the sunset will break your workflows, and you’ll need a rapid overhaul and pipeline build for legacy systems to stay operational.

9. Filter Your Dropdown Results

You can adjust drop-downs from related tables to look at a specific report by editing the form. Having a filtered/sorted report can eliminate old/redundant records.

It also allows for refinement of the field output to a value that makes sense in a field, rather than defaulting to a Record ID# or other value end users will not recognize.

Example: This invoicing application has 51 Companies listed. However, only a few of these companies are active. To prevent sending an invoice to an Inactive Company, you can adjust the form settings to only include Active Companies on the Invoices form. This reduces the list to only 12. This can also make it easier for end users to make a selection, as the shorter list is easier to scan for the correct Company value.

10. Always Keep Future Scalability in Mind

Sometimes performing more complex development and spending more time on it can lead to higher scalability in the future. Developing for scalability can take many forms:

• Try not to develop so specifically that you have trouble quickly adapting to change. Allow for the potential for change to occur rapidly by not staying too narrow in your structure or design.
• If you use Lists to support functions in the app that could change or grow in number over time with the business need, consider developing a table for Administrators to manage these rather than creating a multiple-choice field that only a Developer can edit.
• When performing discovery or consulting with a client on their workflow, point out opportunities for making the process more scalable.
• Ask questions to help identify parts of the workflow that may need to change over time to support the business so you can develop with those qualities in mind.

There Are More Best Practices Out There

Best practices set professional developers apart from subpar developers who create inefficiencies and introduce risk to a business

Following these 10 in our own development is a necessary and integral part of developing QuickBase to the highest standard for all our clients. We know from experience that they ultimately result in easier handoffs, better applications, and a reduction in technical debt that can push projects off-track.

This list does not represent every Best Practice. You may identify items that fall under the definition of a Best Practice (items that are true regardless of the application or use case) that are not outlined here. Discuss these with other members of the team to gain further insight while considering adopting them.

• Author: Tom Shannon
• Email: tshannon@quandarycg.com
• Date Submitted: 8/8/2024