Release Notes

Release Notes have now moved to a new home at /release-notes

…

V6.15 Release Notes – 24th January 2023 

The following lists the key changes that have been implemented since the last v6.0 Release notes. 

1. Enhancement. A new Normalisation Rule has been introduced called [Format Alphanumeric]. If this is set, then any non-alphanumeric characters within the field specified, will be removed when creating the Blocking Key.  

Example: 

The Blocking Key for a Target Object could use the First Name and Last Name. Within the Rules tab of the Target Object settings, you can select the First Name and Last Name fields and specify the Rule Type as Format Alphanumeric. Any non- alphanumeric characters will not be used when generating the Blocking Key for Normalisation purposes. 

1. New Feature. QuickMerge API (REST API) enables external systems to request the merge of 2 or more records via Salesforce Id or External Id values. 

V6.0 Release Notes – 29th November 2022

The following lists the key changes that have been implemented since the last v5.0 Release notes.

1. Enhancement. New Match Type Rules have been added, Key Approximate and Deterministic Strict.  Key Approximate allows for the a slight variation in the field value for matching to continue. This can be set in the Target Object Rules tab. Deterministic Strict will allow the matching rules to continue , if one of the field values is empty, i.e. they do not have to be the same.
2. Enhancement. Matched Record Group Page now displays a Merge Now button. The Matched Record Group page allows you to datasteward possible record matches manually. You can now also click on a button for the matching and merging to happen automatically. This will save time if the records are definite matches.
3. Enhancement. Merge Analysis. Within the Master Record, after matching and merging, you can now see the Merge results and how the Master Record field population has been determined.
4. Enhancement. Merge Result Rollback. You can not only see the Merge Analysis, but if you wanted to revert a value or values you can do so by selecting Merge Rollback.
5. Enhancement. Attribute Group Templates now allow multiple type fields.

….

 

V5.0 Release Notes – 29th October 2021

The following lists the key changes that have been implemented since the last v4.31 Release notes.

1. Enhancement. When upgrading to the v5.0 package, the Platform Cache Partition has a free allocation of 3MB auto-allocated. You can validate this by navigating to the Setup Menu and searching for Platform Cache.
2. Enhancement. There is a new selection within Attribute groups, which when selected will allow the most popular value(s) found within the Source Records to win and be promoted to the Master Record. This selection is within the Attribute Priority type “Frequency”. The winning record for the group is calculated as the one with the most common / frequently occurring set of values for the fields marked as required in the AG across the records being merged. In such a case there will be more than one record which share the same values, so the actual winner is determined by the second factor priority.
   Example:

5 Accounts being merged. The Billing Address Attribute Group has City and Country fields marked as required. Second factor is created date.

(a) 3 Accounts have London and UK

(b) 1 Account has London and GB

(c) 1 Account has Edinburgh and UK

The most common is (a) and the actual winner for the group is the one with the most recent created date.

3. There is now the facility to be able to setup an Attribute Group Template which will override other values within Source Records by setting a ‘Primary Override’. An example of this would be if you had a number of records for the same person, but they have different addresses. If one of the records indicates that the address is a main address, then this will be the one displayed on the Master Record after Matching and Merging. If more than one has a main address indicator, then the one most recently created will be used.
4. There is now a skipped MDM Status which allows records to be identified and removed from repeated attempts to match groups where size exceeds [Max Records Per Group] or [Max Records Per Iterable Cycle].
5. There are two new fields within Target Objects, Matching Settings 1) Group Size Rule optimisation. This allows larger groups to be processed using Key and Deterministic matching rules only 2) Group Size Skipped Status. This allows larger groups to be processed but simply moved to skipped.

….

V4.31 Release Notes – 10th June 2021

The following lists the key changes that have been implemented since the last v4.18 Release notes.  

1. Enhancement. A new field has been added within the Attribute Group Settings, in the Data Sources section called ‘Attribute Group Sub Group Priority’. Where sub groups exist, you can set the field value which should be used to update the Master Record with the most recent update. 
2. Enhancement. API upgrade to v51.0. 
3. Enhancement. Data Source settings has a new field in the Matching section called ‘Check for Matches on Record Creation?’. This is for External Data Sources only and applies matching logic when Data Source records are created. 
4. New Normalisation Rule. The format for Normalisation has been extended so that Umlauts are removed. E.g  Ä –> Ae. 
5. Settings Tab. The Settings tab has been renamed to MDM Settings.

…. 

V4.18 Release Notes – 23rd November 2020 

The following lists the key changes that have been implemented since the last v4.12.1 Release notes. 

1. Target Object Matching Settings. If the ‘Is active on Record Creation?’ checkbox in the Target Object Matching Settings is set to TRUE , then if a deleted record is undeleted, the ‘Is Active for Matching?’ field in the record will also be set to TRUE.
2. Matched Record Groups. If there are some Matched Record Groups and subsequently one of the source records within the groups has been deleted, then the Matched Record Groups relating to the deleted record will no longer be included.
3. Record Create Page. If the name field exists as a filter on the Matching Test tab, then when you create a new record, the name field will be populated with the filter value.
4. Matching Test. The filter fields no longer accept characters such as @;.

….

V4.12.1 Release Notes – 17th September 2020  

The following refers to 2 key changes that have been implemented since the last v4.5.4 Release notes. 

1. Deferred Correct Mode: Where an existing Master Record exists with associated Source Record(s), if a specified field value in an Attribute Group is changed on the Master, this will be updated in the Source Record. In order for this to occur, the Source record must have the same original value. When the Merge and Synchronisation processes are run, the update will take place on the Source Record. This will ensure that all records within the group have the most up to date information. 
2.  Merge Analysis (Attribute Groups Only): There is now a new button on the Accounts page layout which when selected, will display the most recent and previous Attribute Group updates. This information is only displayed in the Master Record where it is most relevant. The Source Record, if you select this button, will display a message stating this isn’t the Master Record.  

In order for this information to be displayed there are two settings that need adding in the Merge Settings section within the Target Object ;’ Is Attribute Group Only?’ and ‘Master Field Map FIeld Name’ = System Master Field Map.  

….

V4.5.4 Release Notes – 25th March 2020

The following lists the key changes that have been implemented since the last v4.3 Release notes. 

1. DataSource ‘Is Active for Reparenting Field Name’ can be set to a text field which can be indexed. Within the settings area of clearMDM, the Datasource has a field which you can select the field name to reference for ‘Is Active for Reparenting’. You can now create a custom field which can be indexed so that when the reparenting job has run, a value of true or false will be entered in the custom field when added to the page layout.
2. API version upgrade to 48.0 – Sprint 20.
3. Lightning UI now contains Kanban views, for example if you go to the Batch Job Runs tab and select the Kanban view you can see the status of all the jobs that have been run.
4. There have been a number of enhancements to the Multiple Target Object feature.
5. Trigger functions implement CPU usage.

….

V4.3 Release Notes – 18th February 2020  

The following lists the key changes that have been implemented since the last v4.0 Release notes. 

1. Multiple Target Objects per Salesforce Object. Up until now you could only setup one Target Object per SObject Type. There is now the ability to be able to setup more than one and specify the record type it applies to. This means that if you have more than one record type within an Object, you can now setup separate matching and merging rules. For example, in Accounts you may have Business Customers and Suppliers, and when creating a Master Record do not want to mix the record types together. By setting up a separate Target Object per record type you can specify a different Blocking Key for each one so that when the jobs are run, the records will not be matched and merged as the Blocking Key will not be the same.  What this also means is that you can setup Attribute Groups for individual record types if you did not want the same merge rules to apply, or you can apply to all record types if you wish. 
2. Maths operators on Merge. Within the Attribute Groups settings there is a new checkbox field called ‘Is Sum Numeric Values?’ If this is set to TRUE then the merge engine will sum all values for all valid Source Records when populating numeric fields on the Master Record. For example, you might have a total spent value on a Customer record so when the Master Record is created, all values within that field on each matching record will be added together and populated on the Master Record as one value.  
3. Search before create for Contact. When creating a contact from an Account record, the parent Account is pre-populated in the New Contact form. 
4. Reparenting. The following can now be setup to be reparented within the Datasource settings. Reparenting happens at the end of the Job run process and will take the details from the Source Records and append to the Master Record, so that the information is kept all in one place: 

• Notes 
• Attachments 
• Orders 
• Files 
• Leads 

To setup reparenting rules, you need to go to the Data Source settings, select the Data Source the reparenting relates to and within this you can go to the Child Object Relationships section. You can tick the Reparent? Checkbox or select the Master Record Id Target Field Name against the child SObject type you want to reparent.  

Within Target Object settings, the Is Active? for reparenting checkbox needs to be ticked to ensure the action is executed when the jobs are run.  

….

v4.0 Release Notes – 22nd October 2019 >

1. Attribute Groups. A new field has been added called ‘Source Record Update Mode’ which provides 3 options; none, correct or overwright. If ‘none’ is selected, then the Attribute Groups update the Master Record as per the set configuration. If ‘correct’ is selected , then where an existing matched and merge group exists and a field on the Master Record is updated, the update will be fed down to the Source Record the value originated from. An example would be the address fields. An attribute group template will be set up and referenced by the address attribute group for the datasource in question. If the house number is updated in the Master Record then this will also be updated in the source record, but only the source record the value came from. This occurs in real-time.  If ‘overwrite’ is selected, then when a Source Record is updated, once the jobs have run, the Master Record will be updated and also update other Source Records.
2. MDMGeneratedDataSweeper. Up until now, you can set the number of days in application settings, logs should be kept for before being deleted. An Apex Class is then scheduled to delete these logs (audit, blocking key process requests and data services logs). Rather than these logs being permanently deleted they are now archived for future reference.

….

v3.43 Release Notes – 16th July 2019 >

1. Blocking Key Process Request (BKPR). A new enhancement has been added to the Blocking Key Process Settings (located in Application Settings) called ‘Is Isolated?’. If this checkbox is ticked and set to TRUE, a new Processor instance is created for each call to the BKPR Action, or direct insert to the BKPR Object. Enabling this setting increases performance at the cost of increased AsyncApexExecutions consumption.
2. Attribute Groups. Within Attribute Groups (fields section), a new setting has been added called ‘Attribute Group Secondary Required?’. When this checkbox is ticked and set to TRUE, if there are no valid record values within the specified target field names, the invalid ones will be displayed in the Master Record. The validity of the target fields are determined by custom formula fields.

….

Summer ’19 (V3.40) Release Notes – June 21st 2019 >

1. Attribute Groups. Sub Groups no longer default to the winning Attribute Group when there is no valid record. A couple of new settings have also been added, ‘Is Blank Update Allowed?’ This is a checkbox and if it is set to TRUE then the merge engine will blank Master Record fields if no valid source record exists on a mapped Attribute Group Data Source. ‘Allow invalid if no valid records?’ is also a checkbox and if this is set to TRUE then invalid source records are processed if no valid record exists. This setting overrides the ‘Is Blank Update Allowed?’ setting.
2. Blocking Key Process Request. A change has been made so the processor now checks for the queueable limit and logs, which in turn avoids an exception.
3. Target Object Settings. The match type was lost when an active change was applied in Classic only. This no longer applies.
4. Data Service. New settings have been added to allow Data Services to run in parallel when processing. The ‘Is Isolated Processor?’ checkbox if set to TRUE, thee the Data Service Update Requests for the Data Service are processed by a separate processor instance. This setting provides control over parallel DSUR processing for Transactional Data Services only. ‘Isolated Connector Calls per Cycle’ determines the number of DSUR processed per Isolated Processor cycle which is calculated as [Max Records per Connector] multiplied by [Isolated Connector Calls per Cycle].

….

v3.37.4 Release Notes – April 25th 2019 >

The following lists the key changes that have been implemented since the last Spring ‘19 Release Notes. 

1. Record Reparenting. Within the Reparenting Settings section a new field has been added called ‘Is Recently Modified?’. When this is ticked then Source Records are processed by the Reparenting Job only based upon the date range set in the Application Settings (Resent days Limit). 
   
2. Master Record. The Master Record can now be cloned rather than created from new or an existing record. This is done through the Target Object Settings and selecting the ‘Clone Master Record for New Groups?’ checkbox. Once this is selected, the identified Master Record for new Matched Record Groups will be cloned to a new Source Record. This setting is overridden by the ‘Create Master for new Groups?’ Setting.
3. Standard to Standard Object. There is now the ability to be able to Match and Merge records that are not in the same Standard Object, an example being Leads to PersonAccounts. How to set this up in detail is described here. 
4. Conversion of a Lead to an Account Record. Where a Lead is not Matched to an Account record, when the conversion job is run this will convert the Lead to an Account Master Record.
5. Synchronisation of Lead records to Account Records. Where a Lead is a source record and any changes are made to the monitored fields, then when the synchronisation job is run this will update the Master Account Record with the changes.
6. BKPR. If the Blocking Key Process Request is run concurrently, only one will be processed and the other will be stopped. 

….

Spring ’19 (V3.28) Release Notes – February 18th 2019 >

1. Merge Engine. Attribute Group Sub Groups. This new capability allows Data Sharing Consent flags to be taken from other matched records within the group that share common attributes with the Attribute Group Winning Record. For example, divisional (or channel-specific) email consent flags could be taken from records that provide a trusted source for a given division and have the same Email address as the winning record for the Attribute Group (from which all other attributes on the Master Record would be populated).
2. Merge Engine. Attribute Groups. It is now possible for the merge engine to blank Source Record field values when populating the master – this is typically required where a unique constraint exists on the field.
3. Matching Engine. Previously it was possible for a Matched status Source Record flagged as a standalone Master Record to be reverted to No Match status where no existing matches for the record are activated for a given matching cycle. This limitation has now been addressed.

….

v3.2 Release Notes – January 31st 2019 >

1. Individual Object. The standard object, ‘Individual’ was introduced for data protection and privacy within Salesforce. Its purpose is to store a person’s data preferences with regards to how their data is stored, used and shared. clearMDM supports this feature by applying settings within the Target Object, which will allow the individual record to be updated to the Master Record after Matching and Merging based upon the following factors:

Data Privacy Record Retention Policy (Newest, Oldest, Keep) determined by the Data Privacy Record Retention Date Field (Created Date, Birth Date, Last Modified Date, System Modstamp, Last viewed date).

2. Blocking Key Process Request (BKPR). Within Application Settings, Blocking Key Process Settings, there is now the ability to be able to set the BKPR to run up to 10 processors in parallel. Each processor executes in 2 phases with the Match, Merge and Synchronisation as phase 1 followed by Reparenting. Reparenting enables identified matched records, determined by the Blocking Key, that have transactions recorded to be updated to the Master Record. The Master Record then has all the transactional history from the Merge Source Record(s).
3. Data Quality Rules. It is now possible to add a negative value as a Data Quality Rule as well as a positive value.  This can be done through Settings, Data Quality Rule Set Settings. The value field now contains some negative values which can be added to the Quality Rule setup and which will help determine the Quality Score Metric in the Target Object.
4. Cross Field Merge. When setting up an Attribute Group Template, you can now specify whether unique values only are used during the Merge process. An example of this could be a duplicate address. If Records have the same address, when the Master Record is created a duplicate value of the same address will not be merged to the Master Record.
5. Multi Select Picklist. Attribute Groups now support Merging to the Master Record of all values from Multi-Select Picklist fields for all valid Source Records.  When Records are Matched, and they contain a Multi-Select Picklist with multiple values, when the Master Record is created, these values will be Merged to display within the Master Record.
6. Settings API. The ability to be able to setup the configuration settings within clearMDM from a source Salesforce org and deploy to one or more target Salesforce org (s). Reducing the time to setup configuration manually and also alleviating any human errors. Further details about this and how to implement can be found here.
7. MDM Reset Reparenting. After the MDM operations have completed and where transactions (for example) have been reparented to the Master Record from the Source Record, if the Master Record is reset using the MDM Reset button, this will now remove the reparented transactions and return to the source record(s) in question.

….

v3.0 Release Notes – August 10th 2018 >

1. Data Services. A new feature within clearMDM that provides the ability for record cleanse, verification or improved quality services via the use of external API connectors and supports the Google Translation API connector using a separate package. This enables translation from the source language to a target language with over 100 languages at various levels available. Some of the significant features of Google Translation API connector are:

• Provides a speedy and easy interface for different language conversation/translation.

• Converts about 100+ languages using Translation API.

• Identifies the local language in your native language without any errors.

A significant step for clearMDM and will prove to be a useful  API connector.

2. Normalisation. It is now possible to update fields where there has been an abbreviation entered, so an example could be Street’ abbreviated with ‘Str’ or ‘St’. By setting up a custom setting list of match and replace values and referencing that via a lookup rule, the value of the field will be replaced with Street (in this example) where these abbreviations are used. Within Develop, Custom Settings there is ‘Replace Values’ where you can add a list of values to be replaced.

3. Merge. Within the Attribute Group Settings there is a field value for Priority Type. This can be Newest, Oldest or Dynamic which is based upon the operational source system timestamp. We are introducing a new priority which focuses specifically on date fields, so you will be able to pick the Newest or Oldest and the field this needs to relate to.

4. BKPR. A new feature has been added called Blocking Key Process Requests. Within the new tab, you can setup a request based upon the Blocking Key Value. Any record with that blocking key will then enter a process queue if any changes are made, based upon the MDM status. This in turn means any external systems will be updated with the new information thereby creating a realtime MDM environment.

….

Spring ’18 (v2.26) Release Notes – April 14th 2018 >

1) Cross Field Merge. The Merge operation now supports cross-field merge. A generic Attribute Group Template can be defined (e.g. Address, Phone or
any other grouping) – with placeholder fields. Attribute Groups (e.g. Billing Address, Shipping Address) can then be mapped to the template (field-by-field) and the population order set; i.e. the order in which the Attribute Group fields will be populated on the Master Record.

The Merge engine will gather all mapped values in priority order. The
highest priority values are then added to the Master Record fields within the
first Attribute Group (by population order) and so on.

2) E164 Normalisation Rule Type. Phone number values can now be normalised to the E164 format (e.g. +441912583886) using country specific prefixes driven by the record-level Country ISO Code value. Beyond standardisation and matching this capability will be particularly useful for CTI integrations such as NewVoiceMedia that require the E164 format.

3) Create Master for New Groups. Previously the Merge operation would designate an available Source Record of the correct type (within a matched group) as the Master Record. Now it is possible to specify that a new Master Record must always be created for new groups. This setting allows all Source Records to remain intact which can be critical where records are integrated with external systems.

….

v2.22 Release Notes – February 6th 2018 >

1) Asynchronous Actions. clearMDM supports transactional MDM processing models via packaged Apex Actions that can be incorporated into Process Builder or Flow (Visual Workflow) process automations. The packaged Apex Actions now support asynchronous processing which can reduce the risk of exceeding platform execution limits (in complex environments) by moving the MDM processing to a separate transaction.

2) Batch MDM Reset. The clearMDM package now includes a batch-based mechanism for the reset of MDM related fields and the removal of matched record pair and blocking key statistic records. This new capability introduces additional efficiency to testing and validation cycles.

3) Predictive Partitioning. The initial MDM processing of a dataset using parallel batch operations previously imposed a 1M record limit, record volumes above this required a single batch operation approach with a consequential impact on processing duration. With clearMDM 2.22 this limit is removed via a new predictive partitioning setting that enables massive data volumes to be processed using parallel operations.

….

v2.15 Release Notes – November 27th 2017 >

1) Winter ’18 Lightning Experience UI Compatibility. The clearMDM Lightning UI has been updated to align with the Winter ’18 Lightning Experience UI.

2) Job Monitoring. On rare occasion where 2 parallel batch job processes complete at the same time, the overall job status can stick at “In Progress” rather than moving to “Completed”. To address this a new automatic job monitoring capability has been added which periodically checks for this scenario and applies the correct job completion logic.

….

v2.12 Release Notes – October 15th 2017 >

1) Data Quality RuleSet Update Action. A new packaged Action has been added to support scenarios where control is required over the specific Data Quality RuleSets that are processed by the Data Quality MDM operation. Process automations can now be implemented (Process Builder, Flow etc.) that include steps which de-activate or re-activate specific RuleSets before/after the invocation of Data Quality operations.

2) Submit Batch Job Run Action – Deferred Start Hour. MDM jobs invoked via the [Batch Job Run] Action from within Process Builder or Flow can now specify the start hour for the job. If the start hour has passed for the current day, execution will be deferred to the specified hour on the next calendar day. Previously job invocation via Action has been limited to immediate execution only.

….

v2.11 Release Notes – October 9th 2017 >

1) Blocking Key Update Action. A new packaged Action has been added to support scenarios where multiple matching passes are required across different Blocking Key constructs. Process automations can now be implemented (Process Builder, Flow etc.) that blend job control functions (i.e. Job Submission) with updates to the Blocking Key configuration.

….

v2.9 Release Notes – September 9th 2017 >

1) Matching Check Notifications. Salesforce Classic only. Notifications shown in the UI when duplicates are found on record-save now include the calculated Match Score and View links to enable easy navigation.

2) QuickMatching API. The QuickMatching API operation now supports a new parameter that allows the blocking key to be overridden. The use case here is where the inputs required to construct a valid blocking key are unavailable at the point-of-entry and an alternative field (such as email) should be used instead.

3) QuickStart, Implementation Guide and API Guide documentation update.

….

v2.8 Release Notes – August 5th 2017 >

1) Advanced Merge. A key engineering focus over recent releases has been to deliver an advanced matching engine (cross-field matching being one such capability). Version 2.8 marks a change in direction toward the delivery of an advanced merge engine. Attribute Groups are the first feature in this regard and represent the most powerful capability added to the clearMDM product to date.

Attribute Groups allow groupings of fields to be defined that are Merged (or Synchronised) together. All fields in an Attribute Group populate to the Master Record from one Source Record only. A common example is address data where the best quality, or most recent (and entire) address should be utilised. Attribute Groups provide additional advanced merge capabilities:

1.1) Existing Record Evaluation. Attribute Group evaluation considers Matched Records, related Master records and also any existing Source Records related to those Master Records. This latter inclusion is new and exclusive to Attribute Groups.

1.2) Priority Types. Attribute Groups support Newest, Oldest and Dynamic priority types. For time-based priority types a Datetime field must be specified to enable record evaluation. For the dynamic priority type a Numeric field must be specified; this could be a field populated by the Data Quality MDM operation (e.g. Address Quality Score) – in a model where the highest quality address is merged to the Master Record. Dynamic priority is a radical shift from static (Data Source specific) field-priorities; the dynamic approach enables record field values to drive the prioritisation of Master Record field population.

2) Record Reparenting Action. A new Action has been added to enable the Reparenting MDM operation to be executed from Process Builder, Flow or the Rest API. A complete cycle of MDM processing can now be implemented in a transactional model, i.e. Source Records match, merge and initiate Child Record reparenting in near-real time.

3) Check-only Data Sources. clearMDM now supports cross-object matching between standard objects. The main use case here is checking between Leads, Contacts and/or Person Accounts – however the approach is generic enough to allow Opportunity checking against Case should this requirement ever arise! More typically, Lead creation (file import, UI data entry etc.) can be blocked where the Lead matches to an existing Contact.

….

v2.4 Release Notes – June 11th 2017 >

1) Target Object Settings UI. The new streamlined Target Object Settings UI enables fields to be selected and added as rules, rather than displaying all fields defined on the object by default. This optimisation addresses performance issues where the custom field count is high.

2) Synchronisation Operation Update. The Synchronisation MDM operation now checks the existing field population state on the Master Record and preserves a non-blank field value unless a Source Record with a higher merge priority exists. This update aligns the Synchronisation and Merge MDM operations.

….

v2.2 Release Notes – May 17th 2017 >

1) QuickStart Documentation. The new QuickStart guides provide a comprehensive overview of the clearMDM product (and key use cases) plus step-by-step implementation guidance for each MDM operation (including the new Data Quality feature-set).

2) Adhoc Merge. The “Matching Test” feature now supports record merge from the Compare step. This new capability allows related records to be found through field filters and directly merged. A common Blocking Key is not necessary for adhoc merge.

3) Re-merge. The “MDM Reset” feature now allows previously merged record groups to be re-merged. A new “Re-merge” button appears when a record with MDM Status equal to “Merge Master” is to be reset. The new button reverts the related group of records back to the Matched Record Group stage allowing records to be removed, a new master record selection to be applied plus modifications to individual field population selections.

4) Last Synchronisation Date. The Synchronisation MDM operation now updates a distinct “Last Synchronisation Date” field, previously the “Last Merged Date” field was shared with the Merge MDM operation.

5) Lightning Experience UI updates. Enhancements have been applied across the User Interface to align with the latest version of the Salesforce Lightning Design system (SLDS).

….

v2.0 Release Notes – April 11th 2017 >

1) Introducing clearMDM Editions; Basic, Mid and Enterprise.

2) Data Quality Rule Sets, Rules and Actions.

….

v1.28 Release Notes – April 3rd 2017 >

1) Cross-field matching. Check for field value matches across multiple fields. This new capability is primarily intended for matching Phone numbers, Email addresses and Address data where the matching values may exist in any one of a number of potential fields (e.g. Phone, Home Phone or Mobile).

2) Matching rules support Date and Datetime fields. Enable matching rules on Person Date-of-birth etc.

3) Exact Matching. A new Match Rule Type “Exact” requires that field values are identical.

4) Matched Record Group Splits. When candidate matches are rejected, it is possible that matched record group becomes logically split into sub-groups, i.e the chain of matches is broken. The Matched Record Group page recognises this situation and allows the sub-groups to be saved as distinct groups. In such cases a group column appears in the table and a “Save & Split” button appears.

….

v1.26 Release Notes – February 20th 2017 >

1) Point-of-Entry Default Search Field. Previously the default search field on the Search-before-Create page was the first field in alphabetic sort order. Now the most relevant field can be selected via the “Default?” checkbox option displayed against each active field on the Target Object setting page.

2) Override Matching Check. For many reasons it can be desirable to apply conditions as to when Matching Checks are applied at the time of record create or edit. Version 1.26 allows a checkbox formula field to be referenced that returns a True value where matching checks should not applied. The formula expression can encode the required conditions (specific user, profiles, field value permutations etc.).

3) Find Matches. Previously the clearMDM real-time matching UI returned all match candidates for the Blocking Key irrespective of whether the candidate pair included the record from which matching was invoked. With 1.26, the Find Matches page offers “Find” and “Find All” options; the former restricts the results to the current record, the latter returns all matches for the blocking key.

4) Manual Merge. The Manual Merge page has been enhanced to provide better support for different data types (dates, email addresses, numbers etc.) and null values within the merge override area.

5) Record-Level Flag Management. Previously management of the [Is Normalised?] and [Is Active for Matching?] record-level flags has been a function of data integration processing or applied via on-platform workflow/process. With 1.26, clearMDM can manage both flags automatically by detecting changes to significant fields as they happen.

….

v1.25 Release Notes – February 2nd 2017 >

1) Selective Re-parenting. A new Custom Setting [Manual Merge Settings] provides control (org, profile and user level) over the reparenting option visibility and default behaviour on the Manual Merge page. Additionally, where the reparenting is invoked from the Manual Merge page it runs in a selective, non-blocking mode meaning only the source records involved in the merge are processed and multiple instances can run concurrently. This new functionality provides support for implementations where manual matching and merge functions are de-centralised across business users, rather than being centralised to one or more data stewards.

2) Matched Record Group Size Visibility. A new Application Setting [Max UI Visible MRG Size] has been added to provide specific control over the maximum size of a Matched Record Group visible via the clearMDM UI. Previously this was controlled by batch job related settings. The new setting allows larger groups to be opened and matches accepted/rejected prior to Merge.

3) QuickMatching API operation. The new API operation supports ad-hoc use cases such as distributed MDM record matching checks – where data modifications should not be persisted. A JSON record representation is passed to the operation which performs in-memory normalisation and matching MDM operations. The returned results can include a requested list of field values (for example the SAP Id) to enable downstream business logic to be applied in the source system.

….

v1.22 Release Notes – November 26th 2016 >

1) MDM Reset. A new UI feature that resets MDM fields and relationships across Source and Master Records. For example, if a Merge Master record is reset all related Source Records will be reset also. This convenient functionality allows inadvertent matches or incorrectly merged records to be reset to the start of the MDM record life-cycle.

….

v1.19 Release Notes – 18th October 2016 >

1) Blocking Key Statistics. A new MDM operation “Blocking Key Statistics” allows pre-calculation of statistics relating to the defined Blocking Key configuration. Calculated statistics can be used to fine-tune the configuration and are also referenced to optimise the performance of Matching MDM operations.

2) Custom Merge Logic. Prior to the Winter ’17 release, the algorithm employed by Merge MDM operations to select the master record could not be customised. With the new release custom business rules can be implemented to prioritise (and de-prioritise) individual records and thereby allow fine-grained control over how master records are selected.

….

v1.17 Release Notes – 25th September 2016 >

1) Real-time MDM Actions. clearMDM now supports transactional MDM processing for individual records (or groups) in real-time via Process Builder or the REST API. Custom business logic can be implemented via Visual Workflow and exposed as REST API resources.

….

v1.16 Release Notes – 9th September 2016 >

1) Field Priority Logic. Master Records now retain a memory of how individual fields were last populated – the memory is used to prevent overwrite of manual changes or values populated from higher priority data sources.

2) Synchronisation MDM operation. A new one-step operation that allows Source Record updates to be applied to directly to Master Records. Synchronisation respects field priority logic. An efficient, scalable implementation model becomes possible where Source Records linked to Master Records synchronise change and only new Source Records are matched and merged.

….

v1.15 Release Notes – 15th August 2016 >

1) Lightning Ready Certified. clearMDM is now fully Lightning Experience compatible. The app user interface dynamically switches between Salesforce Classic and Lightning Experience based on the current view selected by the user.

….

v1.12 Release Notes – 17th April 2016 >

1) Real-time Matching. Prior to this release the clearMDM real-time matching features have respected the record-level [Is Active for Matching?] flag by default (where configured). As of v1.12 real time matching features do not require this flag to be set, enabling candidate matching records to be identified irrespective of their matching flag status.

2) Custom Rollups for Text fields. Custom Rollups can now be configured to concatenate text fields from child records (transactional data) to a text field on the master record. A useful feature for bringing note information together on the master record to provide a complete at-a-glance view.

….

v1.10 Release Notes – 8th March 2016 >

1) Blocking Key Padding. Blocking key inputs can now be padded up to the required blocking key length. The Blocking Key Padding Flag is set per Target Object.

2) Custom Rollup Incremental Addition Mode. Custom Rollups can now be configured to process only records created since the last time of rollup processing. With the 1.10 release only the SUM function is supported for incremental processing.

….

v1.8 Release Notes – 7th February 2016 >

1) Blocking Key Auto-adjustment. With larger data sets it is possible for blocking key match values to cover large volumes of records. The Matching MDM operation can now be configured to dynamically adjust the length of the overall blocking key used in creating matching groups. This fine-tuning prevents blocking key match values being skipped due to the size of records (Max Records per Group setting).

2) Master Record Inclusion. Master Record inclusion allows Master Records to be selectively exposed to the Matching MDM operation for blocking keys found within the Source Record data set. With version 1.8 matches between Master Records exposed by this logic are prevented; only Source Record to Master Record matching paths are supported.

3) Strict Blocking Key Population. In Strict mode blocking keys are populated only where each input is of sufficient length to match the required input length. This feature avoids unusable blocking keys being created and enables early reporting.

….

v1.0 Release Notes – 30th December 2015 >

clearMDM has passed the Salesforce AppExchange Security Review process and will be publicly listed on the AppExchange from the 31st December 2015.

….

RC1 Release Notes – 28th October 2015 >

1) Data Source Specific Operations. The Matching, Conversion and Re-parenting jobs now support a data source list parameter. This enables operations to run for specific data sources only. For large data volume scenarios partition data sources can be defined and processed independently. Where compatible jobs are chained the data sources parameter is passed to the next job in the sequence.

….

Beta 9 Release Notes – 19th October 2015 >

1) Custom Action Support. clearMDM batch jobs can now be invoked via Custom Actions. This capability enables MDM operations to be invoked from Process Builder or via the REST API. In the latter case, invocation of MDM operations can now be incorporated into data integration tasks.

….

Beta 8 Release Notes – 13th October 2015 >

1) Audit Log Control. Log types provide control over the logging behaviour of the clearMDM package, valid values are (None, Normal, Debug).

….

Beta 7 Release Notes – 21st September 2015 >

1) Formula Field Support. Field-level matching rules can now employ formula fields. In combination with Key and Deterministic matching rule types, matching efficiency can be increased as fuzzy matching processing overhead is reduced.

2) Job Chaining. MDM operations run in a logical order (normalisation, match, merge etc.) Jobs can now be chained in sequence to enabled automated, efficient batch processing.

3) Custom Rollups. Rollup summary fields over lookup relationships. This new feature enables child record reparenting to be employed without losing the key benefits of rollup summary fields which are limited to master detail relationships. Note, numeric fields and the following functions are support for the first release:

SUM, AVERAGE, MIN, MAX, COUNT

4) Internal matching. Where all records to be matched exist in the same object, internal matching provides an efficient, highly scalable matching operation.

….

Beta 6 Release Notes – 10th September 2015 >

1) New Normalisation rules types.

Title : Each word in the Source Field Value is Title-cased.
Use case = Standardisation of last names, e.g. smith, Smith (Smith).

Title Hyphen : Each word in the Source Field Value is Title-cased, words are hyphen separated.
Use case = Standardisation of two-part first names, e.g. Anne marie, Anne Marie (Anne-Marie).

2) The Merge MDM Operation can now reset Master Record Identifier fields (populated from specified Source Record fields), or concatenate new fields to the existing data.

This behaviour is controlled by the Target Object Merge setting [Reset Identifier Target Fields?].