Reltio Connect

 View Only

  • 1.  Address Survivorship Best Practices: Nested Address Within Profile (Not Using Location Entity)

    Posted 04-21-2022 13:34
    Hi,

    Looking for recommended best practices for defining survivorship on a nested address attribute.

    Would need to handle 2 major use cases:
    1) Only 1 address type within a Nest (primary use case)
    2) Multiple address tyes within a Nest (secondary use case)

    Looking to use Recency Rules but refine so that a very bad / sparse new address does not replace a stong address just a little bit older.

    This was asked during the Reltio Webinar: "Deep Dive into Reltio Cleansers"

    Also is there any way to filter on existence of a value instead of a specific equals on a value.

    Thanks,

    Mark

    ------------------------------
    Mark Burlock
    Dodge Data & Analytics
    Hamilton NJ
    ------------------------------


  • 2.  RE: Address Survivorship Best Practices: Nested Address Within Profile (Not Using Location Entity)

    Reltio Employee
    Posted 04-26-2022 13:42

    Hi Mark,

    Survivorship within a nest can get a little tricky. Let's start with handling Address Types.

    If I understand your requirements correctly. You can only have one Address of each type, but you can have multiple types of addresses.
    In this scenario you want to set a MatchFieldURI at the nest level to collapse all addresses of the same type. If there is more than on Address of the same type our survivorship will sort it out.  That would look something like this

            {
                    "label": "Address",
                    "name": "Addresses",
                    "type": "Nested",
                    "hidden": false,
                    "important": false,
                    "system": false,
                    "faceted": true,
                    "searchable": true,
                    "attributeOrdering": {
                        "fieldURI": "configuration/entityTypes/Organization/attributes/Addresses/attributes/AddressType",
                        "orderType": "ASC",
                        "orderingStrategy": "FieldBased"
                    },
                    "uri": "configuration/entityTypes/Organization/attributes/Addresses",
                    "dataLabelPattern": "{Country}",
                    "matchFieldURIs": [
                        "configuration/entityTypes/Organization/attributes/Addresses/attributes/AddressType"
        ],


    Now that you have collapsed duplicate types, we need to use survivorship to choose the best crosswalk for our winner. It sounds like you would like to choose the most recent value. I would recommend setting the Address.AddressLine1 to Regency, but setting the value of all other Address attributes to OtherAttributeWinnerCrosswalk with primaryAttributeUri=Address.AddressLine1. This will ensure you never take one part of the Address from one source and one part from a completely different Address, as that would result in an invalid value. Here is an example of how OtherAttributeWinnerCrosswalk works

     {
                            "attribute": "configuration/entityTypes/Organization/attributes/Addresses/attributes/AddressLine1",
                            "sourcesUriOrder": [
                                "configuration/sources/ReltioCleanser",
                                "configuration/sources/Reltio"
                            ],
                            "fallbackStrategies": [
                                {
                                    "attribute": "configuration/entityTypes/Organization/attributes/Addresses/attributes/AddressLine1",
                                    "survivorshipStrategy": "LUD"
                                }
                            ],
                            "fallbackUsingCriteria": "ZERO_OR_MORE_THAN_ONE",
                            "survivorshipStrategy": "SRC_SYS"
                        },
                        {
                            "attribute": "configuration/entityTypes/Organization/attributes/Addresses/attributes/AddressLine2",
                            "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/Addresses/attributes/AddressLine1",
                            "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"
                        },

    I'm not sure what you mean in your question on filtering on the existence of a value, as only non null fields are considered by survivorship. Could you elaborate more on this?



    ------------------------------
    Joel Snipes
    ------------------------------



  • 3.  RE: Address Survivorship Best Practices: Nested Address Within Profile (Not Using Location Entity)

    Posted 05-05-2022 23:33
    Joel,

    Appreciate response and we have decided to handle the refinement of Address Survivorship outside of Reltio using an ETL process for reason which I will explain below.

    Regarding the earlier question:
        Also is there any way to filter on existence of a value instead of a specific equals on a value.
        The Survivorship rule filter s I understand it,  only supports an equal condition to 1 and only 1 value ... at the time we were looking to either support mulitiple criteria (i.e. Verified and Partially Verified) or else that there was a value for VerificationStatus regardless of the value.

    Our specific business requirement for survivorship of address was:
      1) If a Verified address with verification level 5 (Delivery Point) or 4 (Premise) always take the most recent 
      2) If no such address as above exists, take the most recent address, which could be different that the most recent Verified per above.

    We decided at this point,to modify our ETL process going out of Reltio so that:
    1) if the most recent address returned by Reltio as OV is Verified Level 5 or 4 we use that value
    2) Else: if not, then make an entity api call to see if any other Verified address is available and if so then determine which is most recent in the ETL code 
    3) Else: use the original value returned from #1 above

    Thanks,

    Mark​

    ------------------------------
    Mark Burlock
    Dodge Data & Analytics
    Hamilton NJ
    ------------------------------

    Original Message


Related Content