Linkage fields
Each Linkage Project has an overview of all relevant linkage fields that includes:
- The cleaning and standardisation transforms to run on source data
- The matching strategies the fields are used in
- The mapping of each field to the Data Sources of the attached Event Types
- Aliases (or name overrides) for the linkage fields or the data source mappings
This overview is available by clicking the Settings link on each Linkage Project page and then clicking the Linkage Fields link.
Use this overview to validate all expected linkage fields are present in matching strategies and map correctly to all data sources.
Cleaning and standardisation
The system is preconfigured with a standard set of cleaning and standardisation transforms for each field. When a new linkage project is created, these transforms will be used.
However, the set of transforms for each field can be overridden for each linkage project, if required. Clicking on the Transforms icon in the options column of the desired field will display a page that allows the user to customise the transforms to their specific needs.
The default set of transforms can be edited, reordered or completed removed. The list of transforms available mirrors that of the Envelope Builder.
These cleaning and standardisation transforms are applied directly to data that is ingested directly as a data file or via a connected data source such as a database. They are also used to determine the transforms to include in the Project Definition File that can be downloaded directly for each data source associated with the linkage project.
Cleaning and standardisation transforms are not applied to data ingested as an Envelope. It is expected this data has already had those transforms applied.
Field name overrides
The names of each linkage field can be given an alias, if desired. This is particularly useful for PPRL projects using binary fields or even clear-text projects using generic text fields. The aliases are then displayed throughout the system (matching strategies, reports, etc).
Additionally, you can assign an alias to any linkage field that maps to an attached data source. This is specifically used to change the name of the source field name in the Project Definition File, to allow finer control over automatic field mappings by the Envelope Builder. This is particularly useful in PPRL projects that might share the same default Import Format but the names of the source fields differ.
Composite fields
Composite fields are a concept used explicitly for the creation of Project Definition Files. It allows multiple fields from a data source to be combined and stored into a single linkage field in LinXmart.
The list of composite fields defined are shown beneath the list of linkage fields. Below is an example from a PPRL project, which combines Given Name and Family Name from the data source into a single value for the Text Field 1 linkage field.
Drilling into the detail for this field by clicking the Edit icon in the Options column of the table, you can see the individual transforms that are run on each source field before they are combined.
In this case, this composite field is used to define a single blocking field to use in a matching strategy. This eliminates the need to ingest every variable directly into its own linkage field, unless it is used as a matching field in a match strategy.
Use composite fields in PPRL projects to transform and combine blocking fields at the data source, unless every field in the block is also a matching field.