Domino Flex Fields

11/03/2006 04:49 PM by Chris Toohey

The majority of off-the-shelf solutions are designed to meet certain needs, but anyone can tell you that shelfware will only give you 80-90% (on a good day) of the functionality and capability that you're business requires. Even vertical-specific shelfware is not designed to a given customer's requirements - Your company needs to track specific data and perform specific functionality based on your business requirements. This is the problem at the heart of the CIO plight: 3rd Party Shelfware or 3rd Party-or-In House Custom software?

The better software solutions on the market today allow you to expand the current solution via configuration controls, which conditionally allow either pre-built or custom functionality and data entry points. From the functionality standpoint, creating/expanding built-in functionality (especially in the Lotus software world) is often simple enough... provided the solution is architected properly and allows the Admin or Power User type of users to modify said functionality via a controlled environment such as a configuration console/dashboard UI. A solution that's user-friendly enough while giving it's author the ability to address their business requirements. I'll go into just how such a dashboard solution can be architected in a future publishing, and instead turn my attention to a much more common theme in "better software solutions".

Enter User Defined Fields (UDF) - something that the majority of even LND-based solutions use to allow a given Admin or Power User to define what content is stored and displayed in a document without the needs to re-write the application UI (read: customize the 3rd-Party solution, thus possibly voiding vendor support and at the very least making upgrades that much more difficult...). With UDFs, the solutions typically allow for the label to be changed to reflect the requested content, while the field is named something like "UserDefined01".

This works for individual deployments, but a problem arises when the solution is deployed across multiple business units, (or subsidiaries, etc.). UserDefined01 might be labelled "Eye Color" in one instance while it's labelled "Weight" in another. Now, if you're looking to consolidate the data across the entire organization into a Master Data Warehouse of sorts, or simply trying to do consolidated reporting... you've now got a nightmare on your hands: Half of your reports tell you that your customer weighs "blue"!

Someting else to consider is the daily overhead resultant from the configuration being checked, rechecked, and rechecked again each time the solution is launched. Consider this: When you open a given form, it needs to see what fields are to be shown and what fields are to be hidden. It needs to display a conditional label and possibly even a conditional data entry "widget". Once your solution is set, why do you need to constantly check and recheck and recheck again what the configuration should be? Again, more on that later. For now, back to our UDFs...

So what do we do? Well, a current SQL/.Net solution that I'm working on has an interesting architecture in place to account for future/further data requirements without modification to the backend data tables: Flex Fields.

Oracle defines the Flexfield as follows: (source: SearchOracle.com)

"...a flexfield is a database field that has flexibility built into it so that users can define reporting structures that are relevant to their specific organizations."

The SQL/.Net solution adopted this methodology and created Flex Field records that store given data for the "parent" record for further usage, while maintaining the current application architecture. It's a pretty slick solution actually, and something that I in-turn stole adopted for usage in my LND-based solutions.

So, let's recap...

The issue:
UDFs don't work. For small shops and single-instance deployments, they're fine. Otherwise, it's a data integrity nightmare potentially storing ANY field data in general fields that's input criteria can only be defined by the change of a label.
The (suggested) solution:
Create Domino Flex Fields. Documents will have subordinate documents that contain the elective data, the elective unique data key (the fieldname if you will), and the elective data label. Take this a step farther (and as a Proof of Concept), we will modify a sample application UI (Notes based, as the Domino web implementation is so much easier) and allow limitless Flex Field creation, utilization, and modification.

In the next part of this article, we'll discuss the steps taken to create the Domino Flex Field POC.