User Guide

The following are frequently asked questions regarding the creation of tags, terms, and data classes:

Should we convert our entire business glossary or data catalog into tags, terms, and data classes?

If your organization has a business glossary or data catalog, then we recommend that you only import privacy-relevant information from it. We do not recommend bringing all content into the platform.

Should we assign the codes used with our existing business taxonomy to tags, terms, and data classes?

In order to align the use of these entities across the organization in a consistent manner, and also to relate to similar entities defined as part of data governance, you might have already defined a comprehensive taxonomy of these entities and assigned each entity a unique code to identify them in your organization. An example code might be DS993AI - Data Science and AI.

In the platform, such a code can be applied as a tag on a business entity to allow users to search by the code. For example, you can create and apply a tag like DS993AI - Data Science and AI to entities.

Should we apply tags and terms at the top level (datasets) or the lower levels (assets and fields)?

You can apply tags to most objects on the platform, including datasets, assets, fields, projects, and more. You can apply terms to data classes, assets, and fields. When deciding at which level to apply tags and terms, consider how your organization will use them within the platform.

For example, if you need to control access to data by line of business, such as HR or Finance, then apply line-of-business tags to datasets and projects. This allows you to form policies that match concepts between projects and datasets at a high level. It also allows you to more easily manage policy triggers.

Another example is if users in your organization have a need to search for related fields across assets and datasets. If so, apply tags at the field level. Finally, if you need to express rule conditions down to the field level, you should also apply tags and terms to fields.

Should we model hierarchy with tags or terms?

In general, be prudent when venturing into deeper levels. Consider applying tags and terms only at the highest level in which they are required, and proceed one level downwards only if tags and terms applied at the current level are unable to satisfy the rule conditions required. On the platform, assets and fields do not inherit the tags and terms associated with their datasets.

However, certain business concepts might require that you implicitly apply tags and terms at a lower level to correspond with those at a higher level. In this case, if you apply tags to datasets, then you should also apply these tags to assets and fields since they are part of the same dataset. Similarly, if you apply a term to assets, you should apply the same term to the fields in those assets.

How should we represent hierarchical business concepts?

You might have certain business concepts that are hierarchical. For example, their definition might include having three levels: Level 1, Level 2, or Level 3. When working in the platform, you will want to flatten these out. For example, a business concept for Customer Account Number, might include:

You can represent this in a single tag on the platform as Personal Data → Customer → Customer Account Number. Splitting them into three tags might not work well in all cases, and you will need to make sure entities are not stuck with orphaned tags. For example, an L2 tag without an L1 tag.

Ask yourself: