Custom Metadata Type let you use records to configure your app without worrying about migrating those records to other orgs. You can deploy the records of custom metadata types from a sandbox with change sets or packaged in managed packages instead of transferring them manually. With Custom Metadata Types, you can customize, deploy, package, and upgrade application metadata that you design yourself. When you create Custom Metadata Type, you also create custom fields on that type. Custom meta data support below field types. Metadata Relationship Checkbox Date and Date/Time Email and Phone Number Percent Picklist Text and Text Area URL How to create Custom Metadata types? To create, go to setup -> Custom Metadata Types and click on new custom metadata types button. Fill required details. Custom metadata type api name ends with “__mdt”. After creating this, you will get an option to create fields, layout and validation rules. Once you are done with you can create records like custom setting. And you can use this in Apex.

Custom metadata types vs. custom settings

Custom Metadata Type let you use records to configure your app without worrying about migrating those records to other orgs. You can deploy the records of custom metadata types from a sandbox with change sets or packaged in managed packages instead of transferring them manually.

With Custom Metadata Types, you can customize, deploy, package, and upgrade application metadata that you design yourself.

When you create Custom Metadata Type, you also create custom fields on that type. Custom meta data support below field types.

• Metadata Relationship
• Checkbox
• Date and Date/Time
• Email and Phone
• Number
• Percent
• Picklist
• Text and Text Area
• URL

How to create Custom Metadata types?

To create, go to setup -> Custom Metadata Types and click on new custom metadata types button.

Fill required details.

Custom metadata type api name ends with “__mdt”.

After creating this, you will get an option to create fields, layout and validation rules.

Once you are done with you can create records like custom setting. And you can use this in Apex.

Simplify Your Salesforce Data with Custom Metadata Type Relationships

Custom metadata types are better than ever before! In Spring ’17 we added new custom metadata relationships, which let you look up other custom metadata types, entity definitions, and field definitions. Out of the box you can create relationship between your custom metadata type and the following metadata types:

• Another custom metadata type
• Entity definition
• Field definition

Let’s look more closely at the different relationships that custom metadata types have to offer.

Relationships Between Two Custom Metadata Types

Let’s say your application needs to calculate sales tax for the various locations of your business. Usually sales tax combines both city and the state taxes. Let’s see how we can solve this use case with custom metadata relationships.

Relationship between two custom metadata types

In the example, we use two custom metadata types to store city and state taxes. Custom metadata type object for city tax has a relationship to the one that stores the state’s tax rate. This relationship makes it easy to calculate your final sales tax by combining city and state sales tax rates.

Relationships Between Custom Metadata Type and Entity Definition

Another type of relationship supported on custom metadata types is the custom metadata type to entity definition object relationship. What that means is that custom metadata types can now lookup standard and custom entities that are part of your org.

Custom Metadata Type to Entity Definition relationship

In the example above, we use Custom Metadata Type to store Service Level Agreement (SLA) data for different types of standard and custom objects that can be created in your org. Let’s say your company has a policy that newly created invoices have to be reviewed within a 12-hour time frame. So in this case, Custom Metadata Type to Entity Definition relationship helps to define SLA requirements in your org.

Relationships Between Custom Metadata Type and Field Definition

We aren’t done yet! In Spring ’17, we also introduced a new type of relationship: custom metadata type to field definition. The custom metadata type to entity and field definition relationships let you specify what particular field you want to update on each entity type.

Custom Metadata Type to Field Definition relationships

In the example above, when a new referral is created in your org, you can use your app code to populate Source__c field with a value “Internal” by using info stored in your custom metadata types.

SOQL example

Let’s take a look at how custom metadata type relationships can be queried in SOQL. In my developer edition org, I’ve implemented a custom metadata type with FieldDefinition relationship from the example we looked at earlier.

Custom Metadata type example

To query default value for the Account entity, developers can use a simple query like this one:

1	SELECT Entity_Relationship__c, Field_Relationship__c, Default__c FROM Source_Default_Value__mdt WHEREEntity_Relationship__c = 'Account'

the result looks like the following:

Custom Metadata Types vs. Custom Settings

In addition to what we described above, there are other advantages of using custom metadata types.

Custom Settings and Custom Metadata Type side-by-side

As you can see, custom metadata types provide you with significantly greater flexibility over custom settings!

Custom metadata type relationships provides additional flexibility on how you can approach your app configuration problems. With features that enable you to map custom metadata to other custom metadata, entity or field definitions, we’re making it even easier for you to configure and manage your orgs. Want to dive deeper? Check out our Trailhead Module, official docs and share your experience in the Success Community group!

Resources

• Introducing custom metadata types: the app configuration engine for Force.com
• Custom Metadata Types | Salesforce Trailhead
• Metadata Relationship Fields Now Fully Supported (Generally Available) Salesforce Winter ’17 Release Notes
• Custom Metadata Type – Success Community Group

Access Custom Metadata Records Programmatically

Use SOQL to access your custom metadata types and to retrieve the API names of the records of those types.

REQUIRED EDITIONS

Available in: both Salesforce Classic and Lightning Experience

Available in: Professional, Enterprise, Performance, Unlimited, Developer, and Database.com Editions Professional and Group Edition orgs can create, edit, and delete custom metadata records only from types in installed packages.

Apex code can create, read, and update (but not delete) custom metadata records, as long as the metadata is subscriber-controlled and visible from within the code's namespace. DML operations aren’t allowed on custom metadata in the Partner or Enterprise APIs. With unpackaged metadata, both developer-controlled and subscriber-controlled access behave the same: like subscriber-controlled access. For information about the Custom Metadata Type__mdt sObject, see Custom Metadata Type__mdt in the Object Reference for Salesforce . Refer to Trust, but Verify: Apex Metadata API and Security to learn more about package access in developer-controlled and subscriber-controlled orgs.

The following example declares the Apex variable custMeta of the custom metadata type MyCustomMetadataType__mdt, which is in your namespace.

MyCustomMetadataType__mdt custMeta;

Declare the custMeta variable of the custom metadata type TheirCustomMetadataType__mdt, which isn’t in your namespace but is in the their_ns namespace.

their_ns__TheirCustomMetadataType__mdt custMeta;

The following example is a simple query that returns standard and custom fields for all records of the Threat_Tier_Mapping custom metadata type and accesses some of their fields.

Threat_Tier_Mapping__mdt[] threatMappings = [SELECT MasterLabel, QualifiedApiName, Field_Mapping__c ,Minimum_Support_Level__c FROM Threat_Tier_Mapping__mdt];

for (Threat_Tier_Mapping__mdt threatMapping : threatMappings) {
    System.debug(threatMapping.MasterLabel + ‘: ‘ +
                 threatMapping.Field_Mapping__c + ‘ from ‘ +
                 threatMapping.Team_Building_to_SFA_Field_Mapping__c + ‘ to ‘
                 threatMapping.Minimum_Support_Level__c);
}

To provide an entity that looks more like a Schema.SObjectDescribeResult than SOQL, make the Apex class vacations.ThreatTierMappingDescribeResult encapsulate the information queried from vacations__ThreatTierMappingDescribeResult__mdt. Then create the class vacations.Vacations with methods such as:

vacations.ThreatTierMappingDescribeResult describeThreatTierMappings(String qualifiedApiName) {
    Threat_Tier_Mapping__mdt threatMapping = [SELECT <fields> FROM Threat_Tier_Mapping__mdt WHERE QualifiedApiName = :qualifiedApiName];
    return new ThreatTierMappingDescribeResult(<fieldValues>);
}

In the preceding example, <fields> refers to the fields you want to include in the describe and <fieldValues>refers to the values of those fields.

The next example uses a metadata relationship that references another custom metadata type,Team_Building_to_SFA_Field_Mapping__mdt, to do a simple right outer join.

ThreatTierMapping threatMapping = 
    [SELECT MasterLabel, Team_Building_to_SFA_Field_Mapping__r.MasterLabel FROM Threat_Tier_Mapping__mdt WHERE QualifiedApiName=‘Easy_Vacations’];

System.debug(threatMapping.MasterLabel + ‘ is part of ‘ + Team_Building_to_SFA_Field_Mapping__r.MasterLabel);

The following example shows a left outer join starting from EntityDefinition. This query uses a relationship field called Team_Building_Object__c on Team_Building_to_SFA_Field_Mapping__mdt. The child relationship name of this relationship field is Field_Mappings_From.

for (EntityDefinition entity : allObjects) {
    System.debug(‘Processing mappings for: ‘ + entity.QualifiedApiName);
    for (Team_Building_to_SFA_Field_Mapping__mdt fieldMapping : entity.FieldMappingsFrom__r) {
    System.debug(‘  Field ‘ + fieldMapping.Team_Building_Field__c + 
        ‘ has mapping ‘ + fieldMapping.QualifiedApiName);
    }
}

Salesforce: Setup Audit Trail

Setup audit trail helps to track setup changes done by system administrators or users with extra permissions. This feature is very useful for organizations with multiple administrators; or even to find if you forget when to a feature is enabled.

You can view the setup audit trail history, from Setup - Security Controls - View Setup Audit Trail. It will show latest 20 entry,  you also can download up to past 180 days history into CSV file. Audit Trail will show information of Date, User, Action, Section, and Delegate User (if any).

Please note that NOT ALL changes is tracked in Audit Trail, such as: Outlook Configurations, List Views and etc. Here list of type tracked in Audit trail :
- Administration
- Customization
- Security and Sharing
- Data Management
- Development
- Various Setup
- Using the application