Few points to Note:

  1. E2C settings needs to be created for each Queue (for which email-to-case process is needed)
  2. Only 1 E2C configuration record can be created per queue.

Browse to “Email-to-Case Settings” available within “Configuration Settings” and click New.

Explanation of form fields:

Tab:1:General:

Applicable Queue: Select the Queue for which “Email-to-Case” process needs to be enabled.
Do not process emails older than X hours: If you delete emails from Dynamics 365 but not from mailbox… then it gets re-created again in Dynamics 365.
If you want to exclude email-to-case process to run for such emails then can use this setting.
Exclude duplicate email: If a Requestor sends email to your support mailbox and also marks the same email to a Dynamics 365 user who has server side sync enabled for received emails… then multiple Cases can get created for same email.
This is because…Dynamics 365 will create 2 email records…one for email received in your support mailbox… and another one for email received by server side sync from user’s mailbox.
If you want to exclude such emails from creating duplicate cases then enable this setting.
Description: Enter user-friendly description
Email Alias: To learn about email alias feature, refer blog: link

Tab :2: New Case:

==========Section: Attach Customer::==========
Auto Attach Case To Customer Based On:
Option 1: Account-Contact (Recommended)
Option 2: Account (Search Contact & Link Parent Account)
Option 3: Contact (Search Contact Only)
Option 4: Account/Contact GUID

Option 1: Account-Contact [Recommended]
Match Sender Email Address against Contact record. If match found then Set Case.Customer to “Parent Account” (Also populate Case.Contact with matched contact record).
If no “Parent Account” then Set Case.Customer to matched Contact record

Option 2: Account (Search Contact and link Parent Account)
Match Sender Email Address against Contact record. If match found then Set Case.Customer to “Parent Account”.

Option 3: Contact (Search Contact)
Match Sender Email Address against Contact record. If match found then Set Case.Customer to Contact record.

Option 4: Account / Contact based on GUID
Please ignore this option. This was done for a customer who was passing GUID values for Account/Contact record within the email body. We extracted these values using “Email Parsing” functionality and then accordingly populated Case.Customer.

Please note that in all the above scenarios, we also populate:

  1. Custom field “Sender Contact” (Contact Lookup) with matched contact record.
  2. Custom field “Sender Email” (Text field) with email address of Sender.

Both the above fields could be useful in your internal workflow processes.

Please note the below points regarding how we match Sender Email Address with Contact’s email address:

  1. To find a matching Contact, we match the Sender’s email address with Contact email address fields (Email, Email Address 2 and Email Address 3).
  2. If you are using “Email Parsing” feature to create Case…and have sender’s email address within email body (Web to Case scenario)…then populate the custom text field “Sender Email” using a parsing rule. If this field has value then Helpdesk App will use this email address to match Contact record (instead of actual sender’s email address).

No Matching Found then:
Option 1: Do not create Case
Option 2: Link to Default Account
Option 3: Link to Default Contact

Default Account: We suggest creating a Account with name “Dummy Account” OR “Default Account”  and select it here.
Default Contact: We suggest creating a Contact with name “Dummy Contact” OR “Default Contact” and select it here.
If no matching contact or account is found for the senders email address…then the Case.Customer will be linked to a Dummy\Default Account or Contact based on above settings.

Multiple Matching Found:
If multiple contacts are found with same sender email address… then we can set Case.Customer to either a Dummy Account (Multiple Found) or Dummy Contact (Multiple Found).
Please note that “Dummy Account (Multiple Found) is another placeholder account record that you create…

==========Section: Contact/Account Creation::==========
For creating a “New Contact” when email is received from an unknown sender, you have 2 options:

Option 1: You can have Dynamics 365 automatically create the Contact for unknown sender. This can be done by enabling setting “Create contact from sender of tracked email message”. This setting is available under user’s personal settings. This needs to be done for the user who is the Owner of the Support Queue.

Option 2: Let Dynamics 365 create the New Contact automatically (as mentioned in Option 1)…and complement this functionality by Helpdesk “Match & Set Parent Account” feature! [THIS IS RECOMMENDED]

Match & Set Parent Account: If this setting is checked then app will search for another contact with same domain and link the parent account of that contact with this newly created contact.

Exclude Email Domains (;): This is semicolon separated list of email domains that need to be excluded when doing “Match & Set Parent Account”. (non-company email addresses like gmail.com, hotmail.com etc needs to be ignored)

Contact Owner: This will be the owner of the newly created contact. If “Match & Set Parent Account” is enabled then the contact “owner” will be over-ridden by the parent account “owner”.

==========Section: General::==========
Case Title Text Size: Helpdesk App copies the email subject to the “Case Title” field of the newly created case. The text is truncated based on this value. Default value is 200 characters.
Case Description Text Size: Helpdesk App copies the email body text to Case Description of the newly created case. The text is truncated based on this value. Default value is 2000 characters.
Route Case to Queue: Select Queue to which the case would be moved on creation.
Remove Email from Queue: If yes, then the email will be moved out of the current queue after creation of the case.
Select Default Case Owner Type (User/Queue): This will be the default case owner.
Created By User (Optional): This will be the Case Created By User.
Do not create Case, if queue email received in CC list
: If this setting is checked then emails having queue email address in CC section will be excluded from case creation.
Show Sender & Recipients at top of Case Description:
Case Origin: Set default Case Origin for newly created case.
Case Status: Set default Case Status for newly created case.

Tab:3:Email Exclusion/Inclusion:

3A: Email Exclusion/Inclusion Criteria
3B: Loop Protection

==========3A: Email Exclusion/Inclusion Criteria==========

Rule-Type: Exclusion/Inclusion
Exclusion is generally for Spam Protection. This allows you to exclude emails from Case Creation based on criteria: Sender Email Address/ Sender Email Domain Match or Email Subject Keywords.

Inclusion: If you need to allow Case Creation only when the incoming email matches one of the criteria’s then use this option. For example if you want Cases to be created only when email is received from  abc@xyz.com…then Inclusion criteria would work best.

Domain: This is a semicolon separated list of domains. Emails matching any of this domain would be excluded/included from case creation (based on Rule Type selected).
Email Addresses: This is a semicolon separated list of email addresses. Emails matching any of these would be excluded/included from case creation.
Subject Keywords: This is a semicolon separated list of keywords. Email subject having any of these matching keywords would be excluded/included from case creation. (e.g. spam, undelivered, out of office, no reply, etc)

==========3B: Loop Protection==========

Loop Time protection (in minutes) and Loop Count Protection (in number):
When using email-to-case, email loops can occur when the sender has an auto-reply set. In this scenario, Helpdesk will send a new case email notification and sender will reply back with an auto-reply. This back and forth emails can result in lot of unwanted cases created in Dynamics 365.
Default values for below fields are:
Time Block (in minutes): 10
Loop Count (in number): 3
Based on this setting, if email having same sender is received in Dynamics 365 for more than 3 times within 10 minutes block then Case will not be created for the fourth received email. This will break the back-and-forth loop with the sender.

Tab:4:Existing Case Check:

When an email is received in Dynamics 365 regarding an existing case, Helpdesk App extracts the case number from email subject and matches against open or closed cases based on below settings:

Attach Email to existing Case using:
Option 1: Do not check. Create New Case always.
Option 2: Search for Case Number in open case
Option 3: Search for Case Number in open + closed case (Recommended)
Fall-back to OOB Smart Matching: Dynamics 365 uses a smart-matching or tracking token technique to match an incoming email to a Case. This technique is not very reliable…and hence our Helpdesk App extracts Case Number from email subject and matches to the cases in Dynamics 365(this is 100% foolproof). However if for some reason…case number is not present in email subject… then we have an option to fallback to Dynamics 365 Out-of-box technique (identify using Smart Matching or Tracking Token) to match incoming email to a case.
Re-Open case closed: This field is shown when “Option 3” is selected in “Existing Case Check”.
Option 1: Always
Option 2: Within X Hours
X Hours: Enter X hours within which if email is received then the closed case will be re-opened. If time-difference is more than X hours then new case will be created. Default value is 48.
Remove Email from Queue:  If yes, then the email will be moved out of the current queue after re-opening of existing case.
Reset Case Status (for Open Case) & Reset Case Status (for Re-Open Case):
When a new email is received regarding an existing open case…Helpdesk App can reset the Case Status (eg if present Case Status was: “Waiting for Requestor Response”…you could automatically reset this Case Status to: “New Response”).

This functionality works correctly only when “Internal domain” / “Internal email addresses” fields are populated in “Additional Case Settings”

These settings are used to identify whether the email received in Dynamics 365 is from Requestor or not…
For example:
Requestor sends email to support. Helpdesk app creates a new Case and sends acknowledgement email back to Customer.
New Case Internal Email notification is Sent (to your support team).
Now back and forth communication happens between support agent and Customer. Each time a new email communication is received from the Customer…Helpdesk app generates an internal email notification (which goes to your support team)…
To send this internal email notification…Helpdesk App needs to recognize that the email was received from Requestor (and not sent by support agent)…
The way we identify whether the received email is from Requestor and not support agent is by checking the email domain of received email…
Best practice: Whenever a support team member is responding to a customer from their own mailbox then mark support@.. email address in CC section. This will ensure that the email is always tracked against the case.

Tab:5: Rules Configurator:

Smart Rules configurator allows you to create multiple rules which can:

  • Route the Newly Created Case to specific Queue
  • Set the Owner of the Case to User/Team
  • Set default values for Case fields (origin, priority,…)

Each rule has capability to define a condition and an action. The Condition can be based on Case.Customer or Sender Email/Domain or Keywords Match with Email body/subject.

For understanding about various Rule-Types refer blog.

Scroll to “Smart Rules Configurator” grid and click “+”.

Name: Enter a user-friendly name
Rule Type: Default Always / Sender Email Match / Customer Match / Keyword Match
Sequence Number: The rules are executed based on sequence number (in increasing order). Rule with sequence number 0 is executed first. All rules are executed. It is possible that rule with a higher sequence number could over-ride values of rules with lower sequence number.
Condition: This section would show up based on the rule type.
Action: Set Default Value
In Default Values section click “+”.
Then select the Default Value field (Case field) and then enter the default value.
e.g. To set Case origin as “email”:
Click “New” button. This opens up “Zap HD Default Value” form
Select “Default Value Field” as “Origin”
Enter “Default Value” as “email”
Please note that for a 2-option field…value can be true/false or yes/no or 1/0.

Tab:6: Fwd to New Case:

If your customers frequently send support requests to support agent mailbox (eg agent1@zapobjects.com) instead of generic support mailbox (eg. support@zapobjects.com) then this “Forward to New Case” feature can come-in very handy!

“Forward to New Case” allows creating of a new case by forwarding the customer email to support mailbox. Zap Helpdesk then intelligently retrieves the customer email address from the forwarded email and links the case to the customer!

Below are the settings:

Forward Email Marker Text (;): #;Fwd:;FW:;Fw:;
Domain Filter (;): e.g. zapobjects.com //only emails received from this domain can use this “Forward to New Case” feature. If this field is left blank then no domain filter is applied to incoming email.
Internal Email Addresses Filter(;): Only emails received from email addresses mentioned in this field can use this feature.

Let’s consider an example:

Step 1: Customer sent an email to agent personal mailbox instead of support@..
=================
email subject: laptop not starting up
=================

Step 2: Agent forwards this email to generic support mailbox (support@…).

=================
email subject: FW: laptop not starting up @@mark.smith

email body:

From: Dan Cary [mailto:dcary@zipcart.com]
=================

Before forwarding this email, the email subject was tweaked to have the marker “FW:”
This tells the app, that “Fwd to New Case” feature is being used.

Helpdesk will also validate the domain of the received email against the internal domain (zapobjects.com). So only users from internal domain (zapobjects.com) can use this feature. The validation will happen only if the “Internal Domain” has been specified.

Helpdesk App extracts “dcary@zipcart.com” email address from email body and matches against the contacts in Dynamics 365. The Case.Customer will be linked to the parent account of matching contact (based on configuration settings).

For more details, regarding this feature refer blog link.

Tab: 7: Email Parsing:

Email Parsing allows parsing the received email to extract text and directly populate the Case record.

Some common user-scenarios are like:

Use-Case 1: You may also have a “Support Request” page on your website. When user fills in the page, you may be receiving an auto-generated email with the customer issue details.

Use-Case 2: You may be using a legacy system which sends an automated email in a particular format to your support mailbox with issue details.

For both the above use-cases, you can use Helpdesk “Email Parsing” feature, to parse these emails and create Case record in Dynamics 365…with all important case fields populated with the issue details.

Use-Case 3: For creating new cases, your customer may be sending email to your support mailbox.
You are already using Helpdesk App to automatically convert these emails to Cases in Dynamics 365.
Using this new “Email Parsing” feature, you can have customer send in additional details and have them automatically populated in the Newly created Case.
For example…you could send below text in email and have the Case fields automatically populated.
Priority: high (Option-Set)
Additional Comments: XYZ (Custom field on Case)
Internal Issue: Yes (Custom 2-Option Set)

Important points to note regarding Email Parsing feature:
1. This feature is applicable only for new Case creation. We do not apply email parsing for for an existing Case.

2. You can create multiple email parsing configuration records… and use filters to decide which parsing configuration will apply to which email… (Each parsing configuration will have its own set of parsing rules)
Filter conditions could be based on:
– Email Domain(s):
– Email Address(s):
– Email Subject(s):

Please note that the filter conditions will apply only when checkbox “Enable Email Parser Filters” is checked!

If this field “Enable Email Parser filters” is un-checked then the first enabled “Email Parser” configuration record (sorted by Name) will be used for parsing.

3. By default the “Sender Email” is extracted from actual email recipient list…however if you need to extract this value from email body then create a parsing rule and use source field as “Zap Sender Email”. Helpdesk App will then search for a contact matching this email address… and set the Case.Customer and Case.Contact based on the configured settings.

4.If you enable “Contact creation” feature and also need to set Contact First Name and Last Name (of newly created contact) based on parsed value then create parsing rules as shown in screenshot below:

Explanation regarding “Email Parsing Settings”:

Creating parsing rules (Create a New “Zap HD Parsing Rules” record)

A Parsing Rule is a collection of simple instructions which tell our algorithm what kind of data you want to pull out from your emails. Typically you’ll create multiple parsing rules, one for each data field inside your email (e.g. customer name, company etc.).

A basic parsing rule would be one which extracts a data value which can be found inside the body of the email. Ideally this value has a preceding label which stays the same in all emails (e.g. “First Name:”, “Email:”, “Shipping Address:”, …).

Below are the high level steps in creating parsing rule:

  1. Select the field (eg Case.Priority)
  2. Select a data source (e.g. email body, email subject)
  3. Add a Start position text-filter which defines the start of your variable (e.g. search for “Priority: “)
  4. Add a End position text-filter which defines the end of your variable (e.g. “end of line”)
  5. Refine the result with additional settings like trim, remove empty lines, extract first name, extract last name, etc

Below is the explanation of the fields on parsing rule form:

========== Section 8A: General ==========

  • Destination Field: Select the field in which the extracted value needs to be saved.
    Presently following field data-types are supported:

    • Single line Text
    • Multi-line Text
    • Option-Set (here match is performed against option-set values)
    • 2-Option Set (extracted text is match against these values: yes/no, true/false, 1/0)
    • Date-Time (For date-time data-type, mark the checkbox “Format Date” under section: Apply Text Refinements. Then select the date-time format that closely matches the extracted text.)
    • Currency
    • Decimal
    • Whole-Number
    • Owner (This could be a user or team.The extracted text is matched first against user “email address” or “full name”. If no match found then matched against team name.)
  • Data Source: This is the data source from where the text will be extracted.
    The various values for data source are as follows:

    • Email Subject: The text would be extracted from email subject.
    • Email Body: The text would be extracted from email body.
    • Email Recipients: The text would be email address or full name as retrieved from email header.
    • Default Value – This will allow you to add a default value for the destination field.
      For example if you have the destination field as Lead.Lead Source, then you can specify a default value for this option-set called as “Web”.
==========8B: Set up parsing rule==========
  • Start Position: Add a Start position text-filter which defines the start of your content that needs to be extracted.
    Below are the options:

    • None: This is normally selected when the data-source is “Default value” or “Email Recipients”.
    • Text Match After: Enter the text filter that defines the start of the content that needs to be extracted.
    • Start of Content: Select this option to have the content to be extracted start from the beginning of content.
  • End Position: Add a End position text-filter which defines the end of your content that needs to be extracted.
    Below are the options:

    • None: This is normally selected when the data-source is “Default value” or “Email Recipients”.
    • End of Line: The end position of content to be extracted is end of line.
    • End of Content: The end position of content to be extracted is end of content.

==========Section 8C: Apply Text Refinements==========

This section has settings for cropping and cleaning of the extracted content.

  • Trim: To remove blank spaces from the left and right of text.
  • Remove empty lines
  • Remove line breaks
  • Truncate text size: If you would like to truncate the extracted text then mention the text length. The default text length for CRM single line text field is 100.
  • Extract First Name: This setting extracts the word before space of extracted content as First Name.
  • Extract Last Name: This setting extracts the word after space of extracted content as Last Name.
Tab: 8: Test Run:

The classic approach to test email-to-case scenario is to send email to support queue and then wait for it to arrive in Dynamics 365…before it can be converted to case.
Zap Helpdesk App now has a “Test Run” feature which would allow you to test multiple scenarios instantly…right from within the configuration page…no more waiting…

Tab: 9: Copy Attachments:

Email Received For New Case: To enable Copy attachments feature for New Case creation.
Email Received For Existing Case: To enable Copy attachments feature for email received for existing Case.
Action: Copy to Case / Copy to Case & Remove from Email.
Filter – Min. Size (KB): Only attachment above this minimum specified size would be copied over.
Filter – Max. Size (KB): Only attachments having size less that this maximum specified size would be copied over.
Filter By – File Type Criteria: Inclusion / Exclusion
If you select “Inclusion” then:
Allowable File Types (;): Only allow file types mentioned in this    list would be copied over.
If you select “Exclusion” then:
File types to exclude (;): If file types not mentioned in this list would be copied over. Please note that if you specify value in “Allowable file types” field then this setting would be ignored!

Please note that when copying over the attachments from email to Case-Notes, we also populate the “Notes Title” with attachment file name.

Tab: 10: Case No. Format:

////Please ignore this section, if you are using out-of-box “Case Number” field and don’t have a custom auto-numbering defined for Cases./////

Zap Helpdesk App uses “Case Number” field as the primary key field which is unique across all cases. The standard out-of-box case number format is like “CAS-00034-Z7M9F7”. You also have the option to create a new field in case and have your custom auto-numbering defined on it. If you are using custom case auto-numbering then select that field in below setting:

Case Number Field: You can either use default “Case Number” field or any other custom case field (which has autonumber set)
Prefix (textbox): This is mandatory field
Select Suffix: Default suffix is “space”.
Exclude prefix-suffix from case number (checkbox): Yes/No. This tells helpdesk app whether prefix and suffix text are part of case number or not.

Helpdesk App uses the above settings to identify and extract the case number from email subject. Below are some examples of case number and corresponding values for above fields:

  1. Case Number is CAS-00034-Z7M9F7. This is the default format for value of “Case ID” field in CRM.
    Case Number Field: Case ID
    Prefix: CAS
    Suffix: Delimiter-Space
    Exclude Prefix-Suffix from Case Number (Checkbox): No
  2. Case Number is CAS1234
    Case Number Field: Custom Case field
    Prefix: CAS
    Suffix: Delimiter-Space
    Exclude Prefix-Suffix from Case Number (Checkbox): No
  3. Case Number is {{12345}}
    Case Number Field: Custom Case field
    Prefix: {{
    Suffix: }}
    Exclude Prefix-Suffix from Case Number (Checkbox): Yes

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *