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.
    translation-workbench-settings
  • You can select the Language and then select Setup Component that you would like to translate.
    translation-workbench-setup-component-selection
    translation-workbench-translate-manually
  • You can also create Custom Label and set the translation to display user friendly text.
    create-custom-label
    translate-custom-label
    custom-label-translation
  • 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
      create-custom-settings
  • 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.
    custom-settings-page
  • Default value can be defined in organization level as well as by specific user or user's profile.
    custom-settings-default
    custom-settings-profile
    custom-settings-hierarchy
  • 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
    custom-settings-use-in-validation
  • 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.
    create-custom-metadata-types
    custom-metadata-types-page
  • Unlike Custom Settings, Custom Metadata Types can create picklist, text area(long) and metadata relationships (another metadata type, entity definition, or field definition).
    custom-metadata-types-custom-fields
  • 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.
    custom-metadata-types-picklist
  • Records can be created by clicking Manage button.
    custom-metadata-types-manage-records
    create-custom-metadata-types-records
  • Records can be referenced in formula fields.
    custom-metadata-types-reference
  • 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
        custom-metadata-types-field-manageability
  • 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.
FeatureCustom SettingsCustom Metadata Types
Deploy configuration
Deploy configurable data
Test classes visibility
Create/update in bulk custom metadata loader
Relationship type
Picklist field type
Long text area field type
Currency field type
Exempt SOQL limits
Support hierarchy configuration
CRUD via Apex✅ (no delete)
Accessible by formula fields (hierarchy)

Post was published on , last updated on .

Like the content? Support the author by paypal.me!