Overall QuickBase Review
What do you like best about the product?
QuickBase is an intensly powerful tool depending on how it's being used. My organization leverages QuickBase in ways that nearly no one leverages the platform. It's Low-Code to No-Code driven solution makes the platform that much better in being able to generate things on demand.
Pipelines is the bread winner. It's generally easy to integrate with both internal and external functions!
Platform uptime is significantly impressive.
Pipelines is the bread winner. It's generally easy to integrate with both internal and external functions!
Platform uptime is significantly impressive.
What do you dislike about the product?
I do not like the fact that QuickBase deprecates functionality without identical/working alternatives.
Certain Formulaic Items can get a bit tricky and can be tough to implement. There's not enough documentation available related to Formulas where it can get specific to your Application, Enviornment & or Business Needs. Even if you are a QuickBase Expert you will run into some challenges. (This will likely change with the implementation of AI)
The QuickBase Application Table Sizes can sometimes be tough to work within the confines of said table size, due to the maximum table size within QuickBase's Platform, there is a lot of functionality that I am unable to take advantage of as the Data Set Sizes I'd need would quickly exceed the allowed table size. This in turn forces us to build code to generate the equivalent of what we could get out of QuickBase Natively.
Cannot stand that every report you can download from QuickBase has to be in .CSV, would be nice if .XLS or .XLSX is supported, same for PDF Reports. Especially given that Subscription Reports have the ability to email out the same report as a PDF.
If you are not a Jinja Ninja, pipelines can be a bit tough to work with. Native QuickBase fields/sub-fields are widely used within QuickBase however you cannot leverage Pipelines Natively within a "Search Records" step to procure the data you need, instead you'd have to do a Make Request to the QuickBase API's to procure the same data, when you leverage the QuickBase API in many cases you will require Jinja to parse the response payloads which is also tricky.
Certain Formulaic Items can get a bit tricky and can be tough to implement. There's not enough documentation available related to Formulas where it can get specific to your Application, Enviornment & or Business Needs. Even if you are a QuickBase Expert you will run into some challenges. (This will likely change with the implementation of AI)
The QuickBase Application Table Sizes can sometimes be tough to work within the confines of said table size, due to the maximum table size within QuickBase's Platform, there is a lot of functionality that I am unable to take advantage of as the Data Set Sizes I'd need would quickly exceed the allowed table size. This in turn forces us to build code to generate the equivalent of what we could get out of QuickBase Natively.
Cannot stand that every report you can download from QuickBase has to be in .CSV, would be nice if .XLS or .XLSX is supported, same for PDF Reports. Especially given that Subscription Reports have the ability to email out the same report as a PDF.
If you are not a Jinja Ninja, pipelines can be a bit tough to work with. Native QuickBase fields/sub-fields are widely used within QuickBase however you cannot leverage Pipelines Natively within a "Search Records" step to procure the data you need, instead you'd have to do a Make Request to the QuickBase API's to procure the same data, when you leverage the QuickBase API in many cases you will require Jinja to parse the response payloads which is also tricky.
What problems is the product solving and how is that benefiting you?
QuickBase Solves a lot of issues in terms of being a Front End UI for both Internal and External Users.
Data collection is the biggest one, for example. It would take 30 seconds to create a new field, make it visible to a specific user on a form where as if you needed to do this in something like an Angular or React Front End it requires code changes to both the front end and the back end.
In our organizations use case, it's significant that we have the ability to "Stage" all the changes we need to have done which will interface with backend code based solutions.
Data collection is the biggest one, for example. It would take 30 seconds to create a new field, make it visible to a specific user on a form where as if you needed to do this in something like an Angular or React Front End it requires code changes to both the front end and the back end.
In our organizations use case, it's significant that we have the ability to "Stage" all the changes we need to have done which will interface with backend code based solutions.