How can I stop producing an event and a historical entry for a update for the startobject in a relationship when the endobject is being updated?

Question:

• We have 3 entities which are related as below:

Individual---> Policy
Policy----> Individual and Asset
Asset ----> Policy

• What we are trying to see is that what happens when we change the policy status by sending from Individual entity payload(person) which doesn't 
  have immutable property set to true and what happens when we try to change the policy status via Asset payload(which has the immutable property set.
  I am attaching both sample payloads.
• What we observed is the asset payload is not able to even change the policy status and individual payload can while generating updates on all the associated entities.
• As per documentation,I don't see this as the right behaviour. Sample entity created and tested in DEV1 tenant XK3X0rQsbORmdxp,fuK0lZH(policy),
  0EenIBi(Individual),0PbDpCx(asset)
• What we wanted to understand is if we change the policy status via policy payload,would it give an update to all entities and assets. How can we stop
  that from happening?

Answer

a. Elimination of events produced from updates in Policy for the Individual entity type:

This issue arises due to the relationship between Individual and Policy entities. To prevent events from being generated when there's a change in PolicyStatus, PolicyStatus should not be defined in the referencedAttribute. Here's an excerpt of the relevant configuration:

Example showing no PolicyStatus in referencedAttribute

    "label": "Related Policies", 
    "name": "IndividualPolicies", 
    "description": "A connection that exists between an entity and Policy entities, based on Match/Merge rules.", 
    "type": "Reference", 
    "hidden": false, 
    "important": false, 
    "system": false, 
    "required": false, 
    "searchable": true, 
    "relationshipLabelPattern": "[ ({PolicyStatus})] {Role}", 
    "attributeOrdering": { 
        "fieldURI": "configuration/entityTypes/Policy/attributes/PolicyStatus", 
        "orderType": "ASC", 
        "orderingStrategy": "FieldBased" 
    }, 
    "uri": "configuration/entityTypes/Individual/attributes/IndividualPolicies", 
    "referencedAttributeURIs": [ 
        "configuration/relationTypes/PolicyIndividualContact/attributes/Role", 
        "configuration/entityTypes/Policy/attributes/LineOfBusiness", 
        "configuration/entityTypes/Policy/attributes/PolicyNumber", 
        "configuration/entityTypes/Policy/attributes/PolicyType", 
        "configuration/entityTypes/Policy/attributes/SalesAgentAgency", 
        "configuration/entityTypes/Policy/attributes/ServicingAgentAgency" 
    ], 
    "referencedEntityTypeURI": "configuration/entityTypes/Policy", 
    "relationshipTypeURI": "configuration/relationTypes/PolicyIndividualContact", 
    "

You are using referencedAttributeURIs to control whether you have an event or not; whether you have a historical record or not.  There are other uses for referenceAttributeURIs. 

The definition of a referencedAttributeURIs is that a reference attribute doesn't have its own attributes. It is using attributes of a relationship and referenced entity. In this property an array of relationship and referenced entity URIs is set that will be used as part of reference attribute.  This impacts how attributes are overridden or not depending how you are using the POST /entities.  It also controls how start and end object are defined in a relationship is defined.

Please review the following documentation links for more information.

• https://docs.reltio.com/en/integrate/load-data-to-reltio-in-bulk/load-data-with-data-loader/load-entities-into-a-tenant/specify-record-update-preference
• https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/entities-api/partialoverrideforreference-option
• https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/engage-apis/configuration-api/attributes-configuration#reference-attribute-configuration-0

b. Elimination of historical records produced from updates in Policy for the Individual entity type:

You have two options to address this:

Option 1: Remove the relations between Individual and Policy entities.

This option has nothing to do with an event it has to do with this historical record.  So, removing the reference attribute will NOT control the historical record.   We don't have attribute, entity, or relationship level control over a historical record reporting. Individual has a relationship with Policy.  Therefore, any change to a relationship is going to produce a historical record.  If you do not want the historical record for individual when you change a policy, then you would have to remove the relationship between the two entity types.

Option 2: Modify the `maxChangedObjects` property to zero. This property limits the number of Activity Log Items that will be indexed or returned in one request. It can be set tenant-wide. 

As I stated maxChangedObjects specifies the limit on the number of Activity Log Records (the historical record) that will be indexed or returned by one request for every update perform.  CAUTION: this is at the tenant level.  Right now you get an activity log for each update (as represented by the -1).   So, if you want to search for any activity (subsequent auto merge, subsequent relationship changes, subsequent matches) that was performed (within a date range, by a specific user, etc), you will NOT be able to perform that search.  This may have undesirable results.

c. Default setting for the "immutable" attribute:

The default setting for the "immutable" attribute is determined by when your tenant was created (per the below documentation)  As of now, it is set to false.

However, it is possible to change this default setting at the tenant-wide level. If you wish to set the default for `immutableRefAttrsByDefault` to true.