Data Modeling and Management (5%) PDF

4/5/2020 Data Modeling and Management (5%) – focusonforce.
com
TAKE NOTES
Previous Lesson Next Lesson

Data Modeling and Management (5%)
Course Overview
Objectives of this section
Given a scenario, identify and justify where Apex managed sharing should be used.
Describe the use cases for and bene ts of external IDs.
Identify use cases for different types of custom metadata and custom settings, and describe how to
implement solutions for those use cases.
Given a scenario, identify and justify where Apex managed sharing should be used
After studying this topic, you should be able to:
Describe what Apex Managed Sharing is used for in Salesforce
Explain the role of share objects in Apex Managed Sharing
Describe how to set up Apex Managed Sharing for sharing records programmatically
Describe the considerations associated with Apex Managed Sharing and its recalculation
Identify the reasons and use cases associated with the use of Apex Managed Sharing
Introduction
Apex managed sharing is one of three sharing capabilities in Salesforce. Force.com sharing access is granted by the system based on
record ownership, role hierarchy, and sharing rules. User managed sharing allows the record owner or any user with Full Access to a
record to share the record with a user or group of users. In situations where neither Force.com or User-managed sharing is suitable,
Apex managed sharing can be used. Apex Managed Sharing allows you to use Apex code to build sophisticated and dynamic sharing
settings that aren’t otherwise possible.
Privacy - Terms
https://focusonforce.com/lessons/platform-dev-2-study-guide-data-modeling-and-management/ 1/23
4/5/2020 Data Modeling and Management (5%) – focusonforce.com
TAKE NOTES
Apex Managed Sharing Overview
Apex Managed Sharing allows developers to build sophisticated and dynamic sharing settings.
It is a type of programmatic sharing that allows de ning a custom sharing reason for the programmatic
share.
Custom sharing reasons can only be de ned for shares written to custom objects.
Objects with a default sharing setting of ‘Private’ or ‘Public Read Only’ also have a related ‘Share’ object.
A share object includes records supporting Force.com managed sharing, user managed sharing, and Apex managed sharing.
Share Objects
A Share Object only exists for an object if the Organization-Wide Default is Read Only or Private. If the object
access policy is Public Read/Write, no other sharing policy is necessary.
Share Objects for standard objects append ‘Share’ to the object name. For example, the Share Object for
Account would be AccountShare.
Share Objects for custom objects append ‘__Share’ to the object name. For example, the Share Object for
MyCustomObject would be MyCustomObject__Share.
Although Share Objects can exist for both standard and custom object, Apex sharing reasons and Apex managed sharing
recalculation are only available for custom objects.
Share Table
Setting Up Apex Managed Sharing
To use Apex managed sharing, a Sharing Reason must rst be de ned for the custom object. Apex code can then
be written to add or remove entries to the Share Object to grant users access to a record when speci c conditions are met.
Apex Sharing Reason can be created by navigating to the ‘Apex Sharing Reasons’ related list of an object.
Each Apex sharing reason has a label and a name. Label is displayed in the user interface while viewing the sharing for
a record, and the name is used when referencing the reason in the API and Apex.
While creating Apex code for sharing a record, the following elds must be de ned for a custom object’s share
object:
ParentId corresponds to the record being shared.
UserOrGroupId is the ID of the user or public group to whom access is being granted.
AccessLevel can be either ‘Read’ or ‘Edit’.
RowCause is used for specifying the reason why the user or group is being granted access.
Either a custom or ‘Manual’ RowCause can be used in Apex code to create records in share tables.
A ‘Manual’ RowCause is used to treat the share record as if it was created by User managed sharing.
Apex Managed Sharing Settings
Privacy - Terms
TAKE NOTES
Reason Creation
Apex Managed Sharing Recalculation
Apex managed sharing rules are automatically recalculated whenever a custom object's organization-wide
sharing default access level is updated.

During automatic recalculation, custom recalculation classes are executed.
Sharing rule recalculation can be manually invoked from the custom object’s setup area.
To enable manual recalculation, an Apex class that implements the Database.Batchable interface must be
written.
To associate an Apex managed sharing recalculation class with a custom object, go to the object’s Apex Sharing
Recalculations section and choose the recalculation class.
Key Considerations
When multiple entries in the share object apply for the logged-in user, the most-permissive rule applies. For
example, if a user has Read access to the record by way of Force.com or Manual sharing rules, and a managed rule grants
Read/Write access, the Read/Write access will apply.
Apex managed sharing is maintained across record owner changes.
Only users with ‘Modify All Data’ permission can add, edit or delete apex managed sharing records.
A record can be shared multiple times with a user or group Apex sharing reasons.
using different
Reasons for Using Apex Managed Sharing
Use Apex managed sharing when:
Standard sharing functionality is not suf cient.

Sharing rules depend on a combination of values across multiple objects.
Sharing access is criteria-based but the evaluated eld isn’t supported by declarative sharing.
Sharing logic is too complex to be established declaratively.
All attempts to share declaratively have failed.

Privacy - Terms
A M d Sh i U C
Apex Managed Sharing Use Cases
TAKE NOTES
SCENARIO DYNAMIC APEX SOLUTION
Once a Job record is created by a Recruiter, it needs to be shared In this case, an ‘after insert’ trigger can be created to share a newly
automatically with a Hiring Manager based on the value in a lookup created Job record with its associated Hiring Manager
eld on the Job record. automatically. A Share record for the Job record would need to be
created with ParentId, UserOrGroupId, AccessLevel, and
RowCause. The RowCause can be speci ed by navigating to ‘Apex
Sharing Reasons’ related list of the Job custom object.
Account records in an organization need to be shared based on Apex Managed Sharing allows using Apex code to share standard
values of certain custom elds on a custom object called Employee. object records programmatically. If the sharing logic is too complex
and/or involves other objects, Apex code can be de ned to create
and insert share records for the standard object records. In this
scenario, the share object for Account would be AccountShare.
An organization needs to grant access to users to the Warehouse Apex Sharing Reasons can be de ned for a custom object from the
custom object based on different criteria. The reason for granting ‘Apex Sharing Reasons’ related list. It can be used while creating
access needs to be visible in the user interface. Apex code to provide access to custom object records
programmatically. A reason can be speci ed while assigning the
value of the RowCause of the share record. The reason can be
accessed using
Schema.CustomObjectName__Share.RowCause.SharingReason__c.
When a lead is converted into an opportunity, the opportunity needs The opportunity records created from the leads can be shared
to be shared with the lead owner. programmatically with the lead owner using Apex code. However,
the RowCause would need to be ‘Manual’ since custom sharing
reasons are only supported by custom objects.
Learn More
Using Apex Managed Sharing to Create Custom Record Sharing Logic

Sharing a Record Using Apex
Just-In-Time Sharing Slide Deck from DeveloperForce
Understanding Sharing
Recalculating Apex Managed Sharing
Describe the use cases for and bene ts of external IDs
Introduction
External IDs are primarily used to import data from external systems and for integrating external system data into Salesforce.
They allow Salesforce developers and admins to maintain data relationships between internal and external objects. Any custom
text, number or email eld marked as External ID automatically becomes sidebar-searchable. External lookup and indirect lookup
relationships use external IDs for matching records.
Integrating External System Data into Salesforce
Privacy - Terms
TAKE NOTES
Use Cases for External ID Fields
Data can be imported into Salesforce, either from another Salesforce org or from an external source. The external ID
becomes especially important when importing data related through any sort of parent-child relationship.
Insertion of Parent Record
Privacy - Terms
TAKE NOTES
Upsert of Child Record
Privacy - Terms
TAKE NOTES
Privacy - Terms
TAKE NOTES
Data can be integrated from external systems without actually copying it into Salesforce. The integration can
happen through tools such as Salesforce Connect or Heroku Connect.
It is possible to make elds searchable in the sidebar that would not otherwise be searchable. By default, only Name
and Custom AutoNumber elds are sidebar-searchable. Marking any text, number or email eld as an External ID
makes the eld sidebar-searchable.
Sidebar-Searchable Field
Bene ts of Using External ID Fields
Using External ID Fields preserves a reference back to the source record system.
It allows for the creation of parent-child relationships between data existing in 2 different systems.
Duplicates are prevented when importing data.

External ID elds are indexed, so searches on these elds run faster.
Set as External ID
Privacy - Terms
External IDs and External Object Relationships
External lookup and indirect lookup relationships use the External ID parent eld for matching records. TAKE NOTES
An external lookup relationship can be used when the parent is an external object.
An indirect lookup relationship can be used when the parent is a standard or custom object and the external data doesn't
include Salesforce record IDs.
External Lookup Relationships
An external lookup relationship eld links a child standard, custom, or external object to a parent external object.
The standard External ID eld on the parent external object is matched against the values of the external
lookup relationship eld.
Example of an External Lookup Relationship
Indirect Lookup Relationships
An indirect lookup relationship eld links a child external object to a parent standard or custom object.
A custom unique, external ID eld on the parent object is selected to match against the child’s indirect lookup
relationship eld.
The values of the indirect lookup relationship eld are determined by the External Column Name.
Example of an Indirect Lookup Relationship
Privacy - Terms
TAKE NOTES
External Column Name
Learn More
Maximum Number of External IDs Per Object or Entity

Make Any Field Searchable Through Basic Sidebar Search
Searchable Objects and Fields
Import Related RecordsUsing External IDs
Identify use cases for different types of custom metadata and custom settings, and describe how to
implement solutions for those use cases
Introduction
Custom settings and custom metadata types are used to store values which don’t change frequently but need to be frequently
referenced in Salesforce. The data from custom settings and custom metadata types is pulled into the application cache which
allows for ef cient access of the data and, in most cases, does not count toward SOQL limit. Both approaches support many
different data types. Referencing custom settings and custom metadata types in business logic makes customizations easier to
maintain and read, and reduces the number of places where changes need to be made. Custom metadata types are a newer
concept and are preferred over custom settings in many cases. However, there are scenarios in which custom settings are
still the preferred approach.
Privacy - Terms
TAKE NOTES
Custom Settings Overview
Custom settings allow creation of custom sets of data which can be exposed in application cache.
These settings can be used by formula elds, validation rules, ows, Apex, and the SOAP API.
There are two types of custom settings:
List Custom Settings - Provides reusable static data that is the same for all users across the organization
*Note: for situations where this type of custom setting has been used in the past, Custom metadata types are now
the preferred approach.
Hierarchy Custom Settings - Uses built-in hierarchical logic to personalize settings based on speci c user
pro les or users
Custom settings can be included in packages, but the data will not be included. To include data, Apex code will
need to be used.
To protect the value of Custom Settings in managed packages, set Privacy to Protected. This will prevent the target
org from editing the values or accessing them in Apex.
Custom settings can be used for quick and ef cient access to cached custom data without using SOQL queries that
count against the governor limits.
Use Cases of Custom Settings
Custom settings can be used when there is data that doesn’t change frequently but needs to be referenced
frequently.
The value of the setting needs to change based on the logged-in user or the user’s pro le.
A page layout needs to change based on different pro les or users.
The speci c value of the setting will differ for every organization.
A common value is needed to use in formula or validation elds.
A common currency value is needed.
Examples of Custom Settings
A list custom setting can be created to store a list of countries and their ISO country codes that can be used
across the organization.
A hierarchy custom setting can be used to store different incentives and bonus plans for different user pro les
for a compensation application.
A list custom setting can be created for storing domain names through which an organization receives incoming
emails.
A hierarchy custom setting can be created for different discount percentages that can be offered by different sales
users in the organization.
Using Custom Settings
Create custom settings by navigating to ‘Custom Settings’ in Setup.
The manage button can be used to add, edit or delete values.
Custom settings have the same naming format as custom objects; the API name ends in __c.
For example, a Custom Setting named Country Codes would, by default, be named Country_Codes__c.
To access custom settings, pre x the API name with $Setup in validations or formulas (for example:
$Setup.Run_Validation_Rules__c).
To use in Apex, custom settings can be accessed the same way as a normal Salesforce object is accessed. Then
methods speci c to the type of custom setting (list or hierarchy) can be used.
Custom Settings Setup
Privacy - Terms
TAKE NOTES
Editing the Value
Adding an Error Condition Formula
Privacy - Terms
TAKE NOTES
Adding an Error Condition Formula
Custom Settings Code
Custom Metadata Types Overview
Custom metadata types allow for both the structure and the actual record data to be included in a package.
Similar to a custom setting, a custom metadata type consists of custom elds that represent different aspects
of the metadata.
Unlike custom settings, custom metadata types allow for creating relationships between related types.
Records of a custom metadata type can be referenced in an advanced formula eld.
Custom metadata types can be migrated by using change sets.
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 only be accessed by the package.
Privacy - Terms
Protected records can only be accessed by code in the same namespace as the record or its type.
A combination of Public type and Protected record can be used to allow package subscribers to add TAKE NOTES
their own values to a type, but not to modify the type structure.
Fields have 3 levels of editing privileges:

Package developer can edit the eld via package upgrade.
Any user with Customize Application permission can edit. Package upgrades won’t override
the value in this case.
No one can edit; not even the package developer.
Use Cases of Custom Metadata Types
There is data that doesn’t change frequently but needs to be referenced frequently.
The value of the setting is the same for all users and pro les.
The values are tied to a package and are the same for any subscribing organization.
A common picklist or long text area is needed for a package.
Con guration data is linked by relationships.
Business rules require to be stored.

Mappings between con guration data need to be stored.
Parameters for formulas used in formula elds can be stored in custom metadata types.
Default Field Values that are uniform to multiple elds can be set so that there will be no need to con gure each eld
when a change of default value is required.
Examples of Custom Metadata Types
A list of ISO country codes can be created using a custom metadata type. Then the list can be migrated easily to
another environment, such as Production using a change set.

A custom metadata type can be created for employee bonus, and it can be related to another custom metadata
type for salary plans using a metadata relationship eld.

A custom metadata type can be created to store information about products such as machines. Records of the metadata
type can be used in formula elds to perform calculations based on the information.
Using a Custom Metadata Type to Store Information
Referencing a Custom Metadata Type Record
Privacy - Terms
TAKE NOTES
Using Custom Metadata Type Record in Formula Field
Using Custom Metadata Type Record in Field Default Values
Using Custom Metadata Types
Custom metadata types can be created by navigating to ‘Custom Metadata Types’ in Setup.
The data type has to be selected, the elds are added, and then the data can be added.
Data can be created manually or loaded via the custom metadata loader.
Custom metadata types append “__mdt” to the API name instead of “__c”. For example, a metadata type named
Country Codes would, by default, be named Country_Codes__mdt.
Unlike custom settings, custom metadata types are always accessible by all users.
Visibility Options
Privacy - Terms
TAKE NOTES
Field Manageability Options
Custom Metadata Types Setup
Privacy - Terms
TAKE NOTES
Managing Button
Custom Metadata Types Code
Field Types Supported by Both

Checkbox
Date
Percent
Date/Time
Phone
Text
Email
Text Area
Number
Privacy - Terms
URL
TAKE NOTES
Differences Between Custom Settings and Custom Metadata Types
FEATURE CUSTOM SETTINGS CUSTOM METADATA TYPES

Con guration deployable
Con gurable data deployable X

Visible in test classes X
Create/update in bulk custom metadata loader X
Supports relationships X
Can use picklist as a eld type (except global) X
Can use long text area as a eld type X
Can use currency as a eld type X
Exempt from SOQL limits
Supports hierarchy con guration X

Create, read, update and delete values via Apex **
Accessible by formula elds (hierarchy)
** except delete
Custom Metadata Types: Save Years of Developme…

Developme…
Use Cust…
Cust…
Privacy - Terms
Learn More TAKE NOTES
Custom Metadata Types

Custom Metadata Types (CustomObject)
Trailhead: Use Platform Features for Secret Protection
Custom Settings
Custom Settings Methods
Custom Setting List vs. Hierarchy
Create Custom Data Sets
Access Custom Settings
Difference Between Custom Settings and Custom Metadata
How to Use Custom Metadata Types to Save Years of Development on App Con gurations
Custom Metadata Loader Source Code from Salesforce’s GitHub
Custom Metadata Types Implementation Guide
Testing Custom Metadata Types
Platform on the Platform
Custom Metadata Types and Advanced Formula Fields
Review
What should be avoided in formulas

when designing in a multi-language
environment?
Which standard compound type can

be used in a custom eld de nition?
How does designating a eld as an

External ID affect search capability on
the object?
What data type do custom settings

support that custom metadata types
don’t?
Privacy - Terms
ustom settings.
What can be used in a formula eld to
TAKE NOTES
reference metadata information
stored as parameters?
What eld in the Share Object

references the API name of an Apex
Sharing Reason?
How does an External ID help with

data import?
Which type of custom setting doesn’t

have an equivalent custom metadata
type?
What is different between how

custom settings and custom metadata
types are deployed?
What needs to be de ned before

creating Apex code to share a custom
object record programmatically?
In what situation would a Share

Object NOT exist?
Privacy - Terms
TAKE NOTES
COMMENTS
Emma Rosenfeld
Good evening. There are a few questions in the review section referencing Geolocation, addresses, and compound data types, but no
mention of any of that material in the study guide in this lesson. Are those questions mismatched/outdated, or is the section missing?
5 months ago
Ian
Hi Emma, thank you for the feedback. We are currently looking into this.
5 months ago
Demo Kai
Still missing
3 months ago
Ian
Hi Demo, thanks for pointing this out. The review questions belong to old objectives that have already been
removed. They are currently in queue for deletion.
3 months ago
Jeronimo
The confusing bit with Apex Managed Sharing is, that while record owner changes happen on Standard Object the Apex Managed
Shares are removed (because there’s no custom Apex Share cause). For Custom object, the Apex managed sharing persists.
6 months ago
Ian
Hi Jeroen, for custom objects (Apex Managed Sharing), the shares are maintained across record owner changes. For
Managed Sharing (Manual shares), the shares are removed during record owner changes.
6 months ago
Yishuo LYU
Hi, Martin,
I’m not sure if it’s an error or an ambiguity.
For the last row in the last table, Custom MetaData Types should be accessible by formula elds.
Thanks,
Yishuo
1 year ago
Privacy - Terms
Sara S.
TAKE NOTES
Hi Yishuo, thank you for your feedback. We have updated the page.
1 year ago
Shaunmsu
The message on the Geolocation Error screenshot is incorrect. It says “Placing the Geolocation eld before the GEOLOCATION
function causes an error”. Think it should be “Placing the Geolocation eld after the GEOLOCATION function causes an error”.
1 year ago
Sara S.
Hi Shaunmsu, thank you for your feedback. We have updated the page.
1 year ago
Manny Singh
Hi Martin,
There is a spelling mistake under Multicurrency section for the format function. Instead of format it is written formal
Thanks
Manpreet Singh
1 year ago
Sara S.
Hi Manpreet, thank you for your feedback. We have updated the page.
1 year ago
Vijaya Kumar Venkatramanan

Ah. Sorry my bad. I only saw this link – https://developer.salesforce.com/docs/atlas.en-
us.soql_sosl.meta/soql_sosl/sforce_api_calls_sosl_querying_currency_ elds.htm
1 year ago
Vijaya Kumar Venkatramanan

Hi Martin,
convertCurrency() is a SOSL query. In screen shot it is mentioned as SOQL.
Thanks
Vijay
1 year ago
Sara S.
Hi Vijay, convertCurrency() is a function available for SOQL.
Reference: https://developer.salesforce.com/docs/atlas.en-
us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_querying_currency_ elds.htm
1 year ago
Your Comment...
Privacy - Terms
Comment
TAKE NOTES
Copyright 2020 - www.focusonforce.com
About Blog Contact Us Disclaimer Privacy Policy Terms of Use View as Mobile
Privacy - Terms

Data Modeling and Management (5%) PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Data Modeling and Management (5%) PDF

Uploaded by

Copyright:

Available Formats

4/5/2020 Data Modeling and Management (5%) – focusonforce.

Previous Lesson Next Lesson

Objectives of this section

Describe the use cases for and bene ts of external IDs.

After studying this topic, you should be able to:

Describe what Apex Managed Sharing is used for in Salesforce

Explain the role of share objects in Apex Managed Sharing

Apex Managed Sharing Overview

access policy is Public Read/Write, no other sharing policy is necessary.

Setting Up Apex Managed Sharing

Apex Managed Sharing Settings

Apex Managed Sharing Recalculation

sharing default access level is updated.

Recalculations section and choose the recalculation class.

Reasons for Using Apex Managed Sharing

Use Apex managed sharing when:

Standard sharing functionality is not suf cient.

All attempts to share declaratively have failed.

SCENARIO DYNAMIC APEX SOLUTION

Using Apex Managed Sharing to Create Custom Record Sharing Logic

Describe the use cases for and bene ts of external IDs

Integrating External System Data into Salesforce

Use Cases for External ID Fields

Insertion of Parent Record

Insertion of Parent Record

Insertion of Parent Record

Upsert of Child Record

Upsert of Child Record

Upsert of Child Record

Upsert of Child Record

Bene ts of Using External ID Fields

Duplicates are prevented when importing data.

include Salesforce record IDs.

External Lookup Relationships

lookup relationship eld.

Example of an External Lookup Relationship

Indirect Lookup Relationships

Example of an Indirect Lookup Relationship

External Column Name

Maximum Number of External IDs Per Object or Entity

Custom Settings Overview

the preferred approach.

Use Cases of Custom Settings

A common value is needed to use in formula or validation elds.

A common currency value is needed.

Examples of Custom Settings

Using Custom Settings

Create custom settings by navigating to ‘Custom Settings’ in Setup.

The manage button can be used to add, edit or delete values.

Custom Settings Setup

Editing the Value

Adding an Error Condition Formula

Adding an Error Condition Formula

Custom Settings Code

Custom Metadata Types Overview

Public types can be used by all Apex code in an org.

Fields have 3 levels of editing privileges:

No one can edit; not even the package developer.

Use Cases of Custom Metadata Types

A common picklist or long text area is needed for a package.

Con guration data is linked by relationships.

Business rules require to be stored.

Examples of Custom Metadata Types