Language preference and RELO integration

Alison Sochasky:

Great question Rob! We're running into the same thing with both our NetCommunity and Teamraiser sites. Following to see if anyone has best practices as right now our Gift Processing is having to do a manual add although we have "language" listed in our Bio2 Code tab in RE.


robert badley:

We have used RE for many years and are now using LO as of the past few months. We also have the RELO integration running between the two.


As a Canadian charity we track language preference for our supporters in a repurposed RE field that was originally designated for "Ethnicity". This field very conveniently does synch with LO and so I can tell in LO who has a preference for French lanuage communications but of course the LO Ethnicity field is not used for determining language the "Preferred_locale" field does that.


My question is this, has anyone figured out a way to keep preferred_locale updated consistently with language preference coming from any field in RE?

robert badley:

Ryan O'Keefe:

Alison Sochasky:

Great question Rob! We're running into the same thing with both our NetCommunity and Teamraiser sites. Following to see if anyone has best practices as right now our Gift Processing is having to do a manual add although we have "language" listed in our Bio2 Code tab in RE.


robert badley:

We have used RE for many years and are now using LO as of the past few months. We also have the RELO integration running between the two.


As a Canadian charity we track language preference for our supporters in a repurposed RE field that was originally designated for "Ethnicity". This field very conveniently does synch with LO and so I can tell in LO who has a preference for French lanuage communications but of course the LO Ethnicity field is not used for determining language the "Preferred_locale" field does that.


My question is this, has anyone figured out a way to keep preferred_locale updated consistently with language preference coming from any field in RE?

Reusing an existing field that syncs into RE is the best option, but in order to maintain the preferred_Locale setting you will need to get a task created by the DI team. This has been done for a few orgs that have multi-locale that allows you to update the reused data field with whatever is populated in preferred_Locale every night or once a week. Whatever you feel is best. The basic premise is to take the preferred_Locale setting and populate that into a field that gets synced into RE through a task that runs on a specific frequency. You can contact your client sucess manager about getting that task created.

Alison and Ryan, a follow up on this question. I spoke with my CSM and it seems that the way this customization has been made to work in the past for other clients is that it becomes a one way synch from LO to RE. That is if someone changes their locale in LO then the update will flow through to RE and be captured in a constituent attribute. However, there is no way for changes in E to flow to LO.


I think that what we need to do is advocate for BB to add a "real" language preference field to RE (not a repurposed field like ethnicity) and then advocate for them to add this field to the biographical fields that are synched by the RELO integration.

robert badley:

Ryan O'Keefe:

robert badley:

Ryan O'Keefe:

Alison Sochasky:

Great question Rob! We're running into the same thing with both our NetCommunity and Teamraiser sites. Following to see if anyone has best practices as right now our Gift Processing is having to do a manual add although we have "language" listed in our Bio2 Code tab in RE.


robert badley:

We have used RE for many years and are now using LO as of the past few months. We also have the RELO integration running between the two.


As a Canadian charity we track language preference for our supporters in a repurposed RE field that was originally designated for "Ethnicity". This field very conveniently does synch with LO and so I can tell in LO who has a preference for French lanuage communications but of course the LO Ethnicity field is not used for determining language the "Preferred_locale" field does that.


My question is this, has anyone figured out a way to keep preferred_locale updated consistently with language preference coming from any field in RE?

Reusing an existing field that syncs into RE is the best option, but in order to maintain the preferred_Locale setting you will need to get a task created by the DI team. This has been done for a few orgs that have multi-locale that allows you to update the reused data field with whatever is populated in preferred_Locale every night or once a week. Whatever you feel is best. The basic premise is to take the preferred_Locale setting and populate that into a field that gets synced into RE through a task that runs on a specific frequency. You can contact your client sucess manager about getting that task created.

Alison and Ryan, a follow up on this question. I spoke with my CSM and it seems that the way this customization has been made to work in the past for other clients is that it becomes a one way synch from LO to RE. That is if someone changes their locale in LO then the update will flow through to RE and be captured in a constituent attribute. However, there is no way for changes in E to flow to LO.


I think that what we need to do is advocate for BB to add a "real" language preference field to RE (not a repurposed field like ethnicity) and then advocate for them to add this field to the biographical fields that are synched by the RELO integration.

Robert,


The only workaround would be to use a field that is being synched between the two systems (that is not highly used) and then repurpose the locale_preferred data task to update that other field on a nightly basis. This is a workaround that can be done, but you will have to evaluate all your fields to see what's not being used and how you can leverage that field with the locale one. The Data Integration team should be able to help you map this out.

Ryan, would you be able to point me to a list of fields that synch both ways? I know of course that name, mailing address, email address synch but I'm not sure that I have ever seen a spcific, complete list of the bi-directional synch fields.