Incoming Email's Language detection- Automate your case assignment based on Language- Salesforce Email Services




My First Attempt at Blogging!

This is my first attempt to write a blog, which you will probably figure out by the end, but I wanted to start by sharing an interesting and a useful use-case which was implemented for a big Airline company who were using Salesforce service cloud for their customer support. This is a very general requirement for customer support teams using Salesforce Email to Case feature.

Who may require this?

Organisations using Salesforce Service cloud or Case management feature to manage their customer support and having customers from around the globe in different geographical regions (with different native languages).

For such a business,the customers can send emails to support email Ids in different languages and the emails are converted into Salesforce cases (Email to case).

Why is it needed?

Imagine multiple support teams in Salesforce org for customer support which are divided into different queues on the basis of their language skills like English ,Spanish ,French,German,Japanese  etc.

Huge manual effort is involved in going through the cases created in Salesforce(from emails) to identify their language and then manually assigning them to the correct queue.

In a real world example, for an enterprise level Salesforce org, there can be more than 1000 customer support emails that are received daily by customer support teams.

Spare a thought for the admins who will do this manual activity!
Sounds like a boring and expensive exercise right?

How to save this effort and cost?

Automatically detecting the language of an incoming email and assigning the case created from the email to the correct queue (as per language detected) by using case assignment rules.

Salesforce Platform Limitations.

1. No out of box language detection feature for incoming emails currently.
2. No app exchange apps to achieve the same in a flexible and customized way.


What are our Options? Email to Case Enhancement? 

Before continuing if you are not familiar about email to case features and its setup and configuration please refer to this helpful link:
https://help.salesforce.com/articleView?id=customizesupport_email.htm&type=5

Technical Challenge: Part 1

Email to Case is an out of box Salesforce feature which converts the incoming emails (to an Salesforce email id created in email to case setup) into Case records. Since there is no customization possible in regards to how the email is processed  and converted to case via email to case feature,language detection or any other customization on top of that is quite tricky.

If we use Email to Case feature for case creation, the only way to detect the language of the email will be to do some customization through an Apex Trigger or Process Builders on case object as no other customization options are available to us.


Also, we need to use one of the many Language Detection APIs available nowadays like Google translation APIs since Salesforce has no language detection features.

So by now we have identified that we have to create a trigger/flow and we need to make a callout to the language detection API once the case is created from Email to Case functionality.

Technical Challenge: Part 2

Salesforce doesn't allow any call-outs just after a DML operation.
In this scenario, DML(insert) is being performed internally by Salesforce Email to Case functionality as it is creating a new case from the email received.

Because of this, external call-outs in the same transaction are not allowed.
As a workaround, we need to break the transaction by calling a future method (or any other async operation) from Case trigger to make a call-out to the language detection API.

This leaves us with three building blocks identified: A case Trigger (on insert), a future method to make a callout, and a language detection API endpoint(to which the callout will be made).


Problem solved? Not exactly.

Now that we have identified the building blocks, we would assume the problem is solved and we can start our development. But Wait! There's one more catch.

Though the strategy seems to be fine, but calling a future method from trigger does come with one little problem specially in this scenario.

Future calls (or any other async operations) from a trigger to perform a call-out exits/breaks the current transaction and then runs in background asynchronously. It implies that before the future method is actually executed , a case will be created in Salesforce (via email to case). This insert operation of case may fire many case create automation features like assignment rules , before/after insert triggers, workflows, flows etc.


Post that ,when the future call is actually completed and the email language is identified, the same case created in above step has to be updated again with the language identified and it has to be re-assigned to a respective queue after triggering the assignment rules again.
This actually becomes a two step process (first insert, then update) and leaves lots of technical and functional gaps .See the problem?


Email Services to the Rescue!

Email services allow a Salesforce developer to use the incoming email into Salesforce as an independent and usable entity and provides an option to the developer to use the email attributes like subject, body etc. directly for any customization required in Apex code.
This all can be done even before calling a insert operation and creating a case in the database.

In short, developers can create any custom implementations on the email attributes (like email body, subject, header, to, from addresses etc.)and convert  them into a desired format like a record(of any sObject ), documents , attachment etc. when the email is sent on an Email Service Email Id in salesforce.

Please read all about the capabilities and configuration of email services here:
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_email_inbound_what_is.htm

The process will have following steps:
  1. Email is received in Salesforce.
  2. Email service handles the incoming email and uses email's attributes like subject, body etc. and makes a call-out to the language detection API  without required parameters.
  3. Language is identified by the external service  and  is received as response from the API back in Salesforce.
  4. This language is mapped to the case in a custom field and the same is used as a criteria to design the assignment rules.
  5. Case in inserted with all the info received along with the language identified and a insert DML is fired.
  6. Case is created and based on the language the assignment rules assign it to the respective queue.

Looking forward to suggestions and feedback.



Checkout Other Posts


Comments

  1. A nice read. Have used a similar customization for a client.

    ReplyDelete
  2. Good read...thanks for sharing...

    ReplyDelete

Post a comment

Thanks for your Feedback!


Never Miss Latest Posts