Managing data is tough. Every business operates differently and no matter which application you select to manage your assets and infrastructure, it’s likely that right out of the box the application will not be configured to suit your specific needs.
In this example, let’s say you want to track the General Contractor on a Work Order. Easy enough, right? Well, sort of. The problem here is that your software application does not have a “General Contractor” field on the Work Order input form. Now you’re thinking “…Rats. Now what. I spent all this money on this dang thing and I can’t even track the General Contractor on my Work Order – I swear they said we could do that when I sat through their demo…”
Don’t worry; you’re not out of luck just yet. Chances are, you just need to spend some time configuring the application.
A common practice among software developers involves pre-filling the application database with “extra” fields and allowing users to use these fields as necessary (in this example, using one of the extra fields as the “General Contractor” field).
Another common practice involves pre-filling the database with common fields that the software publisher thinks you may need. Hopefully they thought you would need a “General Contractor” field, in this example.
The key fault with these methods is that the application database will never truly line up with your needs.
Using the above methods to manage data, you’re likely to end up in one of these situations:
- You’ll have a bunch of unused (and unnecessary) “extra” fields in your database, or
- You’ll have to make do with pre-determined data fields that may or may not be what you’re looking for, or
- You simply won’t have enough fields to track the necessary data.
The solution? We use what we refer to as “Dynamic Data”. We call it dynamic because it’s not pre-determined, and there are no extra, unnecessary, or unused fields in the application database.
Here’s how it works.
Again, let’s say that you want to track the “General Contractor” on your work order. In the Elements application settings, you use the dynamic data feature to simply create a new “General Contractor” field, determine the type of field that you prefer (drop down list, for example), and define where you want the newly created field to be tracked. Voila. You now have your “General Contractor” field, it’s in the right place, it works according to your needs, and you’re not stuck with a bunch of unnecessary fields in your database.
Now, let’s take that one step further. Maybe you’ve got an entire data form that you’d like to track, a specific “Flow Test” for example. Well, how in the world are you supposed to track your flow tests if the application doesn’t have a “Flow Test” data input form? Unfortunately using pre-built “extra” database fields provided by the vendor won’t work in this situation.
The answer? Dynamic data. In this case we can create an unlimited number of custom fields (specific to our “Flow Test”) and we can assign those fields to a Flow Test data input form. Voila (love that word), we’ve done it again.
The dynamic data engine in Elements also allows users to define dynamic page layouts, grid layouts, and much more. Check back to learn more about the dynamic data in functionality in Elements.
