Understanding correlation rule, correlation configuration, and default correlation

[#1]

Every IIQ enthusiast has one time or the other felt the need to understand the three correlation options IIQ provides. They might have come up with questions like - which to use? Which supersedes the other? Can all three types coexist? Can I have no correlations defined? 

I have tried to break down the three types and tried to answer the questions in the attached document. Feel free to suggest changes. Few likes on the post will be much appreciated.

[sarthak_chawla_87]

Hi @sen_rohit90  Thanks for the article. But I believe this should be updated. Default correlation uses the display attribute to identity name. Not the identity attribute

[Peter_H]

good explanation, was very insightful

[rabindra82]

Nice insights provided. Kudos

[Santhana]

Wonderful document. The section below helped me to complete when question raised why it is using Display attribute for Identity Name.

This is from the Aggregation Data Flow  document. "If no rule is specified, Identities created by
this task will have the name value set to the account display attribute or
identity attribute and the manager attribute set to false; all other attributes
on the Identity will be left null".   

[ppradeep]

Nice explanation

[albert007]

how to override the default correlation? 

[nazampreetkaur]

@jennifer_mitchell, We are also seeing same issue where default correlation (on the basis of display attribute) is overriding our correlation rule. It creates a cube every time if display name of resource object is different. But, If we open a ticket with support, they are just going to close it by saying its custom code and we should go to expert services if we need help.

[jennifer_mitchell]

That suggests to me that your correlation rule is failing, not that the default correlation is overriding a value being set by the rule. The logic will not run the default process if a match has been found by the rule or correlation config.

If you are certain that is wrong, you could try turning on trace level logging for the process and see if you can prove that you had a value from your rule and that it got overridden subsequent to your rule execution.