Introduction
Some categories are simple, like “Priority” - it can be P1, P2, P3, etc. so you can use a list of text to describe the category options. This approach can be used for more complex things like “Department” however, in most cases important and complex objects like a department is better modelled as its own object (entity).
Some benefits of having categorising by object include:
Creates a single source of truth for the items in the category, avoiding the problem of maintaining multiple lists in sync.
Provides a home for properties that relate to each category, avoiding users randomly putting data in less ideal places, fragmenting data and risking duplication.
Makes clear the relationships and dependencies on the category object which helps you create a cleaner and more correct data model.
Improves the ability to do reporting accurately and easier to generate metrics and charts.
How It's Done
To use objects as categories simply create a new dataset with each record being one of your categories and then add a new property to the object you categorize.
Manually edit each record and update the new property to match the old category value. If you have a lot of records you can use Automation to make this data entry quicker and easier.
Use filters to count the number of items are the same when queried on the old and new category properties. When you are happy that everything is correct, you can delete the old text based category property.
Now your data model has improved another step!
Example
Say you have an “Employee” object with a text category property called “Department”. Every employee has been categorized into a department but the value in the table is just the text name of the department. You find out that the Finance and Project teams also categorize some of their records by department as well. In addtion, various people have the need to track the manager and contact/location details of each department however this information is placed ad-hoc in many places. You see this is a clearly a messy situation and the solution is to have a “Department” dataset.
Obviously after you create this department dataset it makes sense to update all previous fields that refer to department by text to be updated to refer to the new “Department” record as the source of truth. During the course of this update you find that some teams were working off an older list and some teams used different spelling for certain departments (e.g. “Program Management” and “Programme Management”). Good catch! You found out why some reports were not quite right.
Step 1
Create a new Department object and populate it with all your current departments. You can use a Form to build this for you and this is a good opportunity to add any other properties you want to track on this object such as Department Manager, Status, Location etc.
Step 2
Add new category properties to every object that uses the old text-based category property.
In this step, you should also enter the property value of the existing department. You can use automation to help you do this if you have a lot of records. If you have a table that has a high level of traffic and changes, to avoid the category fields from getting out of sync, you can add an automation that will update the new category if anyone changes the old property thereby ensuring these are in sync while you make your changes.
Step 3
Remove the old text-based category properties from all datasets. In this step, you may find that removing breaks some automation, queries or reports. Engyn’s compatibility checks might help you with repairing these as you switch over to the new category property.
Take Away
Engyn makes it just as easy to categorize things by selecting a record from another table as it is selecting a name from a list of text, and in many cases there are a lot of benefits to having your categories as a table.