Posted: 28 Oct 2020 23:05 EDT Last activity: 29 Oct 2020 6:30 EDT
Data Classes: Techniques to surface embedded page data on the top-level page [LSA Data Excellence]
Duplication of data should be avoided. The main risk here is that the maintainers of applications that use this technique easily become confused as to which of the copies of the same data is the "source of truth". This inevitably leads to data loss when a data capture feature is implemented on the duplication target, only for that data to be overwritten when duplication engages.
Where a single member of embedded data from within a List/Group structure (which would otherwise use a Declare Index for reporting usage) needs to be available from the top level (for example, .pyWorkParty(Customer).pyEmail1), it would be better to implement a top-level property (such as .CustomerPartyEmailCopy) as a Declare Expression that is always synchronized with the source of truth. For Properties bound to Declare Expressions:
Activities that reference them as a Property-Set target do not save;
Data Transforms that reference them as a Step Target save, but with a Moderate Guardrail warning;
Sections allow editable controls to be bound to them.
As such, be clear in your property name that the top-level data has a different source of truth. For example, .CustomerPartyEmailCopy instead of just .CustomerPartyEmail.
Duplication is sometimes needed, so by ensuring the duplicate is declaratively synchronized with the source of truth and naming conventions are used that discourage editing the duplicate, they are better assured to always match.
Avoid duplicating large pages of data, consider the following techniques to ensure that only one copy of the page is persisted even when it needs to be duplicated on the clipboard:
Use a "Refer to Data Page" Auto-populate property to gather that page of data by reference; OR
Experiment with the "Do not save property data" option on the Advanced tab of the top-level property.
NOTE: If you optimize an embedded page property that has a 1-to-1 relationship with the top-level (for example, .Income.SpouseIncome.TotalAmount), the column will still be created in the same table as the top-level class. These are just as easily referenceable for reporting as optimized top-level properties, and don't require a top-level duplicate.