Other - Data360_DQ+ - Latest

Dashboard settings

You can associate one or more dashboards with a case store to enable case workers to view visualizations of case data.

Any dashboard can be associated with any case store, however, in practice, it makes sense to associate a case store with a dashboard that visualizes the case store directly or that visualizes an internal database data store containing detail records associated to header records in the case store.

You can configure the following settings:

• Dashboard - Add or remove dashboard associations from the case store.
• Default Dashboard - Select the dashboard that will first appear when case workers use the case store.
• Case Selection Search Screen - Select the screen that a case worker will use to select a destination case when records are moved between cases, using the Move feature on detail records or the Merge feature on header records.
• My Cases Search Screen - Select the search screen that case workers will be able to use to search for cases within their My Cases repository. Users who have been assigned the role of "Case Worker" will not be able to see all of the search screens that have been created for a case store.
• All Cases Search Screen - Select the search screen that case workers will be able to use to search for cases within the All Cases repository, provided that they have access to it. Users who have been assigned the role of "Case Worker" will not be able to see all of the search screens that have been created for a case store.
• Environment Groups with Access to All Cases - Select which environment groups have access to the All Cases repository. Only administrators and users within the selected environment groups will be able to access the All Cases repository.

Data retention settings

You can use the Data Retention settings to set a time limit on how long a case store will retain incoming data. This can be useful in cases where data becomes irrelevant after a certain amount of time has passed.

• Retention Period - Define the length of time for which a case store will store data. Data retention applied at the case store level will override Retention Period settings at the environment level made by your administrator.
  Tip: Time is always calculated from the time data is loaded into a data stage.
• Period Precision - Define the precision at which a Retention Period is applied.

For example, if a case store's Retention Period was set to 1 year and its Period Precision was set to Month, the retention period would span one year back from the current day, plus the remaining days to get to the beginning of the month.

Retention example one

• The current day is 6/5/2016.
• The Case Store Retention Period is set to 1 year.
• The Period Precision is set to Month.

In this example, the system would first look back one year to 6/5/2015. Then, since Precision is set to Month, the system would go to the beginning of the month, to 6/1/2015. At this point, any case that was loaded into the case store before 6/1/2015 and had reached the terminal state in its workflow would be removed.

Retention example two

• The current day is 6/5/2016.
• The Environment Retention Period is set to 1 year.
• The Period Precision is set to Quarter.

In this example, the system would first look back one year to 6/5/2015. Then, since Precision is set to Quarter, the system would go to the beginning of the quarter, to 4/1/2015. At this point, any case that was loaded into the case store before 4/1/2015 and had reached the terminal state in its workflow would be removed.

Retention period over time

Retention period data flush

Over time, data will be flushed from case stores based on the specified data retention settings and whether a case has reached the terminal state in its workflow. For instance, in the example above, cases from Load 1 on 4/29/2015 that have reached their terminal state are flushed on 5/1/2016. This is because a 1 year retention period with Month precision is used, so, on 5/1/2016, the 4/29/2015 Load falls outside of the calculated retention period (which spans from 5/1/2015 to 5/1/2016).

Alternate retention policies

In addition to basic data retention functionality, you can also create alternate retention policies for case stores, using a retention class.

To do so, you'll need take advantage of the RetentionClass field that the system automatically assigns to all case stores. By default, records in this field are assigned a value of null, which means that by default, all records in the case store will use the data retention settings that have been applied at the case store level. If you populate the RetentionClass field with Strings within the Analysis, however, you can use these same strings as retention classes here in the Other tab and define unique retention policies for each one.

Alternate retention policy example

In this example you want to create two separate retention policies based on criteria from the fields that comprise a record. To do this, in an analysis, create a new column in a node preceding the case store output node, using an expression that controls the field's value.

In this example, a Select node precedes a Case Store Output node. Within the Select node, a new column is created using the expression:

IF(claimAmount >= 3000, ‘RetentionClassA', ‘RetentionClassB').

Within the Case Store Output node, the new column is mapped to the RetentionClass field.

After setting up the analysis, we can then go into the case store's Other tab and create an alternate retention policy for each newly added class. This would require giving one policy a retention class named "RetentionClassA" and giving the other policy a retention class named "RetentionPolicyB". Each policy could then have unique Period, Precision, and Period Precision properties.

With alternate retention policies set in place, system retention processing would now treat records within the case store individually. Records that did not fall into an alternate class would have a default RetentionClass value of null and thus inherit the retention settings of the case store.

Background processing settings

You can use scripts to run as background processes when a case store is executed. Executions can be performed manually, or they can be scheduled.

Script syntax

The general script syntax that applies throughout the product, does not apply for case store background processing. Throughout the product, Script syntax follows the general format of referencing inputs to the script with the input keyword and outputs of the script with the output keyword. This syntax differs for case store background processing.

To reference any case store field in your script, regardless of whether it is an input or an output, use the caseData keyword, for example:

if(caseData.Age <= 30) {
 caseData.Age_Bucket = ‘Under 30';
}

The script checks each record's system field Age, to evaluate whether its value is less than or equal to 30, and assigns a value of 'Under 30' to the record's Age_Bucket field to the corresponding records.

JavaScript processing time limit

To prevent infinite loops from occurring, Data360 DQ+ has a time limit for the processing of JavaScript in case stores. The maximum time is 10 seconds for each record.