Skip to main content
tim_23349f
tim_23349f
Contributor ⭐️⭐️
February 8, 2016
Solved

Copilot In multi-lingual regions

  • February 8, 2016
  • 1 reply
  • 91 views
I'm struggling to come up with a good solution for sending copilot emails in the right language in regions where there could be several different language possibilities. The best solution I can envision so far is pulling in mailing address info from SF then taking a best guess based on the primary language of the country in question. This poses two problems:
- Data integrity from Salesforce (address is not always accurate)
- Huge power list filter (for example I would essentially have to track every country we do business with that has Spanish as a primary language and make a rule that says "IF it's country A OR it's country B OR it's country C..." I could easily see it being 50 or more countries. I'm not even sure if the engine supports that many but even if it does it seems like a mess.

Has anyone come up with a more elegant solution to a similar problem?
      Best answer by irit_eizips
      This is a bigger issue than most people realize, for companies that do business outside of the US borders. One of my clients who has users all over the world, had a similar challenge. Specifically speaking, about 50% of the users were native English speakers, 30% were Spanish speaking, and they also had a strong community (aka strategic customers) who were German and French speaking. We created a calculated "Preferred Language" field in the account object with a CASE statement (you can also use an IF statement for this purpose) based on the country the account was in. This is a good initial step because it takes away the need to have a long IF statement in the rule itself. In addition, you can then use this field, to quickly analyze data by Preferred Language.

      This was a good first step, but we still needed to clean up the database itself. For example, while the account might have been in France, many times, the users would be located all over Europe and may have had a different language preference. For this reason, we also added a "Preferred Language" field in the Contact Object. To make sure we had the right information for each contact, we then used various methods to get the data cleaner.

      While there's no perfect solution, we tried to collect and improve SFDC accuracy through various means. Not all of them would work for you, but it might help you come up with some of your own:

      1) Add a field in SFDC "Preferred Language" in the Contact Object (only include the languages  you're willing to support).

      2) Ask your CSM team to go through their accounts and update the key contacts as a one time effort (if they manage less than 100 accounts or so, this should be possible. If not, continue reading)

      3) Survey - Ask users to identify their language preference through a survey or an in-app message (again, use picklist)

      2) Product - If possible, add a language preference as a field in your application under the user profile and sync back with SFDC.

      Good luck!

      1 reply

      irit_eizips
      irit_eizipsAnswer
      Helper ⭐️
      February 8, 2016
      This is a bigger issue than most people realize, for companies that do business outside of the US borders. One of my clients who has users all over the world, had a similar challenge. Specifically speaking, about 50% of the users were native English speakers, 30% were Spanish speaking, and they also had a strong community (aka strategic customers) who were German and French speaking. We created a calculated "Preferred Language" field in the account object with a CASE statement (you can also use an IF statement for this purpose) based on the country the account was in. This is a good initial step because it takes away the need to have a long IF statement in the rule itself. In addition, you can then use this field, to quickly analyze data by Preferred Language.

      This was a good first step, but we still needed to clean up the database itself. For example, while the account might have been in France, many times, the users would be located all over Europe and may have had a different language preference. For this reason, we also added a "Preferred Language" field in the Contact Object. To make sure we had the right information for each contact, we then used various methods to get the data cleaner.

      While there's no perfect solution, we tried to collect and improve SFDC accuracy through various means. Not all of them would work for you, but it might help you come up with some of your own:

      1) Add a field in SFDC "Preferred Language" in the Contact Object (only include the languages  you're willing to support).

      2) Ask your CSM team to go through their accounts and update the key contacts as a one time effort (if they manage less than 100 accounts or so, this should be possible. If not, continue reading)

      3) Survey - Ask users to identify their language preference through a survey or an in-app message (again, use picklist)

      2) Product - If possible, add a language preference as a field in your application under the user profile and sync back with SFDC.

      Good luck!
        Terms & ConditionsAccessibility statement