App development

Quickbase apps are created through configuration and are represented by metadata and schema, not code. The platform interprets and runs this metadata and schema in memory. With this process, there is not a code generation, compile or build stage for application development. It is important to understand that applications on Quickbase are always live and running. This infrastructure builds in guardrails that directly handle the app architecture, performance and scaling issues encountered with traditional app development.


Since Quickbase applications are configured, not coded, there is no need to track and control changes to source code. App versioning is not supported natively by the Quickbase platform. Changes can be made and reversed on the fly. Apps are automatically backed up for all customers on a regular basis. If needed, app restore services are available as data restores, table overwrites or a complete app rollback. Most schema changes are reflected in our audit logs.

If needed, developers can create copies of apps that serve as a 'version,' that can either be promoted back into production or saved for documentation, reference, or other purposes. For customers specifically looking for versioning functionality, APIs provide access to schema information for advanced Quickbase developers to build their own.

Collaborative development

Quickbase’s single development environment supports all developers and teams. Business technologists, citizen developers and IT can work together because they are working on the same app creating a common metadata representation of the app. Additionally, professional developers can collaborate and add value by extending the applications created by the business through APIs and custom interfaces.

Change management and testing

Sandbox environment

The Quickbase Sandbox capability is different from traditional development sandbox environment used by professional software developers – it is built with business developers in mind. The Sandbox feature is a lightweight change control mechanism to support the ability to quickly make and verify changes while satisfying the requirements typically expected by professional developers. It is a safe development environment separate from, but contained within the app, in which changes can be built, tested and reviewed before changes are published to all users.

A Quickbase best practice is to use Sandbox for business critical applications where more control is required in the change process. Quickbase’s Sandbox functionality provides an opportunity for IT and business developers to work together to minimize risk by verifying changes and application functionality before releasing it to the entire user base. However, many applications developed with Quickbase do not need the separate development environment to make changes, and benefit from limited friction in the development process. IT administrators can specify which applications must go through Sandbox change process for more control over who can make changes and what change can be made.

QA and testing

When structural changes are made to a Quickbase application, the metadata-driven architecture ensures apps continue to run as the changes are happening. The platform has built-in guardrails in the development process to stop problematic structural changes at the at the time of design, before those changes are saved. With this architecture, there is much less opportunity for poor technical design; however, that risk is not eliminated. Quickbase is able to automatically optimize poorly structured report filters and searches. The Performance Analyzer is built into the platform to help builders analyze application response time and pinpoint problem areas. The Performance Optimizer leverages our platform data and experience to identify and apply (if desired) app changes to improve performance and scale.

Many elements of testing happen automatically and are abstracted away from the developer, such as when names of fields, apps, etc. are changed in Quickbase. The platform automatically handles cascading name changes of app elements (tables, fields, etc.) to other affected app elements (forms, reports, formulas, references, etc.) without builder involvement. Quickbase also provides tools to help builders understand where and how certain design elements are used to help them assess the impact of a change, such as: Field Usage reports; Table Relationship Diagrams; Formula Field Dependency Diagrams; Search & Replace terms in the schema.

To test the impact of specific changes on roles and end-users, Quickbase offers 'Test as User' and 'Test as Role' to help builders assess the functional impact of their changes in different scenarios. This can be used to test the app functionality and UI as a specific user or in a specified role (which could apply to multiple users). Experienced developers use our API for advanced functional app testing. Our API exposes extensive schema data that developers use to run test cases against an app on a regular basis. In some cases, we provision for customers separate accounts to use for development and testing.

Application security guardrails

Global permissions and settings are established at the realm level with other administration settings set and managed at the account, app and workflow levels during the development process. Application level user security consists of being granted access to the platform, being invited to an app and being given permissions to do and see things in that app. Platform admins control who has permission to the platform and who can be an application manager. Security within any app is controlled by the app manager, who shares the app with users while controlling who assigns permissions to groups and roles within the app.

Other global security guardrails include IP filtering to limit access to apps by network or IP address. The approved network ranges and addresses are set by the Realm Administrators and App Managers opt in individual apps to the filtering mechanism.

Guest and Approved user status is set by Realm Administrators and applications can be flagged as only accessible to approved users for highly sensitive applications. Super user permissions are set by the Realm Administrator to help IT enforce permission, security and access policies. Group-based policy management is supported natively and is integrated with external IT systems through IdM integration.

Controls are provided for who can create new apps, build in apps, modify application schemas, save shared reports, invite users to apps, build workflows and who can use what integration channels. Administrative controls for user tokens help manage API access to the platform. IT can specify which apps must go through a QB Sandbox change process to control who can make changes and what changes can be made to critical apps.