Quickbase

That's actually something that I believe is on the dangerous side of low-code. I think that it's hard to track changes if you don't comment out what you have written or changed. A lot of things interact within Quickbase, you could have various tables that are connected and fields that reference each other as well. So, deleting stuff is one of the scariest things in Quickbase. Never delete unless you're truly certain that's what you want. As for just updating, as long as you have your eggs lined up in a basket and you know what you're ready to do it's no issue at all.

I think the key there is understanding how it was originally built. So who did it, why they did it, understanding the back. Once you get there taking it to the next level, whether it's enhancing it or fixing it, is pretty straightforward. The biggest piece is understanding how it was built originally.

There was one where, another coworker built it, but I had to go in and make a change to it, so I had to get with them once so they could explain it to me. It's not that hard. As long as there's kind of similarities between all the apps, you have base guardrails and stuff like that, but it's not too difficult to go in afterward for someone to make changes. You just have to of meet with them, and understand what's going on.

There's always a trade-off. It's just the if, and it depends on the original developer. If the original developer followed all guidelines, commented out a lot of stuff, commented out fields, and created comments in the formula columns, it becomes easy to manage. So it depends. That's a question that could have multiple answers.

Yeah with my company, it's pretty normal to have the original designer resign, retire, go somewhere else, and all of a sudden you inherit an application that you didn't build.I actually mean you didn't. You essentially have to study it and in some cases perfect. The challenges that the original designer put in place. <br><br>I think one of the challenges that I've experienced with my company in particular is that we don't require people to get certified in order to build in Quickbase. We can just basically get people a license and let 'em go out there and start building, and sometimes that leads to good results. Sometimes that leads to disastrous results when people start building without really knowing what they're. And then the person who inherits that application has to create the foundation correctly or restructure it so that way it can do what it needs to do.<br><br>So yeah, I have inherited I would say quite a few. For the most part I would say the process has been successful. It's just a matter of understanding what the customer's trying to accomplish with that app.

We do that every single day where we're working with clients and they want to change workflows.That's, it's a common occurrence. People, their business and how they do business, it changes pretty regularly. And I think, again, one of the strengths a kind of a low-code platform, like Quickbase is that, you're really embracing the agile kind of mindset where you build something and then your business requirements change and you can pivot really quickly.We have a client that's that has a approval workflow, a very complicated approval workflow, that goes through three layers of management. And they were bought out by another company and their workflows keep changing like every month. And we've been able to work with them and just alter their tool within a few hours as opposed to like several weeks to then support their new workload.

Yeah, so that's actually exactly what I do. Someone had developed it and then I go in and manage it, change it, that kind of thing. I added a bunch of statistical aspects to it so that I can monitor the teamwork as well. So I've been editing it a little bit.

I've had to create a new system in Quickbase. I created a few tables and relationships, some automation, and a dashboard and got things up and running in no time! It was easy to build on my existing framework. It's so satisfying to see results come together so quickly with minimal effort. A little prior planning makes building apps a breeze.

I'm in the process right now. I built my first for this company and now that we've expanded in our job tasks and the things that are being requested of us it's time to reevaluate at this point in time. It's not terribly hard to do.It just takes a little bit more thought process before you make those changes. But you have think about what's going ahead of you, where are you trying to go, but it's not that hard.

We've done that in our app many times. I just, either if it's something that I need to do a sandbox or I'll do that, or if it's a little quick change for something simple. Just doing it real quick works for us.

I have not done any updates or had any done by our IT department from the time I have used it.

We update Quickbase all of the time. Our initial implementation was our largest feat, and it went relatively well. If you understand your data and what you want to do with it, Quickbase is well-suited to help bring that to fruition. Quickbase is continuing to evolve; it is showing that a good balance of features, speed, and scalability can be in an affordable and not overly complex solution.

I have edited an already-built application before and I would say it is fairly easy! With the application previously built,I can go into the settings and look at how everything is already linked. From there, it is a bit easier for me to understand where I can add an extra link or information to the already existing application. I also appreciate the chart options to add to my home pages for easily accessible information.

We are always developing new fields and changing data attributes in QB. It has been very easy to test, update, and promote into a environment.

I have not yet needed to update an existing app, but the module design of an existing app and the freedom to revise the app is very valuable!

Usually, all the applications are in a constant update or improvement as part of the quality assurance and continuous improvement of processes.

Updates can be done on the fly and published quickly.

It is not hard to implement. However, it is a little hard to keep track of changes. Since lots of control are done by text field and formula field, due to a lack of work flow control in QuickBase, it is not easy to keep pace of changing demand when changing control fields.

For the most part, our system has been "set it and forget it." When we have tried to update certain aspects, we have implemented new features such as the Kanban. Sometimes it works, sometimes it doesn't.

I have never done that and always created from scratch

Last week only I updated one of our client application as per their new requirement to add in the application and it went very good without any issue and client is also happy with it

For the most part, updating Quickbase applications is a non-problem-causing issue. There are times that it requires much thought and incremental step updates to ensure that potential problems do not become kinetic problems.

We regularly added additional fields to our tables. As the business needs to be changed, we found it quite easy to supplement our data collection efforts with new fields. One thing that would have been handy is to archive or otherwise hide fields that were no longer required but contained data we wanted to retain.

There's not a lot of "updating" that takes place in my organization. [We're] mostly adding new features as we think about them. I think the only time I've ever really updated an application is when an old employee left the company and we wanted to revamp the inventory process. Quickbase is super easy to make changes as needed.

I update applications regularly. I recently updated an entire application by making a copy of it, making substantial structural tweaks and changes because of the increased features of [QuickBase] and our security systems allowing us to work more natively in the application. This allowed me to make changes without shutting down the application, then transfer the remaining data that happened while updating the app and lastly moving all of our users over without most users even noticing they were actually in a different application. The [end-user] experience was one of an upgrade vs a brand new app.