Skip to main content

Hi 

 

We are noticing behaviour in our model where a source system will split from its golden id group when updated on matching criteria fields ( in this example address). However it only does this when the group of records was manually merged onto the golden id. It wont “jump ship” and form a new golden id when the records previously auto merged based on the matched criteria we assigned in the model.

Is there a way we can stop this splitting from happening when the source system is updated?

 

For example we can see here the new golden id created with one SF record

 

 

the previous group the SF record belonged to, shows a lot of manual merging in the Match Rule Name column

 

Our rematch if changed section shows these fields are used for rematching:

 

 

We want to keep rematching switched on, to bring other source systems into the group if they meet criteria, but we dont updates on the SF record itself to allow it to break out of the group. (We dont want “auto-splits”)

 

thanks

Hi ​@mauriceK , it sounds like that you might have a specific parameter removeManualMatch enabled.

In such case the rematch operation would have the priority against the manual override.

Can you please check your runtime.parameters

https://docs.ataccama.com/mdm/13.9.x/configuration/runtime-parameters.html

 

 


Hi ​@mauriceK, I’m closing this thread for now, if you have any follow-up questions please share them here or create a new post 🙋‍♀️


Hi ​@Ales

 

Thanks for your reply. Much appreciated. It turns there was a constraint rule in our matching layer, that didnt stop our SF records from rematching with other SF records. Even though they were rematching inactive SF records ( the greyed out lines in the above screenshot) it still recognised the rule to not rematch to them. Below is the fix we applied. We had to change the constraint rule to also check the active status. Once this was deployed, the retest showed the SF record no longer would split from the master record group and create a new group.

 


Reply