Thanks for your thoughtful response. As you said, with any enterprise-wide software serving multiple processes, standards across applications are necessary so apps can work together to achieve a common purpose. Obviously, you’ve created such an ecosystem and in your case, it seems like the right solution to limit users’ ability to change those fundamental standards. That’s precisely why its important for application creators and managers like you (and the people surveyed) to have control over things like roles, data definitions, and process flows across all apps. In QuickBase, application managers can control each and every one of these aspects.

I also hear you on the point that there’s lots of room for improvement. Many of the suggestions you’ve brought up here including foreign formats, workflow triggers, and a more modern UI are feedback we hear quite often. In fact, if you visit our customer feedback forum (which I encourage you to contribute to, if you haven’t already) you can see that some of your requests are the most popular: http://bit.ly/Afsvmg. Our product management team considers all of these suggestions for our roadmap. In an ideal world, we could tackle all these suggestions right away, but as with any other business we have to allocate our the resources we have and make some tough decisions. At the same time, if you peruse product release announcements you’ll see that some of the features in the forum have been included in product releases since the forum’s launch in spring of 2011, and we’ve got some exciting UI improvements ahead. With your help via feedback like this and in the customer feedback forum, we can improve everyone’s experience of QuickBase. 

Thanks again for your comment. I’ll make sure the broader team sees this. 

^Alex

Most real world applications serve multiple processes many users in many different roles. And in
these cases there should be some sort of architecture: responsibilities, roles, datadefinitions,  procesflows, etc. In traditional system
development this would require a lot of disciplines to build a robust, secure,
scalable, maintainable information system.  It’s true that, in case we develop with (for
example) Quickbase, we can skip some of those expertise’s. But I still need people
that can do information analysis, risk assessment,  procesdesign,  etc.  So
I do not encourage employees to
create solutions independently, because that would certainly kill the
architecture.      

But there is another reason why individual users in our company do not develop
their own solutions, not even for personal use. And that is because building a Quickbase application is far more complex than it should be: It still does not support…..

- foreign formats (dates, amounts, phone numbers, etc.),

- triggers to implement workflows

- SQL Select statements (requires lots of lookup and formula fields)

- restrictions in Business Rules (only 20 derived fields, no rules
behind Grid edit, etc.)

- change logs

- a decent staging method (multiple versions in development)

- a more modern user interface

- etc…

I have created many workarounds for all these issues in my apps. They work, but do not make
the apps very easy to build and/or maintain. As long as we need all those workarounds nobody
here has the time to develop their own Quickbase applications.