OnBase Keyword Data Types: Don't Fool Around

Experience and wisdom often come from making mistakes—and trust me, I’ve made plenty! So, I must be quite wise by now. As a parent, I find myself trying to protect my kids from the mistakes I made, only to watch them stumble into different ones. The same principle applies here: I’m not trying to protect you from every mistake when configuring OnBase keywords, but rather share some of my experiences to fast-track your learning.

When it comes to choosing keyword data types in OnBase, the decision can be surprisingly overlooked. It feels straightforward: if it’s text, use alphanumeric; if it’s a number, go with numeric—right? Well, not always.

Let’s start with a few real-world scenarios that might make you rethink your approach.

Keyword Data Type - Scenario 1: The Case of the Missing Zeros

Imagine you're storing a document in OnBase with an account number like 00563407265. You set the keyword as a numeric type. Everything seems fine—until you test (and of course, we always test). Suddenly, you notice the account number is missing its leading zeros. What happened? Numeric data types strip leading zeros, which can make validation or retrieval harder down the road. Lesson learned: use alphanumeric when leading zeros are involved.

Keyword Data Type - Scenario 2: The Wildcard Search Dilemma

You’ve assigned a customer number as a numeric value because it’s a pure number—no problem, right? But then you get a ticket from operations: they can’t perform a wildcard search in OnBase using just the last four digits of the customer number. The reason? Wildcard searches don’t work on numeric fields. Ouch.

So, Should Everything Be Alphanumeric?

You might be thinking, “Simple solution—just use alphanumeric for everything!” While that’s an option, it’s not always the best one. The real answer is: it depends. 

Purpose-Driven Data Types

When configuring keywords, think about the purpose behind them. What’s the keyword’s role in your workflow? Is it purely for display, or will it be used for calculations or auto-incrementing? If math is involved—whether you’re doing calculations or using it as a unique identifier—numeric data types are appropriate.

Preparing for Future Use Cases

At Datum Evolve, we see many cases where numeric keywords eventually need to be converted to alphanumeric due to changing formats or use cases. By planning ahead and choosing the right data type from the start, you can save yourself a lot of headaches down the road. While we can’t predict the future of a keyword’s use, we can at least prepare for it.

Avoid the "Alphanumeric for Everything" Trap

One final piece of advice: don't default to using alphanumeric 250 for everything. Stick to database design best practices. Otherwise, you’ll have some very unhappy DBAs on your hands—and trust me, we want to keep them happy.

For more tips and in-depth guidance, check out the full series on optimizing your OnBase keyword configurations!

WATCH THE VIDEO SERIES HERE:  https://youtu.be/oM1H0OGxd6E