Fields - Data360_DQ+ - Latest

Data360 DQ+ Help

Product type
Product family
Data360 DQ+
Product name
Data360 DQ+
Data360 DQ+ Help
First publish date

The Fields tab allows you to view all fields that are built into a case store and create or edit new fields to hold the contents of header records pushed to the case store.

In addition to the Name, every field definition includes an optional Description. This displays as a tooltip when you hover over the relevant field column header, in dashboard and case management search screens.


Default fields

Every case store comes with the following default system fields:


A number by which to identify case header records within the case store.


A completely unique ID that can be used to identify a case header record within a case store, or between case stores. Can also be used to tie detail records from an internal database data store to cases.


A code set where values can be 'System' (0) or 'User' (1).


A code set where values are defined in and synced with the case store's workflow. Values represent states a case can transition through as it is processed.


A number representing the age of a case in days.


The name of a Data360 DQ+ user who owns the case.


A code set where values can be 'System' (0) or 'User' (1). Indicates if the last transition was performed by the system or a user.


A codeset with values defined by the user.


A codeset with values defined by the user.


The ID of the queue that the case is in.


The retention class associated with a record (i.e. a case). Used in the case store Other tab to set up retention for individual records. If a record has a null RetentionClass, the record will inherit the case store's data retention settings. If a record has a null RetentionClass and no case store data retention setting exists, the record will stay in the case store forever.


The date a case entered the terminal state in the case store's workflow.


A string field containing the last note that was added to a case.

You can display this field in the result fields of a search screen to view the most recent notes on multiple cases.

Note: For existing case stores, this field is added the next time a user opens the case store for editing, and the field is saved when the case store is saved. The field is completed only for cases where a note is added or edited after the field is added. For cases that already have notes, this field is not updated until the last note is edited, or a new note is added.


A DateTime field containing a timestamp of when a case was most recently updated by a user. The field is updated when a case field is updated, and when a note or attachment is added to the case.

You can display this field in the result fields of a search screen to view the most recently updated cases.


A DateTime field containing a timestamp of when a case was most recently updated. An update can occur as a result of a user action on a case field, a system event, or when a case store script runs.

LastSystemModified is a hidden system field. It is not displayed in the Fields tab, but you can select this field for display in the result fields of a search screen.

This field is also available in the internal database datastore.

The recCount field

When a case store of the type Case contains record(s) from Data Store(s) is associated to detail record data stores in its workflow, the system adds a new field to the case store called recCount (with a number appended to the end*). This field contains numeric values that represent the number of detail records a given case has associated to it.

*The number that is appended to the end of recCount represents the associated data store for which the counts apply to. This becomes relevant when a case store is associated to more than one data store.

Creating new fields

In addition to the standard fields that are part of every case store, the Fields tab allows you to add new fields. This needs to be done for each field that is part of the header record set that is pushed to the case store via analyses.

Tip: It is recommended that you give these fields the same names and data types as the input source fields.


Creating new fields via import

You can use the Import Fields feature to create all of the necessary header record fields from a data store, within your case store. Imported fields will have matching names, field types, and all other configurations.

Semantic type

Applying a semantic type to any type of field can help to further categorize the field's content and enable additional functionality throughout Data360 DQ+.

For example, adding the Airport semantic type to a string field containing airport codes could help to categorize a dataset containing unlabeled airport codes within an analysis.

Displaying URLs as hyperlinks in dashboards with semantic type

As an example, the URL semantic type can be applied to string fields that contain string values which should be treated as URLs. Doing so will actually cause the URL field's strings to be displayed as clickable hyperlinks in data grid dashlets. If the URLs are valid, clicking on these links will open the associated website in another browser tab.

Shortened hyperlinks

You can also create shortened hyperlinks and associate them with the appropriate URL to make, for example, lengthy URLs easier to handle. The shortened hyperlink is displayed and clickable in a dashboard or search screen, taking you to the original target.


  1. Select an Analysis data stage in the relevant data store.

  2. Click Edit then select the relevant node, if required.

  3. Create a new column with the appropriate name.

  4. Ensure that you have selected the correct semantic type for the field, for example, URL.

  5. Enter the full URL and shortened hyperlink using JSON:

    {"url":"https://example/long/url","label":"Shortened hyperlink"}

    Where "Shortened hyperlink" is the name you want to represent the URL.

Using the above example, the dashboard and search screen will display "Shortened hyperlink", which when clicked, will go to https://example/long/url.

The shortened hyperlink values can also be dynamic, for example, "December 2020 Control Report", "January 2021 Control Report" and similar. In this case, the hyperlink is made up of one column value while the URL would navigate to another.

Encrypted fields

Specifying a case store field to be encrypted will cause the field's records to be encrypted in storage.

Any user with access to a case store can encrypt a case store field if it has not yet been encrypted.

Once a field has been encrypted, only administrators and users with Administer or Manage Security permission to the case store will be able to modify the field's encryption settings.

Note: If changing field encryption, a migration job will be performed upon save to encrypt/decrypt the case store's pre-existing data.

Tokenize fields

When tokenization is enabled and the Secure check box is displayed, a Tokenize check box and Tokenize Data Element Name text field are available.

When Tokenize is selected:

  • The Tokenize Data Element Name text field is enabled.

    Enter the appropriate data element name.

  • The Secure check box is selected and disabled from further changes.

    The remaining secure fields are still enabled.

Note: Tokenized fields are supported when the deployment has an integration with a tokenization provider enabled.
Note: You can only transition from, for example, encrypted and tokenized to simply encrypted or tokenized, if there is no data in the case store. Otherwise an error is displayed.

Secure fields

Specifying a case store field to be a secure field will cause the field to be masked throughout Data360 DQ+.

Masking is defined through use of the following parameters:

Secure field parameters

  • Hide this field when user does not have access - Users who have access to a Secure Field are those who belong to the environment groups chosen in the secure field's Environment Groups parameter. If this box is checked and a user who is not part of the secure field's environment groups uses the case store, the secure field will not be visible to them.If this box is left unchecked, all users will see the secure field, but its contents will always be masked.
  • Mask - Determines how the secure field will be masked.
  • Mask Pattern - If the User Defined Mask option is selected, you can use Mask Pattern to define a preset or custom mask for the content of your secure field.
  • Display Mask Pattern - If the User Defined Mask option is selected, you can use Display Mask Pattern to define a preset or custom display mask for the content of your secure field.
  • Environment Groups - Users in a secure field's selected environment groups will be able to see the field with its contents initially masked, as per Mask settings. Unlike other users, however, users within the selected environment groups have the option to unmask secure fields and see their actual contents. Unmasking can be performed throughout the product, at the individual record level or in bulk via Unmask All. If a user is not in a secure field's selected environment groups, they will either see the field as always masked or they will not see the field at all. This will depend on whether Hide this field when user does not have access is selected.

Any user with access to a case store can make a case store field secure, if it has not yet been marked as secure.

Once a field has been marked as secure and the change has been accepted, only administrators and users with Administer or Manage Security permission to the case store will be able to modify the field's security settings.

Note: If a field is set as secure, all the security settings will carry over when the field is used in other data stages.

You will see the effects of a secure field in the following places:

  • When using the case store in an analysis and view its contents in a sheet.
  • When viewing a secure field within a case store search screen. Here, you will also be given the option to unmask the value of a masked secure field, if you have been given permission by being placed in the secure field's environment group.
  • When working with dashboards and the visualizer. Here, some functionality will give you the option to unmask the value of a masked secure field, if you have been given permission by being placed in the secure field's environment group.

Code sets

A code set may be used to create a more readable display value for fields that contain non-human readable codes. Once a code set is created, its effects will be seen throughout the system, such as when the field's values are displayed in a search screen or a dashboard.

Display Name

This is the value that will replace the raw value that is actually stored in the case store field, when the field is displayed throughout the system.


This is the raw value that will be replaced by the display name. Typically, it will be a non-human readable code.

Code Set example

Assuming a field that contains a set of 3 non-human readable codes, you could create a code set for each one, in order to produce a more user-friendly display.









Data Set with Obscure Codes

Assuming you created the following:

Display Name: Dental, Value: GHTY45RD

Display Name: Medical, Value: JJAK09WQ

Display Name: Home, Value: QWRE21PP

"Dental", "Medical", and "Home" would be displayed for GHTY45RD, JJAK09WQ, and QWRE21PP (respectively) whenever these values were encountered.

Computed fields

Fields that are dependent on other field values, and are updated as those values change, are know as Computed Fields. They are displayed, for example, as the fields of a column in a Results grid.

To create a computed field, you have to configure a Computation Expression.

Computation Expression

A Computation Expression is defined as follows:

  1. Navigate to the Fields tab of the relevant case store definition.

  2. Click the Edit button, positioned to the right of the Computation Expression field.

  3. Enter the expression, ensuring it complies with the following:

    • The expression can only be configured for non-system fields of a case store.

      If a system field is selected, the Computation Expression field does not display.

    • The expression is restricted to the following numeric and date data types:
      • Integer.
      • Big Integer.
      • Float.
      • Decimal.
      • Currency.
      • Date.
      • Date & Time.
      • Time.
    • The functions available for the expression are:
      • Simple arithmetic and logical operators.
      • A new COMPUTEIFCASERECORD function.
    • The expression can use values of case store fields, but should not use other computed fields.

      This is because the order of computation is dependent on the order in which fields are defined in the case store.


This function allows you to carry out several aggregations on the fields of an associated data store, when they satisfy the specified condition. This is designed to make sure that computed field do not have to be computed during the execution of an analysis. It also allows the values to be updated, when the aggregated data store values are changed. This is an example of the function:

COMPUTEIFCASERECORD('Lower Rated Canadian Players DB DS', 'Rating', 'Gender = \'M\'', 'sum')

The parameters are:

  • The first parameter specifies the data store where records should be aggregated. This name is the name given to the data store node in the case store workflow diagram.
  • The second parameter is the name of a data store field which should be aggregated.
  • The third is the condition which should be satisfied if a field is to be aggregated. If aggregation should be performed unconditionally, then you need to specify ‘1 = 1’ for the condition.
  • The fourth is the aggregation to be performed. The supported aggregations are:
    • sum
    • min
    • max
    • count

Computed Field Updates

Computed fields are updated in response to three events:

  • After the case store data is finished loading.
  • When one or more cases are changed by a user through edit, mass edit, take or transition actions and similar, when the case data is updated.
  • When the data store record associated with a case is changed through the Records tab, using actions such as edit, mass editor move. In this scenario, the case store search screen is refreshed to show updated case computed values.

Computed fields evaluation is done for each record separately, by executing the computation expression. If COMPUTEIFCASERECORD is present in the expression, aggregation is translated into SQL and pushed for execution to the database. This is the reason why the types of supported aggregations are limited to those supported by SQL. To minimize the number of database queries, these computations are performed in batches of 100.