Manage updates to your business-critical applications using our new sandbox
We see many companies speeding up their innovation by building dozens or even hundreds of applications on the Quickbase platform. The more applications a company builds, the more likely some of those are tier 1 applications which are vital to a company’s operation. What’s the best way to update those business-critical applications? How can you make changes to those apps without disrupting your users? How can you make sure you’re following your company’s IT policies as you’re updating those tier 1 apps? The answer is to have a strategy for application lifecycle management.
Application lifecycle management is a system for planning, building, testing, and releasing changes to software applications. You can think of these steps as a cycle, to make sure you can continually improve your applications to meet ever-changing business needs. Application lifecycle management should be part of your overall governance strategy. As a best practice, we recommend you make changes to your most business-critical Quickbase applications using a sandbox.
You enable Quickbase’s sandbox on a per-application basis. Instead, follow this 3-step process to update your app. First, create a sandbox. Second, build and test your changes in the sandbox. Finally, publish those changes to your live application. This gives you the freedom, security, and peace of mind to make changes to your most important applications without impacting the users of the app.
Two change management models
Quickbase now offers two models for managing changes to your applications:
- Make changes in your live applications, which are applied immediately
- Make changes in a controlled sandbox, which are only applied when you publish the sandbox
You should continue to default to the standard model of making changes in your live applications to accelerate continuous improvement of your company’s unique business processes. The other half of this best practice, however, is to regularly review your apps to determine which ones are business-critical. For each app you determine is business-critical, you should establish a process for making changes to those applications using a sandbox.
Of course, all applications you build on the Quickbase platform are important to your business in some way. So, what indicators should you look for to decide whether to control changes to an app using a sandbox?
Types of apps you should consider using a sandbox with
The benefit of making app changes using a sandbox is to minimize risk. When reviewing your apps, here are some types of apps you should consider using a sandbox for:
- Apps which you’ve shared cross-functionally, across many departments in your company
- Apps which you’ve shared with vendors, outside contractors, or customers
- Apps which large groups depend on to do their day-to-day work
- Apps which hold sensitive or protected classes of data
- Apps which have direct revenue implications
- Apps which have direct regulatory or compliance implications
Most companies will benefit from using the sandbox for a small number of their Quickbase applications. When thinking about change management, focusing your time on those apps which are most central to your business’s success and reliability will help you best manage risk.
Example use cases
Across the following sections, you can find 3 examples of use cases where the new sandbox is essential to an application’s continued success and growth. Notice how the change management processes for each example are a bit different and involve different people. What kinds of processes should you set up for your most business-critical Quickbase apps? That depends on your company’s overall business strategy, and specifically what types of risk you’re trying to address. If you use QB Sync to run your own account management application, you should consider adding a table related to your Apps table to track changes to your apps and the approvals that may come with that.
Example use case #1: incident tracker
A manufacturing company tracks safety incidents in their warehouses using a Quickbase application. Federal Occupational Safety and Health Administration (OSHA) regulations dictate how and when safety incidents must be reported. Therefore, the company requires that all changes made to the Incident Tracker be made through a sandbox and get IT approval.
This is a high-level view of the change management process for this application:
In order to make changes to the Incident Tracker, the app administrator must first create a sandbox. In the sandbox, the app administrator would then make the changes. Next, they invite one of the end users of the app to test and give their feedback. After the end user has finished their testing, a member of the IT team is invited into the app to test and approve the changes. In this case, given the regulatory implications of the Incident Tracker, the IT team member publishes the changes to the live app.
Example use case #2: power line repairs
An electric utility company manages installation and repair of their power lines using a Quickbase application. The company serves millions of residential and commercial customers in many states. A field staff of several thousand technicians use their phones to log their work in Quickbase every day. If their workflow is interrupted, and they can’t get quick access to information about needed repairs, more power outages could result. Therefore, the utility company requires that any changes to the Power Line Repairs application must be made through a sandbox.
This is a high-level view of the change management process for this application:
In order to make changes to the Power Line Repairs application, the app administrator must first create a sandbox. In the sandbox, the app administrator would then make the changes. Next, they invite 2 of the app’s users to test and give their feedback. A large team uses this application, so it’s important to get feedback from multiple users. After the end users finish their testing, the app administrator publishes the changes to the live app.
Example Use Case #3: Job Candidate Tracker
An HR team tracks their company’s pipeline of job candidates using a Quickbase application. The app contains sensitive personal information, such as social security numbers, home addresses, and the candidates’ employment histories. Because of the company’s data classification policies, changes made to the Job Candidate Tracker must be made through a sandbox and get IT approval. The sandbox feature gives companies the flexibility for members of an HR operations group to build and maintain the application, without having access to the data stored in that application. Access to candidate information would therefore be restricted to the recruiters who need to read candidates’ files to make decisions. This is done by removing the app builders’ administrator permissions before the application enters use. Then, whenever a sandbox is created, the app builders are granted administrator access to the sandbox.
This is a high-level view of the change management process for this application:
To make updates to the job candidate tracker, a recruiter who manages the app must first create a sandbox. When they create that sandbox, they do so without copying any of the data from the live app. Next, the recruiter invites a member of their HR operations group to the sandbox as an administrator. Next, the recruiter meets with the HR operations specialist to discuss what changes they want to make to the application. Then the HR operations specialist makes the app changes in the sandbox. The HR operations specialist would then invite an end user of the app into the sandbox, to test the changes. After the end user finishes their testing, an IT staff member must approve the changes to make sure they follow the company’s data governance policies. After the IT staff member signs off, the app administrator who created the sandbox publishes the changes to their live app.
Further Reading
- About Quickbase sandbox help topic
- Sandbox: Best Practice for Application Development blog post