Reltio Connect

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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

Hi Mark,

Thank you for all the details. Hope you are doing well!

I don't think there is a survivorship that can be configured specific by attribute values ordering. However like Saurabh said, there is a workaround for it using RDM. The logic would be - 

- Create the attribute using resolveLookupCode and a lookup defined in RDM. Because of the resolveLookupCode, the raw value from source will not be stored but the canonical code will be stored.

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups

- In RDM, define the lookups like this - 

Reltio Code 1, Reltio Value CUSTOMER -> Canonical Code - 1, Canonical value : CUSTOMER
Reltio Code 2, Reltio Value VERIFIED -> Canonical Code - 2, Canonical value : VERIFIED
Reltio Code 3, Reltio Value FREE_LISTING -> Canonical Code - 3, Canonical value : FREE_LISTING
Reltio Code 4, Reltio Value UNVERIFIED -> Canonical Code - 4, Canonical value : UNVERIFIED
Reltio Code 5, Reltio Value INACTIVE -> Canonical Code - 5, Canonical value : INACTIVE

- Define survivorship as MinValue and Fallback as required.

WARNING - 
If you do a GET on the entity, the attribute will not have the lookup_raw_value. It will only have lookup_code and lookup_value

------------------------------
Ranadip Das

Original Message:
Sent: 03-23-2023 13:29
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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

Ranadip,

Based on Saurabh's earlier comments we have seen this will work for the simple use cases.

We are currently trying more difficult scenarios using fallback strategies.

Some of the more challenging include:

1) Selecting individual attribute OV's differently for a higher priority items where there is a crosswalk for the higher priority but it does not have a value and the lower priority crosswalk does:

           a) In some cases we will want to take the lower priority item (we're ok with this)

           b) Other cases, exclude the lower priorirty item (currently working on)

We'll update with either findings or blocks.

Thanks,

Mark (and Harsha)

Hi Mark,

Thank you for all the details. Hope you are doing well!

I don't think there is a survivorship that can be configured specific by attribute values ordering. However like Saurabh said, there is a workaround for it using RDM. The logic would be - 

- Create the attribute using resolveLookupCode and a lookup defined in RDM. Because of the resolveLookupCode, the raw value from source will not be stored but the canonical code will be stored.

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups

- In RDM, define the lookups like this - 

Reltio Code 1, Reltio Value CUSTOMER -> Canonical Code - 1, Canonical value : CUSTOMER
Reltio Code 2, Reltio Value VERIFIED -> Canonical Code - 2, Canonical value : VERIFIED
Reltio Code 3, Reltio Value FREE_LISTING -> Canonical Code - 3, Canonical value : FREE_LISTING
Reltio Code 4, Reltio Value UNVERIFIED -> Canonical Code - 4, Canonical value : UNVERIFIED
Reltio Code 5, Reltio Value INACTIVE -> Canonical Code - 5, Canonical value : INACTIVE

- Define survivorship as MinValue and Fallback as required.

WARNING - 
If you do a GET on the entity, the attribute will not have the lookup_raw_value. It will only have lookup_code and lookup_value

------------------------------
Ranadip Das

Original Message:
Sent: 03-23-2023 13:29
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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

Saurabh,  Ranadip

For the following strategies, what is meant by source type?

1) Record-values based source priority   (what is source type to start, plus any additional info)
2) Custom survivorship strategy name

If this is different that Source System, then please provide links to additional information and samples.

Thanks,

Mark

Ranadip,

Based on Saurabh's earlier comments we have seen this will work for the simple use cases.

We are currently trying more difficult scenarios using fallback strategies.

Some of the more challenging include:

1) Selecting individual attribute OV's differently for a higher priority items where there is a crosswalk for the higher priority but it does not have a value and the lower priority crosswalk does:

           a) In some cases we will want to take the lower priority item (we're ok with this)

           b) Other cases, exclude the lower priorirty item (currently working on)

We'll update with either findings or blocks.

Thanks,

Mark (and Harsha)

Hi Mark,

Thank you for all the details. Hope you are doing well!

I don't think there is a survivorship that can be configured specific by attribute values ordering. However like Saurabh said, there is a workaround for it using RDM. The logic would be - 

- Create the attribute using resolveLookupCode and a lookup defined in RDM. Because of the resolveLookupCode, the raw value from source will not be stored but the canonical code will be stored.

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups

- In RDM, define the lookups like this - 

Reltio Code 1, Reltio Value CUSTOMER -> Canonical Code - 1, Canonical value : CUSTOMER
Reltio Code 2, Reltio Value VERIFIED -> Canonical Code - 2, Canonical value : VERIFIED
Reltio Code 3, Reltio Value FREE_LISTING -> Canonical Code - 3, Canonical value : FREE_LISTING
Reltio Code 4, Reltio Value UNVERIFIED -> Canonical Code - 4, Canonical value : UNVERIFIED
Reltio Code 5, Reltio Value INACTIVE -> Canonical Code - 5, Canonical value : INACTIVE

- Define survivorship as MinValue and Fallback as required.

WARNING - 
If you do a GET on the entity, the attribute will not have the lookup_raw_value. It will only have lookup_code and lookup_value

------------------------------
Ranadip Das

Original Message:
Sent: 03-23-2023 13:29
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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

Hi Mark,

Source Type is source system. You can find some configuration examples here:

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/engage-apis/configuration-api/configuring-survivorship-rules-in-the-l3

Thanks,

Saurabh,  Ranadip

For the following strategies, what is meant by source type?

1) Record-values based source priority   (what is source type to start, plus any additional info)
2) Custom survivorship strategy name

If this is different that Source System, then please provide links to additional information and samples.

Thanks,

Mark

Ranadip,

Based on Saurabh's earlier comments we have seen this will work for the simple use cases.

We are currently trying more difficult scenarios using fallback strategies.

Some of the more challenging include:

1) Selecting individual attribute OV's differently for a higher priority items where there is a crosswalk for the higher priority but it does not have a value and the lower priority crosswalk does:

           a) In some cases we will want to take the lower priority item (we're ok with this)

           b) Other cases, exclude the lower priorirty item (currently working on)

We'll update with either findings or blocks.

Thanks,

Mark (and Harsha)

Hi Mark,

Thank you for all the details. Hope you are doing well!

I don't think there is a survivorship that can be configured specific by attribute values ordering. However like Saurabh said, there is a workaround for it using RDM. The logic would be - 

- Create the attribute using resolveLookupCode and a lookup defined in RDM. Because of the resolveLookupCode, the raw value from source will not be stored but the canonical code will be stored.

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups

- In RDM, define the lookups like this - 

Reltio Code 1, Reltio Value CUSTOMER -> Canonical Code - 1, Canonical value : CUSTOMER
Reltio Code 2, Reltio Value VERIFIED -> Canonical Code - 2, Canonical value : VERIFIED
Reltio Code 3, Reltio Value FREE_LISTING -> Canonical Code - 3, Canonical value : FREE_LISTING
Reltio Code 4, Reltio Value UNVERIFIED -> Canonical Code - 4, Canonical value : UNVERIFIED
Reltio Code 5, Reltio Value INACTIVE -> Canonical Code - 5, Canonical value : INACTIVE

- Define survivorship as MinValue and Fallback as required.

WARNING - 
If you do a GET on the entity, the attribute will not have the lookup_raw_value. It will only have lookup_code and lookup_value

------------------------------
Ranadip Das

Original Message:
Sent: 03-23-2023 13:29
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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

Saurabh,

Thanks for clarification that Source Type is the same as Source System.

We are still struggling with how to handle the use case where the higher priority crosswalk exists, but does not have any value for a specific attribute. I had erroneously indicated in earlier Post 5 that we had an approach when wanting to capture the OV from the lower priority item, but I was wrong.

We are sttill trying to figure out how we can use the value from the lower priority group in most but not all cases.

We're really looking for existing behavior that could be used with Source System, but without having to create artificial Source Systems since the qualifying attribute could change but we wouldn't want it to create duplicate crosswalk or require us to recreate all relationships to that prior crosswalk.

 If there were some way to simply update the Source System Name on an existing crosswalk while retaining all relationships it would provide what we are looking for by using Source System rule, but don't believe this exists.

Do you have any suggestions and specific recommendations on how we might proceed.

If possible to have a working session you or other Reltio expert(s) on survivorship, I would hope we could bring this to closure.

This open item is a signficant blocker for us on critical next phase of the project.

We are trying to accomplish all of the following:

Thanks,

Mark

Hi Mark,

Source Type is source system. You can find some configuration examples here:

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/engage-apis/configuration-api/configuring-survivorship-rules-in-the-l3

Thanks,

Saurabh,  Ranadip

For the following strategies, what is meant by source type?

1) Record-values based source priority   (what is source type to start, plus any additional info)
2) Custom survivorship strategy name

If this is different that Source System, then please provide links to additional information and samples.

Thanks,

Mark

Ranadip,

Based on Saurabh's earlier comments we have seen this will work for the simple use cases.

We are currently trying more difficult scenarios using fallback strategies.

Some of the more challenging include:

1) Selecting individual attribute OV's differently for a higher priority items where there is a crosswalk for the higher priority but it does not have a value and the lower priority crosswalk does:

           a) In some cases we will want to take the lower priority item (we're ok with this)

           b) Other cases, exclude the lower priorirty item (currently working on)

We'll update with either findings or blocks.

Thanks,

Mark (and Harsha)

Hi Mark,

Thank you for all the details. Hope you are doing well!

I don't think there is a survivorship that can be configured specific by attribute values ordering. However like Saurabh said, there is a workaround for it using RDM. The logic would be - 

- Create the attribute using resolveLookupCode and a lookup defined in RDM. Because of the resolveLookupCode, the raw value from source will not be stored but the canonical code will be stored.

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups

- In RDM, define the lookups like this - 

Reltio Code 1, Reltio Value CUSTOMER -> Canonical Code - 1, Canonical value : CUSTOMER
Reltio Code 2, Reltio Value VERIFIED -> Canonical Code - 2, Canonical value : VERIFIED
Reltio Code 3, Reltio Value FREE_LISTING -> Canonical Code - 3, Canonical value : FREE_LISTING
Reltio Code 4, Reltio Value UNVERIFIED -> Canonical Code - 4, Canonical value : UNVERIFIED
Reltio Code 5, Reltio Value INACTIVE -> Canonical Code - 5, Canonical value : INACTIVE

- Define survivorship as MinValue and Fallback as required.

WARNING - 
If you do a GET on the entity, the attribute will not have the lookup_raw_value. It will only have lookup_code and lookup_value

------------------------------
Ranadip Das

Original Message:
Sent: 03-23-2023 13:29
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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

Saurabh,

Thanks for clarification that Source Type is the same as Source System.

We are still struggling with how to handle the use case where the higher priority crosswalk exists, but does not have any value for a specific attribute. I had erroneously indicated in earlier Post 5 that we had an approach when wanting to capture the OV from the lower priority item, but I was wrong.

We are sttill trying to figure out how we can use the value from the lower priority group in most but not all cases.

We're really looking for existing behavior that could be used with Source System, but without having to create artificial Source Systems since the qualifying attribute could change but we wouldn't want it to create duplicate crosswalk or require us to recreate all relationships to that prior crosswalk.

 If there were some way to simply update the Source System Name on an existing crosswalk while retaining all relationships it would provide what we are looking for by using Source System rule, but don't believe this exists.

Do you have any suggestions and specific recommendations on how we might proceed.

If possible to have a working session you or other Reltio expert(s) on survivorship, I would hope we could bring this to closure.

This open item is a signficant blocker for us on critical next phase of the project.

We are trying to accomplish all of the following:

Thanks,

Mark

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

Original Message:
Sent: 03-27-2023 09:26
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Source Type is source system. You can find some configuration examples here:

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/engage-apis/configuration-api/configuring-survivorship-rules-in-the-l3

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-24-2023 16:44
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,  Ranadip

For the following strategies, what is meant by source type?

1) Record-values based source priority   (what is source type to start, plus any additional info)
2) Custom survivorship strategy name

If this is different that Source System, then please provide links to additional information and samples.

Thanks,

Mark

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

Original Message:
Sent: 03-24-2023 12:10
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Ranadip,

Based on Saurabh's earlier comments we have seen this will work for the simple use cases.

We are currently trying more difficult scenarios using fallback strategies.

Some of the more challenging include:

1) Selecting individual attribute OV's differently for a higher priority items where there is a crosswalk for the higher priority but it does not have a value and the lower priority crosswalk does:

           a) In some cases we will want to take the lower priority item (we're ok with this)

           b) Other cases, exclude the lower priorirty item (currently working on)

We'll update with either findings or blocks.

Thanks,

Mark (and Harsha)

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

Original Message:
Sent: 03-24-2023 11:34
From: Ranadip Das
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Thank you for all the details. Hope you are doing well!

I don't think there is a survivorship that can be configured specific by attribute values ordering. However like Saurabh said, there is a workaround for it using RDM. The logic would be - 

- Create the attribute using resolveLookupCode and a lookup defined in RDM. Because of the resolveLookupCode, the raw value from source will not be stored but the canonical code will be stored.

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups

- In RDM, define the lookups like this - 

Reltio Code 1, Reltio Value CUSTOMER -> Canonical Code - 1, Canonical value : CUSTOMER
Reltio Code 2, Reltio Value VERIFIED -> Canonical Code - 2, Canonical value : VERIFIED
Reltio Code 3, Reltio Value FREE_LISTING -> Canonical Code - 3, Canonical value : FREE_LISTING
Reltio Code 4, Reltio Value UNVERIFIED -> Canonical Code - 4, Canonical value : UNVERIFIED
Reltio Code 5, Reltio Value INACTIVE -> Canonical Code - 5, Canonical value : INACTIVE

- Define survivorship as MinValue and Fallback as required.

WARNING - 
If you do a GET on the entity, the attribute will not have the lookup_raw_value. It will only have lookup_code and lookup_value

------------------------------
Ranadip Das

Original Message:
Sent: 03-23-2023 13:29
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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

Hello Mark,

Below is a solution that I believe will work based on how I understood the requirements.

Attaching the JSON of the survivorship strategies for the setup below.

Hope this helps.

Step 1: Create three new attributes (IsCustomer, IsVerified, IsFreeListed). Type: boolean

Step 2: Set the boolean value = true if the crosswalk has the specific type.

Step 3: For each "other" attribute (ex: Name, Class, State), create a default strategy for profiles where only "Unverified" crosswalks exist.

Step 4: To handle the type priority for the top 3 values, create an additional survivorship rule for every "other" attribute based on the below setup.

How the above "fallback strategies" set up works:

1. Filter: Profile has to have type values: "Customer", "Verified", "Free Listed" (Caveat to be explained further below)
2. Reltio will check if there are values from crosswalks that have type = Customer.
   • If there are multiple values, it will be handled in Step 5 but will still go through Step 3 and Step 4
   • If there are no values, it will go to Step 3
   • If there is only one value, it will survive and END
3. Reltio will check if there are values from crosswalks that have type = Verified
   
   • If there are multiple values from Step 2, this will produce no potential winning candidates and will go to Step 4
   • If there are multiple values from Step 3, it will take the LUD from the potential candidates from Step 3 and END
   • If there are no values, it will go to Step 4
   • If there is only one value, it will survive and END
4. Reltio will check if there are values from crosswalks that have type = Free Listed
   
   • If there are multiple values from Step 2, this will produce no potential winning candidates and will go to Step 5
   • If there are multiple values from Step 4, it will take the LUD from the potential candidates from Step 4 and END
   • If there are no values, it will go to Step 5
   • If there is only one value, it will survive and END
5. Reltio will check if there are values from crosswalks that have type = Customer.
   • If there are multiple values from Step 5, it will take the LUD from the potential candidates from Step 5 and END
   • If there are no values, no value will survive and END

Caveat:  It appears that the filtering option expects all values to exist in order to trigger the rule. So you will need to create additional rules for each possible combination (ex: all 3 values exist or 2 of the values exist or only 1 value exists).  @Saurabh Agarwal will need to advise if this is working as designed.

Additional steps if only one Priority Type ("Customer", "Verified", etc) needs to survive as the OV.

Step 1: Create an attribute for "Score" (based on Ranadip's feedback above) with RDM lookup and resolveLookupCode = true. This will be populated using the type values ("Customer", "Verified", etc).

Step 2: Set "Score" survivorship to "Min Value". Set the "PriorityType" survivorship to "OtherAttributeWinnerCrosswalk" and set the primaryAttributeURI to  "Score"

Results: Multiple types exist in the profile.

Results: Only 'Unverified' type exist in the profile.

Saurabh,

Thanks for clarification that Source Type is the same as Source System.

We are still struggling with how to handle the use case where the higher priority crosswalk exists, but does not have any value for a specific attribute. I had erroneously indicated in earlier Post 5 that we had an approach when wanting to capture the OV from the lower priority item, but I was wrong.

We are sttill trying to figure out how we can use the value from the lower priority group in most but not all cases.

We're really looking for existing behavior that could be used with Source System, but without having to create artificial Source Systems since the qualifying attribute could change but we wouldn't want it to create duplicate crosswalk or require us to recreate all relationships to that prior crosswalk.

 If there were some way to simply update the Source System Name on an existing crosswalk while retaining all relationships it would provide what we are looking for by using Source System rule, but don't believe this exists.

Do you have any suggestions and specific recommendations on how we might proceed.

If possible to have a working session you or other Reltio expert(s) on survivorship, I would hope we could bring this to closure.

This open item is a signficant blocker for us on critical next phase of the project.

We are trying to accomplish all of the following:

Thanks,

Mark

Hi Mark,

Source Type is source system. You can find some configuration examples here:

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/engage-apis/configuration-api/configuring-survivorship-rules-in-the-l3

Thanks,

Saurabh,  Ranadip

For the following strategies, what is meant by source type?

1) Record-values based source priority   (what is source type to start, plus any additional info)
2) Custom survivorship strategy name

If this is different that Source System, then please provide links to additional information and samples.

Thanks,

Mark

Ranadip,

Based on Saurabh's earlier comments we have seen this will work for the simple use cases.

We are currently trying more difficult scenarios using fallback strategies.

Some of the more challenging include:

1) Selecting individual attribute OV's differently for a higher priority items where there is a crosswalk for the higher priority but it does not have a value and the lower priority crosswalk does:

           a) In some cases we will want to take the lower priority item (we're ok with this)

           b) Other cases, exclude the lower priorirty item (currently working on)

We'll update with either findings or blocks.

Thanks,

Mark (and Harsha)

Hi Mark,

Thank you for all the details. Hope you are doing well!

I don't think there is a survivorship that can be configured specific by attribute values ordering. However like Saurabh said, there is a workaround for it using RDM. The logic would be - 

- Create the attribute using resolveLookupCode and a lookup defined in RDM. Because of the resolveLookupCode, the raw value from source will not be stored but the canonical code will be stored.

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups

- In RDM, define the lookups like this - 

Reltio Code 1, Reltio Value CUSTOMER -> Canonical Code - 1, Canonical value : CUSTOMER
Reltio Code 2, Reltio Value VERIFIED -> Canonical Code - 2, Canonical value : VERIFIED
Reltio Code 3, Reltio Value FREE_LISTING -> Canonical Code - 3, Canonical value : FREE_LISTING
Reltio Code 4, Reltio Value UNVERIFIED -> Canonical Code - 4, Canonical value : UNVERIFIED
Reltio Code 5, Reltio Value INACTIVE -> Canonical Code - 5, Canonical value : INACTIVE

- Define survivorship as MinValue and Fallback as required.

WARNING - 
If you do a GET on the entity, the attribute will not have the lookup_raw_value. It will only have lookup_code and lookup_value

------------------------------
Ranadip Das

Original Message:
Sent: 03-23-2023 13:29
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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

Bryant,

Appreciate the thorough and thought-thru recommendation.

I don't see the referenced JSON attachment of the survivorship strategies, could you provide this.

We will be reviewing and evaluating.

Thank you much,

Mark

Hello Mark,

Below is a solution that I believe will work based on how I understood the requirements.

Attaching the JSON of the survivorship strategies for the setup below.

Hope this helps.

Step 1: Create three new attributes (IsCustomer, IsVerified, IsFreeListed). Type: boolean

Step 2: Set the boolean value = true if the crosswalk has the specific type.

Step 3: For each "other" attribute (ex: Name, Class, State), create a default strategy for profiles where only "Unverified" crosswalks exist.

Step 4: To handle the type priority for the top 3 values, create an additional survivorship rule for every "other" attribute based on the below setup.

How the above "fallback strategies" set up works:

1. Filter: Profile has to have type values: "Customer", "Verified", "Free Listed" (Caveat to be explained further below)
2. Reltio will check if there are values from crosswalks that have type = Customer.
   • If there are multiple values, it will be handled in Step 5 but will still go through Step 3 and Step 4
   • If there are no values, it will go to Step 3
   • If there is only one value, it will survive and END
3. Reltio will check if there are values from crosswalks that have type = Verified
   
   • If there are multiple values from Step 2, this will produce no potential winning candidates and will go to Step 4
   • If there are multiple values from Step 3, it will take the LUD from the potential candidates from Step 3 and END
   • If there are no values, it will go to Step 4
   • If there is only one value, it will survive and END
4. Reltio will check if there are values from crosswalks that have type = Free Listed
   
   • If there are multiple values from Step 2, this will produce no potential winning candidates and will go to Step 5
   • If there are multiple values from Step 4, it will take the LUD from the potential candidates from Step 4 and END
   • If there are no values, it will go to Step 5
   • If there is only one value, it will survive and END
5. Reltio will check if there are values from crosswalks that have type = Customer.
   • If there are multiple values from Step 5, it will take the LUD from the potential candidates from Step 5 and END
   • If there are no values, no value will survive and END

Caveat:  It appears that the filtering option expects all values to exist in order to trigger the rule. So you will need to create additional rules for each possible combination (ex: all 3 values exist or 2 of the values exist or only 1 value exists).  @Saurabh Agarwal will need to advise if this is working as designed.

Additional steps if only one Priority Type ("Customer", "Verified", etc) needs to survive as the OV.

Step 1: Create an attribute for "Score" (based on Ranadip's feedback above) with RDM lookup and resolveLookupCode = true. This will be populated using the type values ("Customer", "Verified", etc).

Step 2: Set "Score" survivorship to "Min Value". Set the "PriorityType" survivorship to "OtherAttributeWinnerCrosswalk" and set the primaryAttributeURI to  "Score"

Results: Multiple types exist in the profile.

Results: Only 'Unverified' type exist in the profile.

Saurabh,

Thanks for clarification that Source Type is the same as Source System.

We are still struggling with how to handle the use case where the higher priority crosswalk exists, but does not have any value for a specific attribute. I had erroneously indicated in earlier Post 5 that we had an approach when wanting to capture the OV from the lower priority item, but I was wrong.

We are sttill trying to figure out how we can use the value from the lower priority group in most but not all cases.

We're really looking for existing behavior that could be used with Source System, but without having to create artificial Source Systems since the qualifying attribute could change but we wouldn't want it to create duplicate crosswalk or require us to recreate all relationships to that prior crosswalk.

 If there were some way to simply update the Source System Name on an existing crosswalk while retaining all relationships it would provide what we are looking for by using Source System rule, but don't believe this exists.

Do you have any suggestions and specific recommendations on how we might proceed.

If possible to have a working session you or other Reltio expert(s) on survivorship, I would hope we could bring this to closure.

This open item is a signficant blocker for us on critical next phase of the project.

We are trying to accomplish all of the following:

Thanks,

Mark

Hi Mark,

Source Type is source system. You can find some configuration examples here:

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/engage-apis/configuration-api/configuring-survivorship-rules-in-the-l3

Thanks,

Saurabh,  Ranadip

For the following strategies, what is meant by source type?

1) Record-values based source priority   (what is source type to start, plus any additional info)
2) Custom survivorship strategy name

If this is different that Source System, then please provide links to additional information and samples.

Thanks,

Mark

Ranadip,

Based on Saurabh's earlier comments we have seen this will work for the simple use cases.

We are currently trying more difficult scenarios using fallback strategies.

Some of the more challenging include:

1) Selecting individual attribute OV's differently for a higher priority items where there is a crosswalk for the higher priority but it does not have a value and the lower priority crosswalk does:

           a) In some cases we will want to take the lower priority item (we're ok with this)

           b) Other cases, exclude the lower priorirty item (currently working on)

We'll update with either findings or blocks.

Thanks,

Mark (and Harsha)

Hi Mark,

Thank you for all the details. Hope you are doing well!

I don't think there is a survivorship that can be configured specific by attribute values ordering. However like Saurabh said, there is a workaround for it using RDM. The logic would be - 

- Create the attribute using resolveLookupCode and a lookup defined in RDM. Because of the resolveLookupCode, the raw value from source will not be stored but the canonical code will be stored.

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups

- In RDM, define the lookups like this - 

Reltio Code 1, Reltio Value CUSTOMER -> Canonical Code - 1, Canonical value : CUSTOMER
Reltio Code 2, Reltio Value VERIFIED -> Canonical Code - 2, Canonical value : VERIFIED
Reltio Code 3, Reltio Value FREE_LISTING -> Canonical Code - 3, Canonical value : FREE_LISTING
Reltio Code 4, Reltio Value UNVERIFIED -> Canonical Code - 4, Canonical value : UNVERIFIED
Reltio Code 5, Reltio Value INACTIVE -> Canonical Code - 5, Canonical value : INACTIVE

- Define survivorship as MinValue and Fallback as required.

WARNING - 
If you do a GET on the entity, the attribute will not have the lookup_raw_value. It will only have lookup_code and lookup_value

------------------------------
Ranadip Das

Original Message:
Sent: 03-23-2023 13:29
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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

The attachment appears to have failed on the original post so adding again.

Bryant,

Appreciate the thorough and thought-thru recommendation.

I don't see the referenced JSON attachment of the survivorship strategies, could you provide this.

We will be reviewing and evaluating.

Thank you much,

Mark

Hello Mark,

Below is a solution that I believe will work based on how I understood the requirements.

Attaching the JSON of the survivorship strategies for the setup below.

Hope this helps.

Step 1: Create three new attributes (IsCustomer, IsVerified, IsFreeListed). Type: boolean

Step 2: Set the boolean value = true if the crosswalk has the specific type.

Step 3: For each "other" attribute (ex: Name, Class, State), create a default strategy for profiles where only "Unverified" crosswalks exist.

Step 4: To handle the type priority for the top 3 values, create an additional survivorship rule for every "other" attribute based on the below setup.

How the above "fallback strategies" set up works:

1. Filter: Profile has to have type values: "Customer", "Verified", "Free Listed" (Caveat to be explained further below)
2. Reltio will check if there are values from crosswalks that have type = Customer.
   • If there are multiple values, it will be handled in Step 5 but will still go through Step 3 and Step 4
   • If there are no values, it will go to Step 3
   • If there is only one value, it will survive and END
3. Reltio will check if there are values from crosswalks that have type = Verified
   
   • If there are multiple values from Step 2, this will produce no potential winning candidates and will go to Step 4
   • If there are multiple values from Step 3, it will take the LUD from the potential candidates from Step 3 and END
   • If there are no values, it will go to Step 4
   • If there is only one value, it will survive and END
4. Reltio will check if there are values from crosswalks that have type = Free Listed
   
   • If there are multiple values from Step 2, this will produce no potential winning candidates and will go to Step 5
   • If there are multiple values from Step 4, it will take the LUD from the potential candidates from Step 4 and END
   • If there are no values, it will go to Step 5
   • If there is only one value, it will survive and END
5. Reltio will check if there are values from crosswalks that have type = Customer.
   • If there are multiple values from Step 5, it will take the LUD from the potential candidates from Step 5 and END
   • If there are no values, no value will survive and END

Caveat:  It appears that the filtering option expects all values to exist in order to trigger the rule. So you will need to create additional rules for each possible combination (ex: all 3 values exist or 2 of the values exist or only 1 value exists).  @Saurabh Agarwal will need to advise if this is working as designed.

Additional steps if only one Priority Type ("Customer", "Verified", etc) needs to survive as the OV.

Step 1: Create an attribute for "Score" (based on Ranadip's feedback above) with RDM lookup and resolveLookupCode = true. This will be populated using the type values ("Customer", "Verified", etc).

Step 2: Set "Score" survivorship to "Min Value". Set the "PriorityType" survivorship to "OtherAttributeWinnerCrosswalk" and set the primaryAttributeURI to  "Score"

Results: Multiple types exist in the profile.

Results: Only 'Unverified' type exist in the profile.

Saurabh,

Thanks for clarification that Source Type is the same as Source System.

We are still struggling with how to handle the use case where the higher priority crosswalk exists, but does not have any value for a specific attribute. I had erroneously indicated in earlier Post 5 that we had an approach when wanting to capture the OV from the lower priority item, but I was wrong.

We are sttill trying to figure out how we can use the value from the lower priority group in most but not all cases.

We're really looking for existing behavior that could be used with Source System, but without having to create artificial Source Systems since the qualifying attribute could change but we wouldn't want it to create duplicate crosswalk or require us to recreate all relationships to that prior crosswalk.

 If there were some way to simply update the Source System Name on an existing crosswalk while retaining all relationships it would provide what we are looking for by using Source System rule, but don't believe this exists.

Do you have any suggestions and specific recommendations on how we might proceed.

If possible to have a working session you or other Reltio expert(s) on survivorship, I would hope we could bring this to closure.

This open item is a signficant blocker for us on critical next phase of the project.

We are trying to accomplish all of the following:

Thanks,

Mark

Hi Mark,

Source Type is source system. You can find some configuration examples here:

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/engage-apis/configuration-api/configuring-survivorship-rules-in-the-l3

Thanks,

Saurabh,  Ranadip

For the following strategies, what is meant by source type?

1) Record-values based source priority   (what is source type to start, plus any additional info)
2) Custom survivorship strategy name

If this is different that Source System, then please provide links to additional information and samples.

Thanks,

Mark

Ranadip,

Based on Saurabh's earlier comments we have seen this will work for the simple use cases.

We are currently trying more difficult scenarios using fallback strategies.

Some of the more challenging include:

1) Selecting individual attribute OV's differently for a higher priority items where there is a crosswalk for the higher priority but it does not have a value and the lower priority crosswalk does:

           a) In some cases we will want to take the lower priority item (we're ok with this)

           b) Other cases, exclude the lower priorirty item (currently working on)

We'll update with either findings or blocks.

Thanks,

Mark (and Harsha)

Hi Mark,

Thank you for all the details. Hope you are doing well!

I don't think there is a survivorship that can be configured specific by attribute values ordering. However like Saurabh said, there is a workaround for it using RDM. The logic would be - 

- Create the attribute using resolveLookupCode and a lookup defined in RDM. Because of the resolveLookupCode, the raw value from source will not be stored but the canonical code will be stored.

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups

- In RDM, define the lookups like this - 

Reltio Code 1, Reltio Value CUSTOMER -> Canonical Code - 1, Canonical value : CUSTOMER
Reltio Code 2, Reltio Value VERIFIED -> Canonical Code - 2, Canonical value : VERIFIED
Reltio Code 3, Reltio Value FREE_LISTING -> Canonical Code - 3, Canonical value : FREE_LISTING
Reltio Code 4, Reltio Value UNVERIFIED -> Canonical Code - 4, Canonical value : UNVERIFIED
Reltio Code 5, Reltio Value INACTIVE -> Canonical Code - 5, Canonical value : INACTIVE

- Define survivorship as MinValue and Fallback as required.

WARNING - 
If you do a GET on the entity, the attribute will not have the lookup_raw_value. It will only have lookup_code and lookup_value

------------------------------
Ranadip Das

Original Message:
Sent: 03-23-2023 13:29
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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

Bryant,

This looks very interesting and creative.

Would you have concerns about performance, for illustration purposes we had 3 types, in reality we may have as many as 6. Also this will be required for about:

    Organization:   50 simple attributes; 10 nested
    Contact:             30 simple attributes;   5 nested

Thanks,

Mark

The attachment appears to have failed on the original post so adding again.

Bryant,

Appreciate the thorough and thought-thru recommendation.

I don't see the referenced JSON attachment of the survivorship strategies, could you provide this.

We will be reviewing and evaluating.

Thank you much,

Mark

Hello Mark,

Below is a solution that I believe will work based on how I understood the requirements.

Attaching the JSON of the survivorship strategies for the setup below.

Hope this helps.

Step 1: Create three new attributes (IsCustomer, IsVerified, IsFreeListed). Type: boolean

Step 2: Set the boolean value = true if the crosswalk has the specific type.

Step 3: For each "other" attribute (ex: Name, Class, State), create a default strategy for profiles where only "Unverified" crosswalks exist.

Step 4: To handle the type priority for the top 3 values, create an additional survivorship rule for every "other" attribute based on the below setup.

How the above "fallback strategies" set up works:

1. Filter: Profile has to have type values: "Customer", "Verified", "Free Listed" (Caveat to be explained further below)
2. Reltio will check if there are values from crosswalks that have type = Customer.
   • If there are multiple values, it will be handled in Step 5 but will still go through Step 3 and Step 4
   • If there are no values, it will go to Step 3
   • If there is only one value, it will survive and END
3. Reltio will check if there are values from crosswalks that have type = Verified
   
   • If there are multiple values from Step 2, this will produce no potential winning candidates and will go to Step 4
   • If there are multiple values from Step 3, it will take the LUD from the potential candidates from Step 3 and END
   • If there are no values, it will go to Step 4
   • If there is only one value, it will survive and END
4. Reltio will check if there are values from crosswalks that have type = Free Listed
   
   • If there are multiple values from Step 2, this will produce no potential winning candidates and will go to Step 5
   • If there are multiple values from Step 4, it will take the LUD from the potential candidates from Step 4 and END
   • If there are no values, it will go to Step 5
   • If there is only one value, it will survive and END
5. Reltio will check if there are values from crosswalks that have type = Customer.
   • If there are multiple values from Step 5, it will take the LUD from the potential candidates from Step 5 and END
   • If there are no values, no value will survive and END

Caveat:  It appears that the filtering option expects all values to exist in order to trigger the rule. So you will need to create additional rules for each possible combination (ex: all 3 values exist or 2 of the values exist or only 1 value exists).  @Saurabh Agarwal will need to advise if this is working as designed.

Additional steps if only one Priority Type ("Customer", "Verified", etc) needs to survive as the OV.

Step 1: Create an attribute for "Score" (based on Ranadip's feedback above) with RDM lookup and resolveLookupCode = true. This will be populated using the type values ("Customer", "Verified", etc).

Step 2: Set "Score" survivorship to "Min Value". Set the "PriorityType" survivorship to "OtherAttributeWinnerCrosswalk" and set the primaryAttributeURI to  "Score"

Results: Multiple types exist in the profile.

Results: Only 'Unverified' type exist in the profile.

Saurabh,

Thanks for clarification that Source Type is the same as Source System.

We are still struggling with how to handle the use case where the higher priority crosswalk exists, but does not have any value for a specific attribute. I had erroneously indicated in earlier Post 5 that we had an approach when wanting to capture the OV from the lower priority item, but I was wrong.

We are sttill trying to figure out how we can use the value from the lower priority group in most but not all cases.

We're really looking for existing behavior that could be used with Source System, but without having to create artificial Source Systems since the qualifying attribute could change but we wouldn't want it to create duplicate crosswalk or require us to recreate all relationships to that prior crosswalk.

 If there were some way to simply update the Source System Name on an existing crosswalk while retaining all relationships it would provide what we are looking for by using Source System rule, but don't believe this exists.

Do you have any suggestions and specific recommendations on how we might proceed.

If possible to have a working session you or other Reltio expert(s) on survivorship, I would hope we could bring this to closure.

This open item is a signficant blocker for us on critical next phase of the project.

We are trying to accomplish all of the following:

Thanks,

Mark

Hi Mark,

Source Type is source system. You can find some configuration examples here:

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/engage-apis/configuration-api/configuring-survivorship-rules-in-the-l3

Thanks,

Saurabh,  Ranadip

For the following strategies, what is meant by source type?

1) Record-values based source priority   (what is source type to start, plus any additional info)
2) Custom survivorship strategy name

If this is different that Source System, then please provide links to additional information and samples.

Thanks,

Mark

Ranadip,

Based on Saurabh's earlier comments we have seen this will work for the simple use cases.

We are currently trying more difficult scenarios using fallback strategies.

Some of the more challenging include:

1) Selecting individual attribute OV's differently for a higher priority items where there is a crosswalk for the higher priority but it does not have a value and the lower priority crosswalk does:

           a) In some cases we will want to take the lower priority item (we're ok with this)

           b) Other cases, exclude the lower priorirty item (currently working on)

We'll update with either findings or blocks.

Thanks,

Mark (and Harsha)

Hi Mark,

Thank you for all the details. Hope you are doing well!

I don't think there is a survivorship that can be configured specific by attribute values ordering. However like Saurabh said, there is a workaround for it using RDM. The logic would be - 

- Create the attribute using resolveLookupCode and a lookup defined in RDM. Because of the resolveLookupCode, the raw value from source will not be stored but the canonical code will be stored.

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups

- In RDM, define the lookups like this - 

Reltio Code 1, Reltio Value CUSTOMER -> Canonical Code - 1, Canonical value : CUSTOMER
Reltio Code 2, Reltio Value VERIFIED -> Canonical Code - 2, Canonical value : VERIFIED
Reltio Code 3, Reltio Value FREE_LISTING -> Canonical Code - 3, Canonical value : FREE_LISTING
Reltio Code 4, Reltio Value UNVERIFIED -> Canonical Code - 4, Canonical value : UNVERIFIED
Reltio Code 5, Reltio Value INACTIVE -> Canonical Code - 5, Canonical value : INACTIVE

- Define survivorship as MinValue and Fallback as required.

WARNING - 
If you do a GET on the entity, the attribute will not have the lookup_raw_value. It will only have lookup_code and lookup_value

------------------------------
Ranadip Das

Original Message:
Sent: 03-23-2023 13:29
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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

Hello Mark,

I checked with the Platform team and they have no specific concern in terms of the number of rules but they did advise to test against your large profiles, with many crosswalk contributors.

To reduce the number of combinations due to the "caveat", you can create a single filtered survivorship rule per attribute/type combination. That will reduce the number of rules as opposed to trying to build a rule for every single possible combination of types that can exist within a profile. Below is an example.

        {            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",            "survivorshipStrategy": "LUD"        },        {            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",            "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsCustomer",            "filter": {                "equals": [                    {                        "uri": "configuration/entityTypes/Organization/attributes/TESTType",                        "value": "Customer"                    }                ]            },            "fallbackStrategies": [                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsVerified",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                },                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsFreeListed",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                },                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsCustomer",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                }            ],            "fallbackUsingCriteria": "ZERO_OR_MORE_THAN_ONE",            "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"        },        {            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",            "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsCustomer",            "filter": {                "equals": [                    {                        "uri": "configuration/entityTypes/Organization/attributes/TESTType",                        "value": "Verified"                    }                ]            },            "fallbackStrategies": [                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsVerified",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                },                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsFreeListed",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                },                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsCustomer",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                }            ],            "fallbackUsingCriteria": "ZERO_OR_MORE_THAN_ONE",            "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"        },        {            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",            "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsCustomer",            "filter": {                "equals": [                    {                        "uri": "configuration/entityTypes/Organization/attributes/TESTType",                        "value": "Free Listed"                    }                ]            },            "fallbackStrategies": [                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsVerified",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                },                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsFreeListed",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                },                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsCustomer",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                }            ],            "fallbackUsingCriteria": "ZERO_OR_MORE_THAN_ONE",            "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"        },

Bryant,

This looks very interesting and creative.

Would you have concerns about performance, for illustration purposes we had 3 types, in reality we may have as many as 6. Also this will be required for about:

    Organization:   50 simple attributes; 10 nested
    Contact:             30 simple attributes;   5 nested

Thanks,

Mark

The attachment appears to have failed on the original post so adding again.

Bryant,

Appreciate the thorough and thought-thru recommendation.

I don't see the referenced JSON attachment of the survivorship strategies, could you provide this.

We will be reviewing and evaluating.

Thank you much,

Mark

Hello Mark,

Below is a solution that I believe will work based on how I understood the requirements.

Attaching the JSON of the survivorship strategies for the setup below.

Hope this helps.

Step 1: Create three new attributes (IsCustomer, IsVerified, IsFreeListed). Type: boolean

Step 2: Set the boolean value = true if the crosswalk has the specific type.

Step 3: For each "other" attribute (ex: Name, Class, State), create a default strategy for profiles where only "Unverified" crosswalks exist.

Step 4: To handle the type priority for the top 3 values, create an additional survivorship rule for every "other" attribute based on the below setup.

How the above "fallback strategies" set up works:

1. Filter: Profile has to have type values: "Customer", "Verified", "Free Listed" (Caveat to be explained further below)
2. Reltio will check if there are values from crosswalks that have type = Customer.
   • If there are multiple values, it will be handled in Step 5 but will still go through Step 3 and Step 4
   • If there are no values, it will go to Step 3
   • If there is only one value, it will survive and END
3. Reltio will check if there are values from crosswalks that have type = Verified
   
   • If there are multiple values from Step 2, this will produce no potential winning candidates and will go to Step 4
   • If there are multiple values from Step 3, it will take the LUD from the potential candidates from Step 3 and END
   • If there are no values, it will go to Step 4
   • If there is only one value, it will survive and END
4. Reltio will check if there are values from crosswalks that have type = Free Listed
   
   • If there are multiple values from Step 2, this will produce no potential winning candidates and will go to Step 5
   • If there are multiple values from Step 4, it will take the LUD from the potential candidates from Step 4 and END
   • If there are no values, it will go to Step 5
   • If there is only one value, it will survive and END
5. Reltio will check if there are values from crosswalks that have type = Customer.
   • If there are multiple values from Step 5, it will take the LUD from the potential candidates from Step 5 and END
   • If there are no values, no value will survive and END

Caveat:  It appears that the filtering option expects all values to exist in order to trigger the rule. So you will need to create additional rules for each possible combination (ex: all 3 values exist or 2 of the values exist or only 1 value exists).  @Saurabh Agarwal will need to advise if this is working as designed.

Additional steps if only one Priority Type ("Customer", "Verified", etc) needs to survive as the OV.

Step 1: Create an attribute for "Score" (based on Ranadip's feedback above) with RDM lookup and resolveLookupCode = true. This will be populated using the type values ("Customer", "Verified", etc).

Step 2: Set "Score" survivorship to "Min Value". Set the "PriorityType" survivorship to "OtherAttributeWinnerCrosswalk" and set the primaryAttributeURI to  "Score"

Results: Multiple types exist in the profile.

Results: Only 'Unverified' type exist in the profile.

Saurabh,

Thanks for clarification that Source Type is the same as Source System.

We are still struggling with how to handle the use case where the higher priority crosswalk exists, but does not have any value for a specific attribute. I had erroneously indicated in earlier Post 5 that we had an approach when wanting to capture the OV from the lower priority item, but I was wrong.

We are sttill trying to figure out how we can use the value from the lower priority group in most but not all cases.

We're really looking for existing behavior that could be used with Source System, but without having to create artificial Source Systems since the qualifying attribute could change but we wouldn't want it to create duplicate crosswalk or require us to recreate all relationships to that prior crosswalk.

 If there were some way to simply update the Source System Name on an existing crosswalk while retaining all relationships it would provide what we are looking for by using Source System rule, but don't believe this exists.

Do you have any suggestions and specific recommendations on how we might proceed.

If possible to have a working session you or other Reltio expert(s) on survivorship, I would hope we could bring this to closure.

This open item is a signficant blocker for us on critical next phase of the project.

We are trying to accomplish all of the following:

Thanks,

Mark

Hi Mark,

Source Type is source system. You can find some configuration examples here:

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/engage-apis/configuration-api/configuring-survivorship-rules-in-the-l3

Thanks,

Saurabh,  Ranadip

For the following strategies, what is meant by source type?

1) Record-values based source priority   (what is source type to start, plus any additional info)
2) Custom survivorship strategy name

If this is different that Source System, then please provide links to additional information and samples.

Thanks,

Mark

Ranadip,

Based on Saurabh's earlier comments we have seen this will work for the simple use cases.

We are currently trying more difficult scenarios using fallback strategies.

Some of the more challenging include:

1) Selecting individual attribute OV's differently for a higher priority items where there is a crosswalk for the higher priority but it does not have a value and the lower priority crosswalk does:

           a) In some cases we will want to take the lower priority item (we're ok with this)

           b) Other cases, exclude the lower priorirty item (currently working on)

We'll update with either findings or blocks.

Thanks,

Mark (and Harsha)

Hi Mark,

Thank you for all the details. Hope you are doing well!

I don't think there is a survivorship that can be configured specific by attribute values ordering. However like Saurabh said, there is a workaround for it using RDM. The logic would be - 

- Create the attribute using resolveLookupCode and a lookup defined in RDM. Because of the resolveLookupCode, the raw value from source will not be stored but the canonical code will be stored.

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups

- In RDM, define the lookups like this - 

Reltio Code 1, Reltio Value CUSTOMER -> Canonical Code - 1, Canonical value : CUSTOMER
Reltio Code 2, Reltio Value VERIFIED -> Canonical Code - 2, Canonical value : VERIFIED
Reltio Code 3, Reltio Value FREE_LISTING -> Canonical Code - 3, Canonical value : FREE_LISTING
Reltio Code 4, Reltio Value UNVERIFIED -> Canonical Code - 4, Canonical value : UNVERIFIED
Reltio Code 5, Reltio Value INACTIVE -> Canonical Code - 5, Canonical value : INACTIVE

- Define survivorship as MinValue and Fallback as required.

WARNING - 
If you do a GET on the entity, the attribute will not have the lookup_raw_value. It will only have lookup_code and lookup_value

------------------------------
Ranadip Das

Original Message:
Sent: 03-23-2023 13:29
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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

Bryant,

Not clear on why need for Filter and the TestIsCustomer.

Could you explain why need for both ... if better to talk directly please let me know.

Thanks,

Mark

Hello Mark,

I checked with the Platform team and they have no specific concern in terms of the number of rules but they did advise to test against your large profiles, with many crosswalk contributors.

To reduce the number of combinations due to the "caveat", you can create a single filtered survivorship rule per attribute/type combination. That will reduce the number of rules as opposed to trying to build a rule for every single possible combination of types that can exist within a profile. Below is an example.

        {            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",            "survivorshipStrategy": "LUD"        },        {            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",            "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsCustomer",            "filter": {                "equals": [                    {                        "uri": "configuration/entityTypes/Organization/attributes/TESTType",                        "value": "Customer"                    }                ]            },            "fallbackStrategies": [                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsVerified",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                },                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsFreeListed",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                },                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsCustomer",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                }            ],            "fallbackUsingCriteria": "ZERO_OR_MORE_THAN_ONE",            "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"        },        {            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",            "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsCustomer",            "filter": {                "equals": [                    {                        "uri": "configuration/entityTypes/Organization/attributes/TESTType",                        "value": "Verified"                    }                ]            },            "fallbackStrategies": [                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsVerified",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                },                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsFreeListed",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                },                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsCustomer",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                }            ],            "fallbackUsingCriteria": "ZERO_OR_MORE_THAN_ONE",            "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"        },        {            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",            "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsCustomer",            "filter": {                "equals": [                    {                        "uri": "configuration/entityTypes/Organization/attributes/TESTType",                        "value": "Free Listed"                    }                ]            },            "fallbackStrategies": [                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsVerified",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                },                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsFreeListed",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                },                {                    "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                    "primaryAttributeUri": "configuration/entityTypes/Organization/attributes/TESTIsCustomer",                    "fallbackStrategies": [                        {                            "attribute": "configuration/entityTypes/Organization/attributes/TESTName",                            "survivorshipStrategy": "LUD"                        }                    ],                    "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"                }            ],            "fallbackUsingCriteria": "ZERO_OR_MORE_THAN_ONE",            "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"        },

Bryant,

This looks very interesting and creative.

Would you have concerns about performance, for illustration purposes we had 3 types, in reality we may have as many as 6. Also this will be required for about:

    Organization:   50 simple attributes; 10 nested
    Contact:             30 simple attributes;   5 nested

Thanks,

Mark

The attachment appears to have failed on the original post so adding again.

Bryant,

Appreciate the thorough and thought-thru recommendation.

I don't see the referenced JSON attachment of the survivorship strategies, could you provide this.

We will be reviewing and evaluating.

Thank you much,

Mark

Hello Mark,

Below is a solution that I believe will work based on how I understood the requirements.

Attaching the JSON of the survivorship strategies for the setup below.

Hope this helps.

Step 1: Create three new attributes (IsCustomer, IsVerified, IsFreeListed). Type: boolean

Step 2: Set the boolean value = true if the crosswalk has the specific type.

Step 3: For each "other" attribute (ex: Name, Class, State), create a default strategy for profiles where only "Unverified" crosswalks exist.

Step 4: To handle the type priority for the top 3 values, create an additional survivorship rule for every "other" attribute based on the below setup.

How the above "fallback strategies" set up works:

1. Filter: Profile has to have type values: "Customer", "Verified", "Free Listed" (Caveat to be explained further below)
2. Reltio will check if there are values from crosswalks that have type = Customer.
   • If there are multiple values, it will be handled in Step 5 but will still go through Step 3 and Step 4
   • If there are no values, it will go to Step 3
   • If there is only one value, it will survive and END
3. Reltio will check if there are values from crosswalks that have type = Verified
   
   • If there are multiple values from Step 2, this will produce no potential winning candidates and will go to Step 4
   • If there are multiple values from Step 3, it will take the LUD from the potential candidates from Step 3 and END
   • If there are no values, it will go to Step 4
   • If there is only one value, it will survive and END
4. Reltio will check if there are values from crosswalks that have type = Free Listed
   
   • If there are multiple values from Step 2, this will produce no potential winning candidates and will go to Step 5
   • If there are multiple values from Step 4, it will take the LUD from the potential candidates from Step 4 and END
   • If there are no values, it will go to Step 5
   • If there is only one value, it will survive and END
5. Reltio will check if there are values from crosswalks that have type = Customer.
   • If there are multiple values from Step 5, it will take the LUD from the potential candidates from Step 5 and END
   • If there are no values, no value will survive and END

Caveat:  It appears that the filtering option expects all values to exist in order to trigger the rule. So you will need to create additional rules for each possible combination (ex: all 3 values exist or 2 of the values exist or only 1 value exists).  @Saurabh Agarwal will need to advise if this is working as designed.

Additional steps if only one Priority Type ("Customer", "Verified", etc) needs to survive as the OV.

Step 1: Create an attribute for "Score" (based on Ranadip's feedback above) with RDM lookup and resolveLookupCode = true. This will be populated using the type values ("Customer", "Verified", etc).

Step 2: Set "Score" survivorship to "Min Value". Set the "PriorityType" survivorship to "OtherAttributeWinnerCrosswalk" and set the primaryAttributeURI to  "Score"

Results: Multiple types exist in the profile.

Results: Only 'Unverified' type exist in the profile.

Saurabh,

Thanks for clarification that Source Type is the same as Source System.

We are still struggling with how to handle the use case where the higher priority crosswalk exists, but does not have any value for a specific attribute. I had erroneously indicated in earlier Post 5 that we had an approach when wanting to capture the OV from the lower priority item, but I was wrong.

We are sttill trying to figure out how we can use the value from the lower priority group in most but not all cases.

We're really looking for existing behavior that could be used with Source System, but without having to create artificial Source Systems since the qualifying attribute could change but we wouldn't want it to create duplicate crosswalk or require us to recreate all relationships to that prior crosswalk.

 If there were some way to simply update the Source System Name on an existing crosswalk while retaining all relationships it would provide what we are looking for by using Source System rule, but don't believe this exists.

Do you have any suggestions and specific recommendations on how we might proceed.

If possible to have a working session you or other Reltio expert(s) on survivorship, I would hope we could bring this to closure.

This open item is a signficant blocker for us on critical next phase of the project.

We are trying to accomplish all of the following:

Thanks,

Mark

Hi Mark,

Source Type is source system. You can find some configuration examples here:

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/engage-apis/configuration-api/configuring-survivorship-rules-in-the-l3

Thanks,

Saurabh,  Ranadip

For the following strategies, what is meant by source type?

1) Record-values based source priority   (what is source type to start, plus any additional info)
2) Custom survivorship strategy name

If this is different that Source System, then please provide links to additional information and samples.

Thanks,

Mark

Ranadip,

Based on Saurabh's earlier comments we have seen this will work for the simple use cases.

We are currently trying more difficult scenarios using fallback strategies.

Some of the more challenging include:

1) Selecting individual attribute OV's differently for a higher priority items where there is a crosswalk for the higher priority but it does not have a value and the lower priority crosswalk does:

           a) In some cases we will want to take the lower priority item (we're ok with this)

           b) Other cases, exclude the lower priorirty item (currently working on)

We'll update with either findings or blocks.

Thanks,

Mark (and Harsha)

Hi Mark,

Thank you for all the details. Hope you are doing well!

I don't think there is a survivorship that can be configured specific by attribute values ordering. However like Saurabh said, there is a workaround for it using RDM. The logic would be - 

- Create the attribute using resolveLookupCode and a lookup defined in RDM. Because of the resolveLookupCode, the raw value from source will not be stored but the canonical code will be stored.

https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups

- In RDM, define the lookups like this - 

Reltio Code 1, Reltio Value CUSTOMER -> Canonical Code - 1, Canonical value : CUSTOMER
Reltio Code 2, Reltio Value VERIFIED -> Canonical Code - 2, Canonical value : VERIFIED
Reltio Code 3, Reltio Value FREE_LISTING -> Canonical Code - 3, Canonical value : FREE_LISTING
Reltio Code 4, Reltio Value UNVERIFIED -> Canonical Code - 4, Canonical value : UNVERIFIED
Reltio Code 5, Reltio Value INACTIVE -> Canonical Code - 5, Canonical value : INACTIVE

- Define survivorship as MinValue and Fallback as required.

WARNING - 
If you do a GET on the entity, the attribute will not have the lookup_raw_value. It will only have lookup_code and lookup_value

------------------------------
Ranadip Das

Original Message:
Sent: 03-23-2023 13:29
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Saurabh,

We will evaluate if this can work for us. 

Thanks,

Mark

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

Original Message:
Sent: 03-23-2023 11:50
From: Saurabh Agarwal
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

Hi Mark,

Another user had a similar use case and they tried to solve it using RDM. Can you check this thread and see if the suggestions in this thread work for you?

Thanks,

------------------------------
Saurabh Agarwal

Original Message:
Sent: 03-22-2023 10:58
From: Mark Burlock
Subject: Survivorship: Use of Source System vs. Filtering for Control of Sequential Order of Evaluation

We have a survivorship requirement for the following:

1.       Base survivorship OV on an attribute, AccountStatus with the following values:

a.       CUSTOMER

b.       VERIFIED

c.       FREE_LISTING

d.       UNVERIFIED

e.       INACTIVE

2.       OV should be based on the sequence above where matching crosswalks exist

3.       If any ties then used fallback approach such as recency, etc

 We know we meet our requirements by defining a different source systems for each of the 5 attribute values, doing so would permit:

1.       Use sourcesURIOrder to ensure proper sequencing for the OV

2.       Use of sourcesForOv to handle fallback with specific rule such recency, aggregation, etc when more than 1 occurrence within a particular AccountStatus.

Our concerns with doing so, is increased complexity:

1.       Including the AccountStatus in a crosswalk results in our needing to handle "duplicates" for what should be a single record and likely additional related maintenance

a.       Logically this making the crosswalk PK based on a non-identifying attribute

2.       RDM Population where we would need to duplicate 1 Source System to 5 Source Systems

It would be preferable, if we can use Filtering for an attribute, or other approach, to obtain the same results.

With filtering, we are not seeing a way to simulate the sourceURIOrder to handle sequencing, so that only the first Filtering condition that is met would return OV values, instead of all the Filter conditions that are met.

Our questions:

1.       If we have a different filtering set defined for each value of the AccountStatus, is the OV value aggregation of all the sets or is there any way to get an OV if the value matches "CUSTOMER" so we would not evaluate the other filtering conditions.

a.       If not, is there any option to define an order of precedence to match our scenario.

2.       If we need to go with multiple source systems are there any concerns other than what we indicated

3.       What would recommended approach to meet our survivorship requirements.

See attachment for additional context

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