Create environments in a solution

Prev Next

Beta feature

This is a beta feature, which means we're still developing it. Some functionality may change.

Create environments within a solution to safely build, test, and publish changes to your apps and pipelines. Environments help you test and review work without interrupting active users or impacting production data.

A solution acts as the container for your apps and pipelines. When you create environments within a solution, Quickbase establishes structured release stages so changes can move forward safely.

Environments follow a defined workflow:

  1. Development—Build and modify schema

  2. Testing (only available in Enterprise plans)—Validate and confirm changes

  3. Production—Live version used by end users

Changes always move forward through these stages in order.

What happens when environments are created

When you create environments in a solution:

  • The original live apps and pipelines become the Production versions

  • Separate Development versions of each app and pipeline are automatically created

  • Optional Testing versions are created if you choose a three-stage structure

  • Development and Testing apps appear on the My Apps page (labeled, for example, App – Dev)

Understand access and ownership in new environments

When environments are created, new Development and Testing apps and pipelines are generated as separate instances.

For these resources:

  • App and pipeline ownership is assigned to the user who creates the environments

  • No users are automatically assigned to Development and Testing versions of apps

  • You can control exactly who has access to Development and Testing versions

This allows teams to restrict access to in-progress work while keeping Production unchanged.

Example of how ownership works across environments

  • User 1 owns the Production app

  • User 2 creates environments → becomes owner of the Development app

  • User 2 makes changes in the Development app

  • User 2 publishes changes to Testing and then Production

After deployment:

  • User 1 remains the owner of Production

  • User 2 remains the owner of Development and Testing

Create environments

  1. Open a solution.
    Your solution must already contain the apps and pipelines you want to create environments for.

  2. Select Create Environments.

  3. Choose your environment structure.

  4. Select a QBL version (use the latest).

  5. Confirm creation.

Choose an environment structure

Choose the structure that matches how your team works. You can set up either:

  • Development | Production

    Build your apps and pipelines, then make your changes live to users. Best for smaller teams or low-risk releases.

  • Development | Testing | Production

    Build your apps and pipelines, test your changes, then make them live to users. Best for teams that require validation before release.

Select a QBL version

Quickbase Language (QBL) powers how changes move between environments, by:

  • Detecting schema differences

  • Applying updates between environments

  • Validating supported features

You do not write QBL—it runs in the background during publish and restore operations.

Understand what the QBL version controls

Each QBL version supports specific schema. Always use the latest QBL version to ensure maximum compatibility.

When environments are created, Quickbase duplicates schema only, not live data.

Schema includes:

  • App settings

  • Charts

  • Connected tables

  • Dashboards

  • Fields

  • Forms

  • Pages

  • Pipelines structure

  • Relationships

  • Reports

  • Roles

  • Tables

Schema does not include:

  • Record data

  • File attachments

  • Historical logs

If your solution includes features that are not supported by the QBL version you choose:

  • Unsupported pipelines and connected tables cause environment creation to fail when added to a solution.

  • Other unsupported objects aren’t changed when updates move forward. Learn more about unsupported schema in QBL.

Learn more about what’s supported in each QBL version.

Cross-solution relationships

Apps can only belong to one solution. However, apps inside a solution may:

  • Reference apps outside the solution

  • Have relationships to external apps

When environments are created:

  • Schema inside the solution is duplicated.

  • Relationships to apps outside the solution remain pointed to the external app.

  • External apps are not duplicated.

Pipelines and channel accounts

When environments are created:

  • Pipeline structures are duplicated into Development and Testing environments.

  • Production pipelines remain live and active.

Channel accounts are not duplicated per environment. Pipeline environments reference the same channel account configuration.

This means:

  • Credential management is shared.

  • Changes to channel accounts affect pipelines across environments.

  • Carefully manage channel credentials when testing changes.

Users, roles, and ownership

When environments are created:

  • Roles and permission structures are duplicated as part of schema.

  • User assignments to roles are maintained.

  • App ownership remains consistent with the original Production app.

However:

  • Development and Testing apps are separate app instances.

  • Access to these apps depends on existing role assignments.

  • Users with access to the original app may see Dev and Test versions based on their permissions.

User data and user activity history are not copied between environments.

Delete environments

At this time, the only way to delete environments is to delete the whole solution. Learn more about deleting solutions.