Question
Looking at the properties for a report, there is metadata visible from the content systems like Tableau, PowerBI, and IBM Cognos Analytics, but is it possible to create custom metadata values on a report or dashboard. The objective is to designate whether certain content is certified, or to specify the data classification level.
Answer
Digital Hive provides the ability to define a custom metadata schema that will be applied to ALL objects across all the content accessible through Digital Hive, regardless of the source content system. When creating a Custom Field, t
here are different data types that can be leveraged as part of the Custom Field definition, which will expose different options/settings available. It is important to understand the differences of each type, which options are available and when they should be used. For more details about the various Custom Fields data types, please refer to this knowledge base article: https://support.digitalhive.com/portal/en/kb/articles/custom-field-data-types
Let's take a look at how to create a Custom Field that will indicate to users whether a piece of content has been certified. There are different ways to define the Custom Field and to provide the best result, it is important to understand what the desired user experience should be. For example, when a user is defining the metadata for a report, if a Boolean data type was selected for the Custom Field, then the user will have a tri-state checkbox available to them.
The default state, which means that the field is not set:
The selected state, which means that the value is yes:
The unselected state, which means that the value is no:
A Text data type could also be used to define the Custom Field, and the user experience would be slightly different. When metadata for an object is edited, the Text data type will display the possible options.
In this scenario, there is a negligible difference between the Boolean and Text data types, but, what if additional options were required. Perhaps, there should be an 'unknown' state because it's unknown whether the content has been certified, or it could be that the content review is still in progress. In this case, a third option may be desirable.
Or, if multi-lingual values are a requirement, the Text data type provides flexibility in how the values are displayed compared to the Boolean data type.
Creating a Custom Field
For this document, the assumption is that a Boolean data type is desired for the creation of a Certified Content Custom Field.
To define the schema, a user must be part of a role that has been granted the Manage Custom Fields capability.
- Launch the Digital Hive Control Center by clicking on the user avatar button and selecting Manage Digital Hive
- In the Control Center, expand the Content section using the down arrow beside Content
- Click on the Custom Fields option
- To create the first Custom Field, press the button in the middle of the screen to launch the Add new field dialog
- Using the data type selector , change the value from Text to Boolean
- Provide a Title such as Certified Content (you can ignore the internal data name field as this is just for internal usage purposes)
- Save the settings using the Save icon which will create the new Custom Field
- To further define the Custom Field, click on the settings icon to open the Boolean field settings: Certified Content dialog
- Since we're dealing with a Boolean data type, the options are limited but adjust the desired settings:
Description: Provides a description for users so that they can better understand the metadata. For a certified content field, a description of "Indicates whether this content has been certified by the Enterprise Data Management team" could be used
Value Required: Determines whether the value MUST be set when a user sets/edits metadata on an object
Categorization: When this option is enabled, the Custom Field becomes a facet that users can leverage to filter search results
Display in details panel: When enabled, the Custom Field is visible to end users when they're looking at the properties of an item. Normally, this value is set to Yes but this property can be used to hide the Custom Field from the properties, but still have the metadata present, in case it is required again in the future.
- Save the settings using the Save icon
- With the first Custom Field defined, you can see a preview of what the entire metadata schema will look like, with a sample data value, in the Preview pane
Now that the first Custom Field has been created, let's create another one to designate the classification level of the data contained within the report.
- To create the new Custom Field, press the button to launch the Add new field dialog
- For this new Custom Field we'll keep the Text data type
- Provide a Title such as Data Classification
- Save the settings using the Save icon which will create the new Custom Field
- To further define the Custom Field, click on the settings icon to open the Text field settings: Data Classification dialog
- First thing to note, is that there are different options available when compared to the Boolean data type Custom Field like:
Text Format: Defines what the text format will be. The options are plain text, email address, and hyperlink. Use plain text for this Custom Field
Allow values not in the options: When enabled, this allows users to create new metadata values in addition to any default ones that are provided. Also, when enabled, it is not possible to use the Categorization option (Note: using this option can introduce inconsistency in the metadata as any values, like, sales, revenu, revenue, income, etc could be entered, which can devalue the benefit of this Custom Field)
- For this example, disable Allow values not in the options and enable Categorization
- Use Indicates the sensitivity of the data contained within the content as the Description
- With no custom options possible, static values must be provided for users to choose from. Press the icon to add a new value
- For the Data Classification schema, we're going to use values:
Public
Internal
Confidential - In the Value field enter Public and leave the Display Name field empty (more on this field later on in the article)
- Repeat steps 9-11 for the Internal and Confidential values
- Save the settings using the Save icon which will create the new Custom Field
- With two Custom Fields now created the Control Center should look like this:
- If the requirements change, or the fields were created in the wrong order, it is possible to reorder the fields by clicking, and dragging, the icon
Setting Content Metadata Values
Once the Custom Fields metadata schema has been defined, metadata can now be set for the different objects coming from the underlying content systems.
Part of the normal lifecycle of an application, changes will be required. These changes could be the addition of new Custom Fields, the removal of existing Custom Fields, adding new values to fields, etc. Digital Hive enables Administrators with the ability to modify the existing Custom Fields schema to reflect the current business needs.
Creating Rules Based Custom Fields
Imagine a scenario where you are trying to create metadata fields for related Custom Fields. For example, you need to associate content to a Product Line, and then an individual product. Or, a business unit, and a point of contact within that unit. If two Custom Fields were created, Product Line and Product, using the techniques so far in this article, the definitions would look like this:
While these look good and the temptation might be to deploy with this configuration, these field definitions enable an unwanted situation where a user could set inconsistent metadata values. Tents are NOT part of the Golf Equipment product line, but the way that the Custom Fields have been defined allow for this combination of values.
To avoid this situation, Custom Fields can be configured with some 'rules' that drive which metadata values are displayed. Leaving the top level Product Line definition intact, let's delete the Product Custom Field and create a new Custom Field.
- Launch the Digital Hive Control Center by clicking on the user avatar button and selecting Manage Digital Hive
- In the Control Center, expand the Content section using the down arrow beside Content
- Click on the Custom Fields option
- To create the new Custom Field, press the button to launch the Add new field dialog
- For this new Custom Field we'll keep the Text data type
- Provide a Title such as Golf Equipment
- Save the settings using the Save icon which will create the new Custom Field
- To further define the Custom Field, click on the settings icon to open the Text field settings: Golf Equipment dialog
- Enable Advanced mode by changing the setting to
- Change the Show when: value to Field "Product Line" and using the Condition dropdown, select Golf Equipment
- Create selection values for Putters and Drivers
- Save the settings using the Save icon which will create the new Custom Field
- Notice that the newly created Custom Field is indented under the 'parent' Product Line field
This process created a Custom Field that will only display when the Product Line Custom Field value is set to Golf Equipment. To complete the process, repeat steps 4-12 with these settings:
Custom Field Title Data Type Show When Condition Values
Outdoor Accessories Text Field "Product Line" "Outdoor Accessories" Tents, Hiking Shoes
Alpine Equipment Text Field "Product Line" "Alpine Equipment" Skis, Boots
The final result would like this.
When users set the metadata values on content now, the UI would end up dynamically changing the options for Product when Product Line is changed. When editing the metadata, the Product Custom Field isn't displayed until a Product Line option is selected. Selecting Golf Equipment provides an accurate list of Golf Equipment items, while selecting Alpine Equipment provides a different list of items.
What if another level of detail was required? For example, there is a Tent Brands that category that just applies to Outdoor Accessories - Tents. The same process would apply but instead of the Show when value being Field "Product Line", the value would be Field "Outdoor Accessories" with a condition of "Tents". Examining the Custom Fields hierarchy, the result would be:
Editing the metadata values, the UI would only display the Tent Brands field when Tents was selected as the product.
Looking back at the previous examples, you can see that the Product field currently displays the name of the Product Line. In other words, there is some inconsistency with the Product field name due to the way that the Custom Fields were created. To provide some consistency to the UI, the Custom Fields for Products could be changed to a single label. The labels can be modified through this view, without having to open the properties for each Custom Field.
The reason that this is possible, is that the Custom Fields were first created with unique names. When a Custom Field is created, an internal name is created and that internal name can't be modified.
Once the labels have been changed, the metadata schema is a lot more consistent for users. Notice how regardless of which Product Line is selected, the label Product is displayed.
Changing Custom Field Values
Requirements evolve over time, much to the dismay of application administrators. One such change could be the metadata values that are required for a particular Custom Field. When new values are required, this is an easy enhancement to satisfy as a new value can be added to the list of available Custom Field values. If an existing value is no longer required, then that single value can be removed from the list of available values for a Custom Field. When a value is deleted, a prompt will appear to Auto Remove Data. If that value is selected, it will remove the value from all objects that have been configured with that value.
Do NOT use the Wipe Data option as this will remove ALL custom metadata applied to all objects
The challenge with managing Custom Field values is when an existing label changes. For example, working with the previous Data Classification Custom Field, a new value of Restricted needs to be added, and Public needs to be changed to External.
- Launch the Digital Hive Control Center by clicking on the user avatar button and selecting Manage Digital Hive
- In the Control Center, expand the Content section using the down arrow beside Content
- Click on the Custom Fields option
- To further define the Custom Field, click on the settings icon to open the Text field settings: Data Classification dialog
- Press the icon to add a new value
- Provide the value of Restricted
- Save the settings using the Save icon
Now, what is the best way to deal with the label change from Public to External? We could delete the Public value and create a new called External, but this would remove all of the Public classifications from the content and force users to reclassify the data. Instead, we can take advantage of the Display Name field. Within the Text field settings: Data Classification dialog enter External for the Public Display Name.
These changes will modify the schema so that when a user goes to set or view the values, the Data Classification Custom Field will be displayed like this.
If the requirements change again, and Public is the 'new' value to be displayed, removing the Display Name will return the label to Public. If the new requirement is to replace External with "Cleared for broad usage" then once again modifying the Display Name will yield the desired results.
Setting Custom Field Values on Multiple Objects
Usually, contents within a folder contain similar metadata properties. In Digital Hive, it is possible to set Custom Field values at a folder level and then push those values down to the contents within the folder structure. To accomplish this:
- Edit the values on a folder
- Once the values are et, instead of pressing the usual 'Apply' button , press the button to show some additional values
- Select the option
Accept the warning that any existing metadata will be overwritten (if this desired, otherwise CANCEL) by pressing Save Recursively
- This operation could take quite a while depending on how much content is contained within the folder structure
Don't select a starting point that is high up in the structure as the operation could take a long time to complete, and chances are the metadata values will need to be changed afterwards. It is highly recommended to start setting values at lower level folders to promote metadata accuracy
The options in Step 2 above also enable users to clear all of the recursive values as well as to clear the values for the object that is currently being edited.
Once the schema has been defined and matches all of the (current) requirements, it is advisable to take a back up of the schema definition.
It is possible to leverage the exported schema definition as well as the exported metadata values to restore the data on a new server, or on the original server is somebody inadvertently deleted the schema/data.