Salesforce Platform Dev II Exam Preparation: Data Modeling and Management

Our second chapter will revolve around Data Modeling and Management which consists of 7% of total score in Salesforce Platform Dev II Exam. Without further ado, let's get into it!

NOTE: This post is written in July 2019 and content might be changed/updated overtime. The content is inspired by focusonforce.com.

Introduction

• The powerful Salesforce application is able to adapt to variations of language, locale and currency:
  • Language - controls label and translations
  • Locale - controls data formatting such as dates, times, and names
  • Currency - controls display of currency, such as currency symbols and use of period and comma for decimal places.
• Useful functions in System.UserInfo class:
  • getDefaultCurrency()
  • getFirstName()
  • getLanguage()
  • getLocale()
  • getName() - get full name
  • getOrganizationId()
  • getOrganizationName()
  • getSessionId()
  • getTimeZone()
  • getUserEmail()
  • getUserId() - return the user Id
  • getUserName()
  • isMultiCurrencyOrganization()

Multi-Language

• Language controls labels and translations.
• Salesforce provides 3 levels of language support:
  1. Fully Supported Languages - all standard pages and features automatically translate based on the user's selected language.
  2. End-user Languages - all standard objects and pages, except administrative pages, Setup and Help
  3. Platform-only Languages - developer-sepcified translations for languages not supported by Salesforce, mainly used in custom objects, labels and fields.
• Translation Workbench can be used add or activate languages in Salesforce.
  
• You can select the Language and then select Setup Component that you would like to translate.
  
  
• You can also create Custom Label and set the translation to display user friendly text.
  
  
  
• In formula, label can be accessed via $Label.Testing_Text; meanwhile in Apex, simply write Label.Testing_Text will do.
• To make error message more "translation friendly", you can type like this:

ApexPages.addMessage(
    new ApexPages.Message(ApexPages.Severity.ERROR, Label.Testing_Test)
);

Multi-Locale

• Locale controls formatting such as number, date, time, name and etc.
• Locale-aware output components such as <apex:outputField> should be used in Visualforce so that data format can be displayed correctly.

Multi-Currency

• Currency controls display of currency, such as currency symbols, period/comma for decimal places.
• All objects that have currency field will have CurrencyIsoCode field to specify the currency that is used (available in multi-currency org)
• In SOQL, convertCurrency() function can be used to convert currency and format() function can be used in SOQL to format number, date, time, fields based on user's locale, ex: SELECT format(convertCurrency(Amount)) from Opportunity

Custom Settings

• Custom settings allows to store custom sets of data in application cache for faster and frequent access.
• NOTE: querying Custom Settings does not count towards SOQL limit!
• Two types of Custom Settings:
  • List Custom Settings (unusable) - provide reusable static data that is same for all users across org (preferred Custom Metadata Type)
  • Hierarchy Custom Settings - use built-in hierarchical logic to personalize settings based on specific user profiles or users
    
• NOTE: Custom Settings can be included in a package, but the data will not. If needed, it must be done via Apex.
• Custom fields can be added in Custom Settings. Supported data types are checkbox, currency, date, date/time, email, number, percent, phone, text, textarea, and URL.
  
• Default value can be defined in organization level as well as by specific user or user's profile.
  
  
  
• Custom Settings can be used in formulas, validation rules, flows, Apex and SOAP API.
• Custom Settings have the same naming format as custom objects, as the API name ends in __c. For example, Custom Settings named Test Hierarchy will have API name of Test_Hierarchy__c.
• Custom Settings can be assessed via $Setup in formula or validations. Example: $Setup.Test_Hierarchy__c.Test_Text__c
  
• To use Custom Settings in Apex, simply type Test_Hierarchy__c.getInstance().Test_Text__c will do.
• To prevent values of Custom Settings to be modified in managed packages, the Privacy can be set to Protected.
• Use Custom Settings when:
  • data doesn't change frequently but needs to be referenced frequently
  • values of Custom Settings need to change based on logged-in user or user's profile.
  • page layout needs to change based on different profiles or users
  • specific value of setting will differ for every organization
  • common value is needed to use in formula or validations.
  • common currency value is needed.

Custom Metadata Types

• Custom Metadata Types are newer and preferred over Custom Settings which allows for both structure and actual record data to be included in a package.
  
  
• Unlike Custom Settings, Custom Metadata Types can create picklist, text area(long) and metadata relationships (another metadata type, entity definition, or field definition).
  
• NOTE: while creating custom picklist field, the "Use first value as default value" and "Restrict picklist to the values defined in the value set" are checked by default.
  
• Records can be created by clicking Manage button.
  
  
• Records can be referenced in formula fields.
  
• Sample Custom Metadata Types formula usage: $CustomMetadata.Custom_Test__mdt.Hello_World.Test_Picklist__c , $CustomMetadata.Custom_Test__mdt.Hello_World.MasterLabel
• Access Custom Metdata Types via SOQL:
  • SELECT Label, Test_Picklist__c FROM Custom_Test__mdt WHERE Test_Picklist__c = 'A'
• In managed packages, Custom Metadata Types can be protected at the Type, Record, and Field Level.
  • Public types can be used by all Apex code in an org.
  • Protected types can be used by package
  • Protected records can only be accessed by code in the same namespace as the record or its type
  • Combination of Public type and Protected record can be used to allow package subscribers to add their own values to a type, but not to modify the type structure.
  • Fields have 3 levels of editing privileges:
    • Upgradable - Only the package developer (via package upgrade)
    • Subscriber editable - Any user with Custom Application permission (package upgrades won't override the value)
    • Locked after release - No one
      
• Use Custom Metadata Types when:
  • data doesn't change frequently but needs to be referenced frequently
  • values of the settings are same for all users and profiles (can't be specifically defined)
  • values are tied to a package and are the same for any subscribing organization
  • A relationship, common picklist or long text area is needed for a package
  • Parameters for formulas used in formula fields can be stored
• Unlike custom settings, Custom Metadata Types are always accessible by all users.