Restrict Case Creation From Unwanted Email Domains – Using Custom Metadata Types

You are currently viewing Restrict Case Creation From Unwanted Email Domains – Using Custom Metadata Types

The native Email to Case feature in Salesforce doesn’t allow you to restrict Case creation when an Email comes in from certain domain/(s). You can certainly specify the Allowed Email addresses in the ‘Accept Email From‘ text box to limit the email addresses or domains available for On-Demand Email-to-Case. However it’s not the perfect way to handle such a scenario if you have a ton of legit ‘From Addresses‘ feeding Cases into your Salesforce org. Consequently, a lot of junk Cases get created in Salesforce from unwanted domains (mostly internal) which are first assigned to something like a ‘Junk Cases Queue‘ and then cleaned up either using Flows or manual deletion.

So why even let such Cases make their way into Salesforce when you can write a simple Apex class to kill the junk Case way before it’s created? My good friend Deepak Anand recently made me aware of Custom Metadata Types in Salesforce that were introduced in the Summer ’15 release and seemed to be perfect for this use case. We henceforth decided to utilize them to make the Restricted Domains part configurable via the UI. These immensely useful Custom Metadata Types provide you with the superpower of creating your own metadata types which was earlier never possible! If you want to get an in-depth idea about their benefits and usage, feel free to go through this. And just like custom settings, they give an authorized person the ability to change the needed variables on the fly thus sparing you the trouble of making those changes to code in sandbox and then re-deploying them. Another convincing reason why I decided to go for them is that their records are metadata themselves so they can be conveniently migrated using Changesets. Isn’t that neat? Without further ado, let’s get down to business and make your Salesforce org a better and cleaner place by eliminating unwanted Cases.

  1. Create the Custom Metadata Type:
    Navigate to Setup -> Develop -> Custom Metadata Types and create a new one. Below is how you configure the custom metadata type.Support Setting
  2. Add a record to the created Custom Metadata Type:
    This record will be used to specify the email domains that should be restricted from creating Cases in Salesforce. Please note that this Support Setting can hold multiple records, each one behaving as a custom object on its own. We are creating one for Restricting Email domains and you can have multiple others for different purposes.Restricted E2C Domains
    If an email is ever sent to the Email-To-Case routing address and it belongs to one of the above listed domains, our goal is to prevent Case creation from such a domain.
  3. Create the method to extract the domain values from the above created Custom Metadata Type:
    The getSupportSettings method below first extracts the domain values into a Support Setting type sObject and then uses the split function to properly separate them and load them into a set.Support setting extraction
  4. Create the method with the main business logic to process Cases and accordingly kill them:
    Here is where we take care of our primary logic to prevent those sneaky Cases from creeping into Salesforce.

    Click to Expand Image
  5. Create a Before Insert trigger on Case object:
    This trigger will fire before Case creation and the purpose is to feed the List of Cases to our Method in Step 4 above. The Cases will then be processed in order to determine if they should be created or not.E2C trigger


And finally for the test methods, you can have something like the following (you should add more checks for better coverage and reliability):

Negative Assertion


Positive Assertion


Wasn’t that simple? Now if someone ever wants to restrict a domain other than the ones included in the Support Settings record (Restricted_E2C_Domains) above, it’s as simple as accessing this record, modifying the Value field and our code will take care of the rest. Now when I have to deploy all of this code in Production, I simply create a Changeset with my Apex Class, Test Class and Support Settings metadata (even the associated records since they are metadata themselves) and upload the Changeset. If someone asks you to add a new domain to the list of restricted domains, guide them to the Support Settings and show them how easy it is to change that, like a BOSS!