Hi all!

I'm just looking for some beginner/intermediate wisdom. I am taking on the (to me, much coveted) task of managing and revamping Quickbase across other arms in my division. This'll be the true test of whether I'm actually cut out for this haha - it's one thing to be self-taught and know how to build and fix across the empire that I've built, but another to jump into someone else's empire.

So. Looking for some wisdom:

What things should I know when going in and offering up a "revamp" of sorts?
What major pitfalls should I watch out for?
How might one approach doing this sort of thing? My first approach has been to learn about what sorts of things they use Quickbase for today, what data is captured, what they'd like to use it for down the line, and then with that, I'm peeking in the back end, seeing what fields/forms/reports exist, and wrapping my head around how it all is (or isn't) working together today

A sub-set of questions - might it behoove us to build several apps? I honestly have no idea how much Quickbase costs our organization, if it's per app, per user, some combination. That all is tightly managed at a level higher than me in our IT department, and app managers are only that - we're not "App Owners". But I've been thinking it really might behoove us to have several apps, that are all cross-linked, because for instance, each unit in our division coudl really have several tables -- as my unit does. There are things that will be division-wide, such as inventory management; but if we lump all these tables into one app, it will get pretty messy pretty quickly. So my sense is the best thing to do would be propose having several added apps that can be connected, one "Master" app where the universal tables live, and one for each division's division-specific work.

Forum Discussion

Quickbase - Jumping into managing someone else's build-out