We’ve been building and rescuing Quickbase apps since 2015, and we get a version of this call a few times a year. The person who built and maintained an organization’s Quickbase apps has retired, resigned, been laid off, or just stopped answering email, and now nobody knows how the apps work. If that’s you, here’s my advice: lock the person out today, but don’t deny the account until you know what’s running under it, because in Quickbase those are two different things. The rest of this article explains why, and what to do instead.
First, is anything actually broken?
The first question is whether the apps are working today. If users can log in, forms open, reports run, and the nightly imports showed up this morning, then you’re probably in pretty good shape. You at least have time to think, research, and plan. Most of the organizations that call us are in this situation; the problem is that something might break (and eventually it will), and there’s no one to call when it does.
If something is broken (a pipeline that stopped, a form nobody can save, an integration that quit loading data), then you need emergency triage first and planning second. Call or email us, and we’ll step in to help.
Lock out the person, not the account
Your IT department is right to cut off a departed employee’s access the day they leave, especially if the departure was hostile. So do that: revoke their single sign-on, terminate their sessions, change the password if the account isn’t behind SSO. What I’m telling you not to do is deny the Quickbase account itself until you’ve moved what depends on it. This distinction matters because denying an account is exactly what stops the things that run under it, and in Quickbase a surprising number of things can run under a specific person’s identity rather than the organization’s.
Pipelines are the big one. Every pipeline has an owner, and the connections it uses to talk to Quickbase and to outside systems were authorized by that owner. Connected tables are next: the connection that pulls data from QuickBooks, Salesforce, or another Quickbase app belongs to whoever set it up, and the owner is the one who can manage it. User tokens are tied to the user who created them, so any outside integration that authenticates with one (Zapier, Workato, Make, a custom script somebody wrote in 2021) stops when the user is denied. Automated emails and report subscriptions stop too. And if the developer was the app manager for your apps, or worse, the only realm administrator, then your first job is getting administrative control back.
In other words, denying the account comes at the end of offboarding, after everything that runs under it has moved. The good news is that, in recent years, Quickbase has introduced a lot of new features to make transitions like this smooth. A realm admin can switch into the departed user’s account to see what they owned, transfer management of the apps, change the owner of automated emails, transfer user tokens to another user through the API, and export a pipeline and import it under a new owner (it comes in disabled, with placeholders where the connections were, which the new owner then reconnects). The right destination for all of it is a service account, which Quickbase introduced for exactly this purpose: a paid seat that isn’t tied to any one person, which up to 20 people can switch into without sharing a password. One caution: a user token transferred from the departed developer is a token the departed developer still knows. So transfer it to keep the integration running, then generate a fresh one and retire the old.
If the developer hasn’t left yet and you know it’s coming, this is the moment to do all of that with his or her cooperation. I’m not saying any of this fact-finding and documentation is hard. It’s just the kind of thing that nobody takes the time to write down when they’re busy with other things, so this is the time to do it. And if you don’t have time for it yourself (because I’m sure you are busy with other things), let us handle it with your outgoing developer for you.
Take stock of the realm
Once the account is secured, find out what you actually have. Start in the Admin Console, which lists every app in the account, who manages it, and whether anyone has used it lately. (You might be surprised to find a lot more apps in your Quickbase realm than you knew about.) Check which user tokens exist and what uses them.
Then open Connection Central in the App Settings (gear or cog icon in the top left) for each app that matters; it shows the pipelines and connected tables attached to the app and who owns them. Also in the App Settings, click into App Management and then into the Manage Emails screen. Look through the email lists for subscriptions owned by the departed developer. You’ll want to change the owner for each of these that is still active and needed.
Finally, talk to the people who use the apps. A report nobody has opened in six months is probably dead; a process that runs once a year at fiscal close is not, and it won’t show up in last month’s usage.
The results of this quick investigation determine what kind of help you need. One critical app with 40 users and no documentation is a different problem from a dozen small apps that mostly work. The first calls for someone to reverse-engineer and document the app before anyone makes nonessential changes; the second may just need a maintenance arrangement and an afternoon of cleanup.
Who should take over?
Assuming you’re staying on Quickbase, you have four choices.
The first is a solo freelancer from one of the marketplaces. Many are competent, responsive, and inexpensive. Some will tell you plainly when your idea is a bad one or if there are better ways to go about it than what you’re asking them to do. The real weakness is continuity. A single freelancer is exactly the arrangement you just had: one person who knows how everything works. You’d be rebuilding the single point of failure that put you in this position.
The second is a programmer you already know or employ. This one is generally a mistake, and I say that as a programmer. Programmers understand databases. The trouble is that Quickbase does most of its work through relationships, lookup fields, summary fields, and formulas, so a well-built app keeps data where it lives and makes it available wherever it’s needed, and a programmer who doesn’t know the platform will write a pipeline or an API call to do what a lookup field already does. The result is duplicated data that creates inconsistencies and uncertainty, more moving parts, and an app that needs a programmer to keep it running. Pipelines and the API have their place (sparingly), but the architecture has to be Quickbase architecture.
The third possibility for taking over your Quickbase app is Quickbase’s own professional services team. They know the product, obviously, and for an organization making Quickbase a strategic platform, with a budget to match, they can be the right choice. If what you need is somebody to own three apps, answer the phone when something breaks, and bill you for the hours it took, you’re not the customer they’re built for. I plan to write more about that comparison separately.
The fourth possibility is a firm that specializes in Quickbase, which is what we are. We’ve been building and rescuing business software since 2015, for manufacturers, a hotel chain, a medical device maker, a state indigent-defense agency, universities, and a sign company, among many, many others, so there isn’t much in the way of a business process we haven’t already seen modeled in Quickbase. Every engagement runs through the same six phases, discovery through support, which means your apps get documented, they get built the way Quickbase is meant to be built, and more than one of us knows how they work. We integrate Quickbase with whatever else you’re running, QuickBooks, Salesforce, SharePoint, a payment processor, a legacy SQL database, because most of our custom software work is exactly that kind of integration. And we’re a team that stays: the people who build your app are the ones who answer the phone when it misbehaves two years later, whether you need us a few hours a month or a few hundred, without anyone’s livelihood depending on inventing work for you.
One of our clients, Capital Impact Partners, came to us in exactly this situation: its compliance team had inherited an application built by someone who was no longer with the company. We got the app functional again and then worked through the rest of the issues with them over the following year, which is often how these engagements go.
Is this the moment to change platforms?
A transition like this is also a natural moment to ask a bigger question, if you have the bandwidth. Maybe Quickbase has been meeting your needs, or maybe you’ve been working around it for years and the annual renewal has become a line item you wince at. Some organizations in this position conclude that a custom application, with no per-user license fees and ample file attachment space, is the better long-term answer. Something they own outright. Many conclude exactly the opposite: Quickbase is great, they handle security and infrastructure, and your app just needs an owner. Custom software costs more up front, and you take on hosting and maintenance, but the ongoing costs are often quite low; Quickbase costs less to start but more every year as the user count grows and prices increase. The tradeoff is real in both directions. We can help you think through it and do a cost-benefit analysis if you wish.
What we can do
We start with a fixed-fee Quickbase App Assessment. We go through the apps, their data models and workflows, their permissions and integrations, and come back with a written report: what you have, where the risks are, a recommendation for each app (fix, extend, re-architect, or migrate), and a fixed price for whatever we recommend next. The report is yours whether or not you go further with us. If something business-critical is already broken, we separate emergency stabilization from the assessment so the fix doesn’t wait on the report. And sometimes the recommendation is that nothing needs to change beyond making sure someone understands the apps and can maintain them. If your Quickbase developer has left and you’re not sure what you’re dealing with, request an assessment and tell us what’s working and what isn’t.
