Quickbase

We did not get the chance to do full maintenance on our application so I cannot give any feedback on how it went properly.

We develop new products and each requires a different workflow but uses mostly the same data. Quickbase allows a way [for] product managers to track progress.

Our Quickbase application is actually being constantly maintained due to our constantly changing business processes and workflows. Being able to to do this overnight allows us to not run into barriers to grow the business due to a difficulty in reflecting the business process within our business tools.

For instance, in 2018, we had a product that was designed to be priced by package, and as we were discussing our 2018 pricing, we realized that this particular product needed to have more granularity to allow multiple pricing configurations altogether.

With Quickbase, and over 2 days, we were able to expand that pricing of the product, from a flat pricing model into a multi-tiered pricing, trackable by client, and reportable in the same way the old method was implemented, only with much more detail and flexibility.

As a result we were able to present our new pricing plans and make available our new offering without the stress of having to worry about how to keep track of the new model, had a Quickbase mechanism not exist for it.

It all depends on the complexity of the application (# of fields, tables, etc.). Always get someone to walk you through the application to ensure you are not duplicating efforts already developed. Over the last 15 years, I usually inherit something someone else built and either found ways to improve it or it was already perfectly built and only required minor maintenance.

To accommodate a growing business, we frequently update our Quickbase applications. Especially, with strong planning, this is easy and achievable to do.

I have not updated my application much, just added a couple of fields, but it was just as easy as it had been creating it.

We have constantly updated our applications. as long as the person making the update has a full understanding of the table and the links it is easy to update. For someone that does not have that knowledge, it can be a little harder because they will need to become familiar with the table first.

I update data in our existing applications on a daily basis and it's very easy and quick to do. We have an outside vendor expert who creates and updates our applications for us. We have an inside innovation director and team who handles daily application information and another inside team who handles updating data in our applications as well.

Updating and modifying current applications in Quickbase is an easy workflow. One example would be with our Sales CRM application. We joined as a vendor for a large local event and wanted to track the visitors to our booth for future marketing campaigns. In a day, we were able to modify the CRM back-end and integrate it with our website's front-end form and easily track these leads. That is just one example of how quickly you can implement new ideas into current systems.

We have often duplicated applications and simply updated field names or Client logos. It is extremely simple.

I update applications on a day-to-day basis. It is incredibly fast once you know what you're doing.

I have only updated a QuickBase-developed application twice so far, but both times it was very easy and painless. The product is designed very well and is relatively smooth and effortless to maintain and update. I have no complaints and can only say that the more I use it the more I see its benefit to us both now and in the future.

Working on that now. I am partnering with 3rd parties to enhance our platform and add to it. The user group forum is pretty rich and I have found a lot of companies to help.

At first it was a little bit confusing but I was also able to refer to some training video to see how I needed to process and it went pretty smoothly without any issue.

I have maintained several QuickBase applications, across several of my client organizations. The best way to make changes to an existing QuickBase application is to use the Sandbox feature. If you are creating new reports, you SHOULD do it in the existing production application. But if you have to make changes to the table structures, relationships, forms etc, you should create a Sandbox from the production application, migrate some data from the production version or otherwise, make the changes necessary, test it and rollover the Sandbox to production.

There are pitfalls just like in any other application development environments. They can be aggravated in QuickBase, because of how quick it is to do something with QuickBase. Just as you can do several productive things quickly, you can even make mistakes very quickly (probably why it is called Quick Base.) So the best way to handle deployments is to have a plan.

I always have had a living document for the deployment plan, that I would start right after I create the Sandbox. Through out the development/maintenance phase, I keep documenting everything that needs to be done at the time of deployment. Otherwise, it is very easy to lose track of the tasks you need to do, leading to grave errors. At the end, it is extremely easy to review the deployment plan document and quickly estimate how long it is going to take to deploy and deploy it without errors and in a timely manner. One note of caution to QuickBase administrators: NEVER delete the connection between the production application and your sandbox. You WILL lose all the changes made in the sandbox.

Very easy to change work flow, add screens, db changes etc. One of the easiest apps to modify after live deployment.

The process is painless. All our updates have been in-place updates, we didn't need to worry about versioning, even though QuickBase does support the ability to make multiple changes then push all changes at once. Some complicated transactions were made easy by the way that QuickBase is able to import and export Excel sheets, so even most data manipulations were made easy since early on when everyone was more comfortable with using Excel. We once updated our supply chain to more correctly model our food safety requirements. The change was relatively complicated and included adding two connected tables and modifying the third. The planning stage took twice as long as the building and implementation stages combined.

We use Quickbase to track royalty payment from a publisher. We have added new products on a regular basis so need to update the database regularly. I was not involved in the initial build nor am I in IT, and I was able to update it with no problems on multiple occasions.

The double edged sword of customization is that you can build yourself into a corner. I've done it a few times and had to undo a bunch of work. That being said updating is very easy.

We manage our customer-facing email inboxes and customer feedback as well as keeping track of communications and closure to tickets.

As requirements are updated based on system changes around quickbase, we can dynamically update the formats of any tables and in most cases make advancements in the way an application is operated. This is due to you finding the best practices that have been accomplished in similar applications or in other departments.

We have interns working for us each summer who go in and update info in QuickBase. It has gone well.

I have not yet done this.

We update our primary Quick Base application all the time. Everything from tweaking a dashboard or report to capturing an entirely new business workflow. For years our call center agents have been requesting a web dashboard to be able to view their performance management, attendance and QA performance, which never seemed at all realistic until we built our operations system into Quick Base. We rolled out an extremely robust, fully-featured agent dashboard the first of this year and it has had a real impact on our retention rate and thus bottom line.

I update old apps all the time, some I wrote and some I did not. If you stick to native QuickBase and avoid javascript then it pretty easy to figure out an app, even one that you have not seen before. If you venture outside of native Quick Base, then be aware that future support just got 10x more difficult and risky. My recommendation is that the IT manager should enforce a native Policy unless the company has very strong internal support for javascript and not just one employee who wants to change the native behavior of Quick Base and leave you will a mess to support.