App deployment

Quickbase gives you flexibility in how you deploy changes to your applications and workflows. You can allow changes to go live automatically. Or you can set up a controlled deployment process. 

Automatic deployment

By default, Quickbase applications are live upon design. This gives teams the agility to implement changes with no deployments to manage.

Quickbase applications consist of metadata. They're run within the Quickbase environment on our infrastructure. As a result, they're available immediately upon publishing to permitted users, and don't require CI/CD tools to be published.

Controlled deployment

We also support a range of stringent IT security and compliance requirements. This includes giving you more control over updates to your Quickbase applications and workflows:

• Application sandbox: Lock down individual applications so their schema can only be changed via our no-code sandbox. Review a list of changes before using our push-button publishing to deploy.
• Solution APIs: Group related Quickbase applications and workflows (which we call pipelines) together into solutions. This allows you to:
  • Manage, test, and deploy changes to a solution as a single unit—ensuring a consistent state across each of your solution’s components.  
  • Create separate environments as needed (like dev, test, and prod).
  • Create a set of solutions with identical schema, perhaps to be used at different locations, and easily push updates to each solution in the set via API.  

Optionally, you can integrate with your CI/CD toolchain for even more control. A template Quickbase application for managing these deployments is also available.  

Striking the right balance  

Some organizations have precise IT requirements, who use thousands of Quickbase applications. But even for them, a one-size-fits-all approach to deployment may not be optimal.  

Quickbase lets you evolve your applications as your business needs change, without having to deal with a large backlog of IT requests. Requiring a multi-step process using Solution APIs for every change in every application, for example, could cause your business to fall behind.

That’s why we recommend you select a process that's specific to each application or category of apps. Exactly how this looks depends on your own requirements, but here are a few simple examples:  

• You might allow an application to be published live (without a sandbox or testing environment) if it contains no financial data and is not shared across departments or externally.
• You might require that all applications used by certain departments (like finance and legal) use a sandbox.
• You might give certain application administrators (who have the proper technical skill) to use a sandbox for some changes but not others. You could allow them to modify a report without a sandbox, but require a sandbox when updating a relationship or user permissions, for example.

Requiring that applications get updated using Solution APIs is perfect for cases like when:

1. The workflows in the application are revenue-adjacent,
2. There is restricted data included,
3. The app is used on a daily basis by many people, or
4. The app is shared with many external users like vendors or contractors. 

The more of these qualities your application has, the more valuable Solution APIs will be.