Custom metadata types are similar to custom objects. They allow application developers to create custom sets of data, as well as create and associate custom data with an organization. All custom metadata type data is available in the application cache, which allows efficient access without the cost of repeated queries to the database. It is mainly used to store information that will be frequently accessed from Apex code. It will perform better than a custom object as it doesn't have to be queried. Building a custom metadata types is very similar to building a custom object. The main difference that you will notice is the __mdt suffix at the end of the custom metadata type, as opposed to the usual __c for custom objects. As of the Summer'17 release, custom metadata is not yet available in Process Builder, but is available in Flow. 

Let's look at a business scenario. Helina Jolly is working as a system administrator at Universal Containers. She has received a requirement to auto-create a case whenever a new Chatter post (not a comment) contains a banned word. She also received a list of banned words (almost 50 words) from her manager. If Chatter posts contain numerous banned words, create a single case.

For the preceding business scenario, you can use all 50 words in a Process Builder criteria and use the Create a Record action to auto-create a case. But the problem with this approach is that if, after few days, the business wants to add/remove a few banned words, then you have to start from scratch again. Custom metadata provides the flexibility to add/remove banned words without having to change your Process definition or Flow.

To solve the preceding business requirement, we will use custom metadata types to store the banned words, Flow to compare the banned words with the Chatter post body, and Process Builder to launch the Flow. Perform the following steps to solve the preceding business requirement:

1.  To create new custom metadata type, navigate to Setup (Gear Icon) | Setup | PLATFORM TOOLS | Custom Code | Custom Metadata Types and click on the New Custom Metadata Type button; it will redirect you to a new window, where you have to enter following details:
   • Label: Enter a label for the custom settings. Enter Chatter Post as the criteria name.
   • Plural Label: Enter a plural label. If you create a tab for the custom metadata type, this name will be used. Enter Chatter Posts as the plural name.
   • Object Name: Enter the unique object name; it will be used when the custom metadata type is referenced by formula fields, validation rules, Apex, or the SOAP API. This will be autopopulated based on the Label. 
   • Description: Write some meaningful text so that another developer or administrator can easily understand why this custom metadata type has been created.
   • Visibility: For Visibility, select All Apex code and APIs can use the type, and it is visible in Setup.
2. Once you are done, click on the Save button. 
3. Create a Text field Banned Word to store the words that are not allowed in the Chatter post and make this field a required field. At the end, the Chatter Post custom metadata type should look like what is shown in the following screenshot: 

4. The next step is to insert a few records into the custom metadata type. To do that, click on the Manage Chatter Posts button on the custom metadata type detail page, and then click on New to create some custom setting records, as shown in the following screenshot: 

5. The next step is to create a Flow. To do that, navigate to Setup (Gear Icon) | Setup | PLATFORM TOOLS | Process Automation | Flows. Click on the New Flow button; it will open the Flow canvas for you. Create the variables in the Flow, as shown in the following table:

We will use these variables in the Flow.

6. The next task is to get the Chatter post body. For this, we will use the Record Lookup element. Click on the Palette tab and drag and drop the Record Lookup element onto the canvas; it will open a new window for you, where you have to enter the following details:
   • Name: Enter the name for the Record Lookup element. Enter Get the Feedbody as the name.
   • Unique Name: This will be autopopulated based on the name.
   • Description: Write some meaningful text so that another developer or administrator can easily understand why this Record Lookup element has been added to the Flow.
   • Look up: Select the object for which you want to search the record. In this case, select the FeedItem object. The next task is to define the search criteria. For this, using Id equal VarT_FeedItemId.
   • Assign the record's fields to variables to reference them in your flow: Optionally, you can save the fields' values into variables, so you can use them later in the Flow. Save Body into the VarT_Feedbody variable.

To map the fields, you can use the information in the following screenshot:

7. Once you are done, click on the OK button.
8. The next step is to get all the banned words from custom metadata type. For this, we will use the Fast Lookup element. Click on the Palette tab and drag and drop the Fast Lookup element onto the canvas; it will open a new window for you, where you have to enter the following details:
   • Name: Enter the name for the Fast Lookup element. In this case, enter Get all banned words as the name.
   • Unique Name: This will be auto-populated based on the name.
   • Description: Enter a meaningful description.
   • Look up: Select the object for which you want to search the records. In this case, select Chatter_Post_mdt. The next task is to define the search criteria; for this, select banned_word__c as the field, the does not equal operator, and the global constant 
     {!$GlobalConstant.EmptyString} as the value.
   • Variable: Use the SObject Collection variable SOCVBannedWords. Don't forget to select the Assign null to the variable if no records are found checkbox. Finally, select the fields whose values you want to store in the SObject variable or SObject Collection variable; in this case, select banned_word__c.

To map the fields, you can use the information in the following screenshot:

9. Once you are done, click on the OK button.
10. The next task is to check whether the SObject Collection variable contains any banned words or not. To check this, we will use the Decision element. To do that, drag and drop the Decision element onto the Flow canvas. Enter the name Check SObject Collection Variable Size, and Unique Name will be auto-populated based on the name. Optionally, you can also add Description for the Decision element. Then, create two outcomes for the Decision element, which are as follows:
    • Not Exist: Enter the name Null as DEFAULT OUTCOME
    • Not Null: Select the SObject Collection variable SOCVBannedWords, the is null operator, and the {!$ GlobalConstant.False} global constant as the value. 

11. Once you are done, click on the OK button.
12. If the SObject Collection variable is not null, that means that it contains some banned words. We will use the Loop element to extract records from the SObject Collection variable (SOCVBannedWords) and store it to the SObject variable (SovBannedWord). Click on the Palette tab and drag and drop the Loop element onto the Flow canvas. It will open a new window for you, where you have to enter the following details:
    • Name: Enter the name for the Loop element. In this case, enter Loop over collection as the name.
    • Unique Name: This will be auto-populated based on the name.
    • Description: Write some meaningful text so that another developer or administrator can easily understand why this Loop element was created.
    • Loop through: Select the SObject Collection variable SOCVBannedWords. Select the order as Ascending to loop through the collection.
    • Loop Variable: Select the SObject variable or variable as Loop Variable. In this case, select the SObject variable SovBannedWord as the loop variable.

To map the variable, you can use the information in the following screenshot:

13. Once you are done, click on the OK button.
14. The next task is to check whether VarT_feedbody contains any banned words or not. To check this, we will use the Decision element. To do that, drag and drop theDecision element onto the Flow canvas. Enter the name Lookup for banned words and Unique Name will be auto-populated based on the name. Optionally, you can also add a description for the Decision element. Then, create two outcomes for the Decision element, which are as follows:
    • Not Found: Enter the name Null as DEFAULT OUTCOME
    • Found: Select the variable VarT_Feedbody, which contains the operator, and {!SovBannedWord.banned_word__c} as the value
15. Once you are done, click on the OK button.
16. If the VarT_Feedbody variable contains a banned word, then we have to create a new case. Click on the Palette tab and drag and drop the Record Create element onto the canvas; it will open a new window for you, where you have to enter following details:
    • Name: Enter the name for the Record Create element. In this case, enter Create new case as the name.
    • Unique Name: This will be auto-populated based on the name.
    • Description: Write some meaningful text so that another developer or administrator can easily understand why this Record Create element was created.
    • Create: Select the object for which you want to create the record. In this case, select the Case object. The next task is to assign the value or resource to the object fields (data types must match). To assign a value to multiple fields, click on the Add Row link.
    • Variable: Optionally, you can save the new record's ID into a variable, so you can use it later in the Flow.

To map the fields, you can use the information in the following screenshot:

17. Once you are done, click on the OK button.
18. Use the connector to connect the elements used in the Flow. Set the Record Lookup element and Get the Feedbody as the Start element, as shown in the following screenshot:

19. Save your Flow with the name Custom metadata type in Flow,  select Type as Autolaunched Flow, and click on the Close button to close the canvas. Don't forget to activate the Flow.