Salesforce Admin Manual

Index
Index............................................................................................................................................. 1
Objects Information............................................................................................................... 3
Big Objects..................................................................................................................................... 3
Standard Objects...........................................................................................................................5
Custom Objects............................................................................................................................. 6
External Objects............................................................................................................................ 8
Tab Information...................................................................................................................... 9
Application Information.......................................................................................................11
Fields and Relationships.......................................................................................................12
List Views............................................................................................................................... 18
Layouts In Salesforce............................................................................................................21
Page Layouts in Salesforce........................................................................................................ 21
Mini page Layouts.......................................................................................................................25
Compact Page Layout.................................................................................................................26
Search Layout.............................................................................................................................. 27
Record Types..........................................................................................................................28
Business Processes in Salesforce............................................................................................. 30
Rules in salesforce................................................................................................................ 31
Assignment Rules........................................................................................................................32
Duplicate Rules............................................................................................................................34
Matching Rule Creation..............................................................................................................36
Auto Response Rules..................................................................................................................37
Escalation Rules...........................................................................................................................38
Workflow Rules............................................................................................................................39
Validation Rules...........................................................................................................................42
Process Builder...................................................................................................................... 50
Approval Process...................................................................................................................62
Security Model.......................................................................................................................66
Profiles in Salesforce.................................................................................................................. 67
Users in the Salesforce...............................................................................................................69
Public Groups in Salesforce.......................................................................................................75
Org Level Security....................................................................................................................... 76
Object Level Security.................................................................................................................. 78
Field Level Security..................................................................................................................... 80
Record Level Security................................................................................................................. 82
Security Model Questions..........................................................................................................89
 2

Reports and Dashboards...................................................................................................... 97

Global Quick Actions...........................................................................................................100
Object Specific Actions....................................................................................................... 102
Scenario Based Questions..................................................................................................103
 3

Objects Information
Every database has a job to store the data, and that data should be in the organized form.
Salesforce also has an organized database that stores the data in tabular form. It has rows and
columns, that table is called an “Object” in salesforce.
There are 4 types of objects in salesforce:
●​ Standard Object
●​ Custom Object
●​ Big Object
●​ External Object

Big Objects
●​ Triggers, Flows, Processes and the Salesforce App are unavailable for Big Objects.
●​ It only supports Object and Field permission.
●​ Big Objects supports custom salesforce Lightning and Visualforce components rather
than standard UI.
●​ Example of Standard Big Object: FieldHistoryArchive, it stores data as a part of the field
Audit Trail.
●​ Standard big objects are available out of the box and cannot be customized.
●​ Custom Big Objects: It can save up to 1 Billion records.
●​ We can not create Reports and Dashboards directly on the Big Object because of the
large amount of data.
●​ To create the report we need to create a Custom Object and transfer the data in the
custom object and then create a custom report type on it, in that way we can create a
report on a subset of data of Big Object.
●​ We can not create Tab for Big Object while creating the object and after creation.
●​ Initially it is only visible for System Admin.
●​ API Name of the Big Object is having __b as extension.
●​ There are no standard fields are present for Big Object
●​ The creation setup of the Custom big Object can be completed only after creating at least
one required custom field.
●​ Big Objects can not be at the child side of the M-D Relationship.
●​ We can do field indexing in Big Object, only required fields we can use as index fields.
(Limit 5)
●​ The index defines the composite primary key for a custom big object and is used for
querying and filtering the big object data.
 4

●​ These objects can be included in managed packages.

●​ We cannot track field history on big objects.
How to Create Big Objects
Setup => Quick Find Box => Click on New

Information while creating Big Objects

●​ Label
●​ Plural Label
●​ Description
●​ Deployment Status (In Development) only

Data types available for creating custom fields

●​ Date / Time
●​ Email
●​ Number
●​ Phone
●​ Text
●​ Text Area Long
●​ URL
●​ Lookup
 5

Standard Objects
These are the objects which already exist in the Salesforce platform to manage the
configurations and settings of the environment. Once you log in to the salesforce platform, you
can see the available objects.

List of Main Standard Objects

●​ Account objects: companies or individuals that are involved in a business relationship.
These can be partners, customers, or competitors.
●​ Accounts Contacts: individuals within the accounts define the contact object
●​ Opportunity: an event or activity for revenue generation
●​ Case: a problem that a customer may have brought up
●​ Solution: the description of issues and how to solve them
●​ Forecast: the estimated quarterly revenue of the organization
●​ Document: documents that are stored in folders and used by the company
●​ Folders: store information documents and control access
●​ Report: it is the analysis of all the data that are stored in custom or standard objects
●​ Dashboard: a visual representation of data or groups of charts generated from the reports
●​ Activity: it includes calendar events and tasks
●​ Products: they refer to items that are sold to customers
●​ Orders: new to the spring ‘14 release, they are records of a customer’s purchase of
products or services
●​ Campaign: marketing projects
●​ Lead: the companies that are interested in your product or service

Considerations
●​ We can not create Standard Objects.
●​ Standard objects already having some custom fields.
●​ We can change the Tab name of the Standard Object from “Rename Tabs and Labels”
option.
●​ Standard objects can not be at the child side of the Master Detail relationship.
●​ Standard objects API name does not contain __c.
●​ We can not delete Standard objects.
●​ There is a Cascade Relationship between Account & Contact.
●​ We can not create Tab for Standard object.
●​ We can not delete Tab of Standard Object.
 6

Custom Objects
How to Create Custom Object
Setup => Object Manager => Create Custom Object

Things to Remember while Creating Custom Object

●​ Label - The actual name of the Custom Object
●​ Plural Label - Name of the Tab of Custom Object
●​ Object Name - API Name of the Custom Object (Spaces are replaced by ‘_’) (Special
symbols and special characters are not allowed)
●​ Description - Formal information regarding the object
●​ Context Sensitive Help Setting - This refers to the Help Page
●​ Record Name - Name of the Standard field which we can create along with object (Its API
name is always be the ‘Name’)
●​ Data Type - Text or Auto Number
●​ Optional Features
○​ Allow Reports - Whether we can create reports or not
○​ Allow activities - Whether we can create Task or Not
○​ Track Field History - Whether we can track history of fields
○​ Allow in Chatter Groups - Whether we can track object records in chatter

●​ Deployment Status
○​ In Development - If selected then object can only visible to System Administrator
○​ Deployed - If selected then states that the object is now ready for use and then
can be visible to non admin profile users if having permission.

●​ Search Status - Allow Search - If selected then object records are visible after searching
them
●​ Add Notes and Attachments related list to default page layout - This adds Notes and
Attachment related list to default page layout.
●​ Launch New Custom Tab Wizard after saving this custom object - This redirects to Tab
creation for object after clicking on save.
 7

Considerations for Custom Object

●​ We can delete custom object.
●​ We can create custom object.
●​ We can create Tab for Custom Object.
●​ We can change the name of the tab.
●​ Only 1 tab at a time.
●​ API Name contains __c.
●​ Custom objects are having Name, CreatedBy, ModifiedBy, Owner, CreatedBy ID standard
fields
●​ Custom objects do not have custom fields initially, we can create them.
●​ We can create 500 fields per custom object in Dev Edition and 800 in Unlimited edition.
●​ In Dev Edition we can create 400 Custom Objects & 2000 in Unlimited Edition + 1000
Objects by Installing from app Exchange.
●​ We can create Lookup as well as M-D Relationship on custom objects, it can be at master
or Child side.
 8

External Objects
External objects are similar to custom objects, except that they map to data that’s stored outside
your Salesforce org. Each external object relies on an external data source definition to connect
with the external system’s data. Each external object definition maps to a data table on the
external system. Each of the external object’s fields maps to a table column on the external
system. External objects enable your users and the Lightning Platform to search and interact with
the external data. (Each Org can have up to 200 external objects.)

Things to Remember while Creating Custom Object

●​ Label - The actual name of the Custom Object
●​ Plural Label - Name of the Tab of Custom Object
●​ Object Name - API Name of the Custom Object (Spaces are replaced by ‘_’) (Special
symbols and special characters are not allowed)
●​ Description - Formal information regarding the object
●​ Context Sensitive Help Setting - This refers to the Help Page
●​ Starts with vowel sound - If it’s appropriate for your org’s default language, select to
precede your label with “an” instead of “a” for any automated messages.
●​ Content Name - Select the Visualforce page that best describes the data that’s provided
by this external object.
●​ External Data Source - The external data source definition that contains the connection
details you want to use for this external object.
●​ Table Name - Table in the external system that the external object maps to.
●​ Display URL Reference Field - Available only for Salesforce Connect. The external object’s
Display URL standard field values are automatically generated from the external system.
●​ Allow Reports - Whether we can create reports or not
●​ Launch New Custom Tab Wizard after saving this external object - If selected, the custom
tab wizard starts after you save the external object.
 9

Tab Information
Tabs represent objects on the UI, by using tabs users can see and create records.
OR
Tabs are like a user interface that is used to build records for objects and to view the records in
the objects.

Types of Tabs
There are 5 Types of tabs.
●​ Custom Object Tab - Tabs for the Custom Object.
○​ Custom Object Tab can be created while creating the object and after creating the
object.
○​ For standard objects tabs are already created and we can not delete them.
○​ For custom objects we can create and delete the tabs.
○​ On dev org we can create max 100 tabs, on Unlimited Edition we can create 1225
tabs.
○​ For one object there can only be 1 tab.
○​ Once any object is having a tab we can not create another tab until and unless we
delete the old tab.

●​ Web Tab - Custom web tabs show any external web-based application or web page.
○​ Web tab can be full page or with sidebar.
○​ Web tab is just like a normal tab, when we click on that it redirects us to the web
page

●​ VisualForce Tab - Visualforce tabs show data from a Visualforce page. Visualforce tabs
look and function just like standard tabs.
○​ First we have to create a VF Page then we can select it while creating the tab.

●​ Lightning Component Tab - Lightning component tabs make Lightning components

available in the Salesforce mobile apps and in Lightning Experience. Lightning
components aren’t supported in Salesforce Classic.
 10

●​ Lightning Page Tab - Lightning page tabs let you add Lightning app pages to the
Salesforce mobile app and Lightning Experience navigation bars.
Visibility of Tabs
●​ Default On: If Default On is selected, the particular tab is displayed on the bar at the top,
where other tabs are.
●​ Default Off: If Default Off is selected, the user will have to click the ‘+’ icon on the bar at
the top, next to all the other tabs that are visible.
●​ Tab Hidden: If Tab Hidden is selected, then the tab will be hidden from the bar at the top
and the user won’t be able to access it even with the ‘+’ icon.
 11

Application Information
Apps in Salesforce are a window on which we can access a set of tabs each consisting of
different types of information and functionalities. It simply consists of a name, a logo, and an
ordered set of tabs. The simplest app contains only one tab i.e the home tab and a default logo.

Types
●​ Salesforce Standard App
●​ Salesforce Custom App

Salesforce Standard App

Apps are already present in every new instance of Salesforce by default. It includes App
Launcher, Call Center, Community, Content, Marketing, Sales, Salesforce Chatter, and Site.com.
These apps are a collection of items that include everything from the Classic apps list, plus
Lightning page tabs, and utilities like Sales Dialer. In Lightning apps, you can customize the app’s
logo and enhance its branding by customizing the color of the navigation bar.

Salesforce Custom App

When we need to group the tabs as per the need of the team then we create the custom app.
Custom apps have 2 styles, Standard Navigation and Custom Navigation.
Standard Navigation: By using this we can open records one by one in a new window even if
they are related to each other.
Console Navigation: Using this we can open related records as a sub tab.
 12

Fields and Relationships

In salesforce the main aim is to create records and gather the data, the data gathered in the form
of records. To create the records we need a proper informative data collection index. These are
called fields or In other ways we can define fields as columns in the table.
Every field is created to gather specific types of data, that is called data types.

Types of the fields

●​ Standard Fields
●​ Custom Fields

Standard Fields
Standard fields are those fields which are created by the salesforce. All standard objects have the
standard fields and when we create a custom Object then Name, CreatedBy, ModifiedBy, Owner,
CreatedBy ID standard fields get created.
●​ We can not create Standard Fields
●​ We can not delete standard fields
●​ Standard fields do not have __c in the API name.
●​ Big Objects do not have standard fields
●​ Standard objects already have many standard fields.

Custom Fields
Custom Fields are those fields which we create as per business needs. We can create custom
fields in Standard as well as Custom Object. We can create specific data type fields.
●​ We can create custom fields.
●​ We can delete custom fields.
●​ Custom fields have __c in API Name.
●​ We can refer to custom fields in Apex, VR and other processes.

Data Types
●​ Auto Number:
○​ Auto numbers are auto generated numbers
 13

○​ We can generate auto numbers for older records but only while creating the field.
By using option “Generate Auto Number for existing records”
○​ If we do not use this option, then auto numbers only generate for new records
created after field creation.
○​ Auto numbers are read only.
○​ If anyone deletes the record then its number will not be transferred to other
record.

●​ Checkbox
○​ Checkbox returns the TRUE or FALSE value in the backend.
○​ Checked means True, Unchecked means False.
○​ We can not make the checkbox Required.
○​ We can set the checkbox’s default value to True or False.

●​ Currency
○​ Currency has a max 18 char length.
○​ We can set decimals in currency.
○​ After adding value in field, value get append with currency symbol like 20$
○​ We can mark it as required.
○​ It only accepts numbers.

●​ Date
○​ We can make it required.
○​ Format: YYYY-MM-DD
○​ We can either enter the date manually or we can pick from the calendar.

●​ Date/Time
○​ We can make it required.
○​ Format: YYYY-MM-DD hh:mm:ss
○​ We can either enter the date manually or we can pick from the calendar.

●​ Email
○​ We can make it Required, Unique, External ID.
○​ It only accepts data which is in proper email format.
○​ It fires an error when we enter wrong data.
 14

●​ Number
○​ Number only accepts the number values.
○​ Max length 18 Char.
○​ It can have decimals.
○​ We can make it unique, external, Required.

●​ Lookup Relationship
○​ The lookup is a loosely coupled relationship, allowing you to connect one object
to another in a one-to-many fashion.
○​ One Object acts as Parent and One acts as child.
○​ We can delete the Parent Record and the child will be as it is.

●​ Master Detail Relationship

○​ The master-detail relationship is a strongly coupled relationship – meaning if the
parent is deleted, so are the child records.
○​ Master-detail also allows the parent record to control child record attributes, such
as sharing and visibility. The child record inherits whichever security setting you
choose for the parent record.
○​ There will be no Owner field on the child, the owner is always the parent record.

●​ Many to Many Relationship

 15

○​ Junction objects are required to create many to many relationships.

○​ In master detail only we need a junction object, for lookup it is not necessary to
have a junction object.
Considerations
●​ `Auto Number (Data Type Conversion)
○​ If we convert the auto number into Text then it will not create any problem.
○​ We can convert Text into Auto number without losing the data.
○​ If we convert Auto Number into any other data type except Text, then it will cause
data loss.
○​ Max length of Auto number is 30 char, so if we are converting Text which has more
than 30 char, then data will get trimmed.

●​ Formula (Data Type Conversion)

○​ Formula is the Read-Only by nature.
○​ We can not convert Formula to Other Data type.
○​ We can not convert other data types to formulas.

●​ Picklist (Data Type Conversion)

○​ If we convert picklist into checkbox then, on existing records, we can select which
value will appear as checked & which value as unchecked.
○​ Single Select picklist to Multi select picklist conversion does not cause any data
loss.
○​ Multi Select picklist to single select picklist conversion will cause data loss.

●​ Relationship (Data Type Conversion)

○​ We can only convert External lookup relationships into non relationship data type.
○​ When we convert Lookup to MD / MD to Lookup & if we have large amount of data
in Org, then the system display “Waiting Page”.
○​ If we have a Roll Up summary field on the parent, then we can not convert MD to
lookup on child objects.
○​ If we have lookup & on child object some lookups are blank on child then we can
not convert Lookup into MD.
○​ When we convert Lookup to MD, OWD will change for the child and be set to
“Controlled by Parent”.
○​ When we convert MD to Lookup, OWD for child will change from “Controlled by
Parent” to “Public Read/Write”.
○​ If we convert MD to Lookup or Vice Versa, then the records created using these
fields may become unusable.
 16

○​ To restore those unusable reports we need to restore the original data type.
○​ Error in Report: “This report no longer be edited or run. Your administrator has
disabled all reports for the custom object or its relationship has changed.
○​ If any dashboard that uses the report then that also be unusable with below error:
This report can not be used as source report for this component. If a summary or
matrix report, add one or more groupings in the report. If it is tabular report with a
row limit, specify the Dashboard setting in the report.

●​ Text Area Long (Data Type Conversion)

○​ If we convert Text Area Long to Email, Text, Phone, Text Area, URL then data gets
truncated to 255 char.

●​ Text Area Rich (Data Type Conversion)

○​ We can convert the Rich Text Area field to Text Area long only.
○​ Images in rich text area fields get deleted only after editing & saving the long text
area.
○​ After converting the markup options like Bold, Italic are hidden but the markup
text on record remains the same.

●​ Changes after Field Deletion

○​ If we have deleted any field and after deletion we have not edited any page layout
or report, then when we restore the field, it also restores the field on report and
page layout.
○​ If we have a unique field, when we delete and restore that field, the system will
remove unique on that field.
○​ If we have any required field, when we delete and restore that field, the system
will remove required on that field.
○​ If any field is included in the AppExchange package, and we delete that field then
the field will get removed from the package.
○​ If we have MD & we delete MD Field, then its data type will change to lookup.
○​ When we delete a field then it will get removed from field dependency.
○​ When we delete picklist values then that will get deleted from field dependency.
○​ When we delete the formula field then its formula may show the error, so we need
to check the formula after restore.
○​ Field history tracking also gets removed after field deletion.
 17

●​ The Purge Delete

○​ For a custom object, if we reach 75% of total field deletion capacity, then
salesforce shows purge delete button.
○​ Purge button will delete field & data permanently.
○​ If deletion takes more than 30 seconds then, SFDC will send an email.

●​ The Custom Address Field

○​ Setup => User Interface => Check, Use custom Add Field
○​ This way we can enable the custom address field.
○​ It will enable address data type for custom field creation.
○​ Once enabled we can not disable.
 18

List Views
In Salesforce we can create list views to filter out records based on any field that we have access
to. List views are used to quickly segment lists of records, they allow us to action multiple records
at the same time.
There are 2 Types of List Views:
●​ Standard List View
●​ Custom List View

Standard List Views

●​ Standard List Views are created by salesforce.
●​ Standard List Views are available in standard as well as custom objects.
●​ We can delete standard list views
●​ We can not create standard list views
●​ We can edit properties of standard list views.

Custom List Views

●​ Users with “Manage Public List View” can create the list views.
●​ We can create custom list views in standard as well as custom objects.
●​ We can create, delete or Edit custom list views.

Limitations of List Views

●​ List views on external objects are not searchable.
●​ Person Account records may be returned in list view results if they match filter criteria
however, searching list view results is not supported for Person Accounts. Example results
may be returned for Person Account results that do not match list view filter criteria.
●​ Results are limited to the items contained in the list view. So, since the list view only has
2,000 items (due to SOQL limits), the search will only find results in those 2,000 items and
does not find results in any other items beyond those.
●​ We can show up to 15 fields in list view.

How to Create
●​ Click on Gear Icon => New => Give Name & Visibility
 19

Visibility of List Views

●​ Only I can see this list view - Only the creator of the list view can see the list view.
●​ All users can see this list view - All users having Object access can see the list view.
●​ Share list view with groups of users - We can share list view with Public Group.

We can see the list views in 3 different ways

●​ Split View
●​ Kanban View
●​ Table View

How they See

●​ Split view

○​

●​ Table View

○​
 20

●​ Kanban View

○​
○​ In Kanban View we can do Summarised By and Group By

List View Charts

●​ We can create following charts in List view Page
○​ Vertical Bar Chart
○​ Horizontal Bar Chart
○​ Donut Chart

How to Add Button on List View

●​ Select Object on which we need to add a button.
●​ Edit the Object and go To “Button Links and Actions”.
●​ Click on New Button or Link.
●​ Give Name, Link and Select Display Type as List Button & Save it.
●​ Go to the list view button layout and add that button to the layout.

Note:
●​ Recently View is not a list view.
●​ We can apply filters to list views by 2 ways, by gear icon-Add list view filters or from the
Filter Icon on list view page.
 21

Layouts In Salesforce
●​ Page Layouts
●​ Mini Page Layouts
●​ Compact Layouts
●​ Search Layouts

Page Layouts in Salesforce

Page layouts control the layout and organization of buttons, fields, s-controls, Visualforce, custom
links, and related lists on object record pages. They also help determine which fields are visible,
read only, and required. Use page layouts to customize the content of record pages for your
users.

Page Layout Tips

●​ Use field-level security to restrict users’ access to fields; then use page layouts to
organize detail and edit pages within tabs. This reduces the number of page layouts for
you to maintain. Field-level security settings override the visible and read-only settings on
the page layout if the field-level security has a more restrictive setting than the page
layout.
●​ Remove unnecessary fields.
●​ Keep the number of required fields to a minimum.
●​ Group similar fields with sections.
●​ Check your layouts in Read and Edit modes.
●​ Add help and description text to custom fields. Use it to explain to users what data you’re
looking for in the field.
●​ In Professional, Enterprise, Performance, Unlimited, and Developer Editions, use record
types to provide unique layouts for different records.
●​ If a dependent lookup is above its controlling field on a page layout, make its lookup filter
optional or redesign the page layout. Placing a required dependent lookup above its
controlling field on a page layout could confuse users who typically start from the top of
the page when entering data.
●​ A background process periodically runs that cleans up metadata associated with deleted
custom fields. This process will affect the Last Modified Date and Last Modified By fields
on page layouts, record types, and custom objects.
●​ Salesforce recommends creating no more than 200 page layouts. Although there is no
limit, it can be difficult to manage your page layouts if you have more than 200.
 22

Page Layout Creation

Select Object => Edit Object => Page Layout => New Page Layout

Page Layout Considerations

●​ Layout changes made by administrators for record pages don't appear immediately in
Lightning Experience. The record page displays the updated layout about 15 minutes later
when you reload the page.
●​ To see your changes immediately, log out and log back in. Other users don't see the
change until up to one hour later when they reload the page. This behavior applies to
record pages for these objects.
○​ Account
○​ Case
○​ Contact
○​ Lead
○​ Opportunity
○​ Custom objects
●​ This behavior also applies to record layouts updated through the page layout editor,
compact layouts, and Lightning pages. For example, the layout is changed when you add
a custom field to an object and add that field to the page layout.
●​ For Personal, Contact Manager, Essentials, and Group Edition orgs, every user views the
same layout. Professional, Enterprise, Unlimited, Performance, and Developer Edition orgs
can create different page layouts for use by different profiles and record types and set
field-level security settings to further restrict users’ access to specific fields.
●​ In Professional, Enterprise, Performance, Unlimited, and Developer Editions, you can set
the mini page layouts and related objects that appear in the Console tab.
●​ Removing a field from a page layout doesn’t remove it from the object’s compact layout.
The two layout types are independent.
●​ Changes to user layouts override the global publisher layout on user profile pages and
the Chatter home page.

Page Layout Assignments

●​ Select Object => Edit Object => Page Layout =>
●​ We can assign page layout to Records Types & Profiles.
●​ By using page layout assignments we can assign diff page layouts for diff record types.
 23

Limitations of Page Layouts

●​ If you’re using Salesforce Professional Edition, you can’t rename a page layout.
●​ You can drag up to 20 s-controls, 20 Visualforce pages, 20 expanded lookups, and 100
related lists onto a page layout. There are no limits on custom links.
●​ In Lightning Experience, page layouts support up to 55 lookup fields. In Salesforce
Classic, page layouts support up to 40 lookup fields.
●​ Don’t add more than four external lookup fields to your page layout. On Lightning
Experience record pages, a Record Detail component that contains more than four
external lookup fields breaks the page at runtime.
●​ You can add one dashboard per page layout.
●​ Page layouts for the user object only include custom fields, custom links, s-controls, and
Visualforce pages. Tagging, related lists, custom buttons, and standard field
customizations aren’t included on page layouts for the user object. Also, field-level
security is only available for custom fields on the user object. Only standard Chatter
actions appear on the user profile page, regardless of which actions are assigned to the
User Page Layout or the global publisher layout.
●​ A page layout can have up to 100 related lists.
●​ The View All button only displays up to 2,000 items in a related list.
●​ You can’t add related lists to the page layouts for the User object.
●​ You can include up to 10 fields per related list.
●​ In Lightning Experience, the related list type determines how many fields are displayed in
a related list. The Basic List related list type displays only the first four fields of a related
list. The Enhanced List type shows up to 10 fields, lets you resize and sort columns,
perform mass actions, and wrap text. To change the related list type, customize the
Related List–Single component or the Related Lists component in the Lightning App
Builder.
●​ Users can’t drag documents to add them to Files or Notes & Attachments related lists
when the related list type is Basic List.
●​ You can’t move the first field of a related list, because it’s a unique identifier for the record.
●​ You can add custom fields of the long text area type to a related list. However, you can’t
add some standard fields of the long text area type. For example, you can’t add the
Description field on an Opportunity to a related list.
●​ The default sort order varies per record. The Sort By dropdown isn’t available for activities
and opportunity products.
●​ Lookup fields aren’t available for display on their corresponding lookup related list. For
example, the case lookup field on an account page layout isn’t available when editing the
cases related list.
●​ You can’t customize the History related list because it links to data stored elsewhere.
 24

Symbols on Page Layout

●​ Star mark shows that this is required field
●​ Blue Dot shows that this Field should be always on Page layout. (We can not remove it)
●​ Greenbox-Arrow shows that it is a controlling field.
●​ Arrow-Redbox shows that it is a dependent field.
●​ Locks show that the field is Read-Only.

Things we can do with Page Layouts

●​ We can make fields required on page layout.
●​ We can make the field read only on page layout.
●​ We can remove fields from page layout.
●​ We can add a field to page layout.
●​ We can add related lists to page layout.
●​ We can remove related lists from page layout.
●​ We can add custom links to page layout.
●​ We can add / remove buttons on page layout.
 25

Mini page Layouts

Mini Page Layout is a layout defined from the existing “Page layout”. It is a subset of units existing
in page layout. It is defined to show hover details when you mouse over a field on an object’s
detail page or in the Recent Item section of the sidebar. Importance of mini page layout is to show
you the minimum required information to get the idea of a record without going to the records
detail page.

How to Create Mini Page Layout in Salesforce

Select Object => Edit Object => Page Layout => Edit Page Layout => Mini Page Layout

Note: Mini Layout is only visible only in Salesforce Classic.

Mini Page Layout Consideration

●​ You can set the mini page layouts and related objects that appear in the Console tab.
●​ Field properties on the page layout determine field properties on the mini page layout.
For example, if a field is read-only on the page layout, that same field is read-only on the
mini page layout. To change the field properties of fields on the mini page layout, you
must change the field properties of fields on the page layout.
●​ Overrides for the Edit and View buttons for an object don’t affect the Edit and View
buttons in mini page layouts.
●​ Fields marked Always Displayed or Always on Layout on page layouts are automatically
included on the mini page layout and can’t be removed unless they’re removed from the
page layout.
●​ You can’t choose Mini Console View for the Close Case layout, Log a Case page, or View
Cases page layouts on the Self-Service Portal. You can’t choose Mini Console View for
opportunity team page layouts.
●​ You can’t define mini page layouts for the Close Case layout, Log a Case page, or View
Cases page layouts on the Self-Service Portal. You can’t define mini page layouts for
opportunity team page layouts.
●​ You can define mini page layouts for the user object; however, you can’t add standard
fields or related lists. Also, a customized mini page layout won’t display in the Agent
console.
 26

Compact Page Layout

Compact layouts are used to display the key fields of a record whenever the minimum required
details of the record is needed. Compact layouts control which fields users see in the highlights
panel at the top of a record.

How to Create Compact Layout

Setup => Object Manager => Compact Page Layout => Click on New Button
●​ Give Label and Name
●​ Add fields to show
Note: We can add up to 10 Fields in Compact Page Layout & we can see up to 7 fields at the
record header.

Compact Page Layout Assignment

After creation of the layout we have to assign it, if we don't assign then it will not appear.

Where we can see the Compact Page Layout

We can see compact layout on Record detail page like:

Also we can see Compact Layout when we hover the cursor on Record Name
 27

Search Layout
In Lightning Experience, We can set the search results layout, or which fields appear as columns
on the search results page. In Lightning Experience,with Search Layouts we can customize which
fields appear in the search results for global search, lookup search, and search results filters. We
aren’t required to separately update Lookup Dialogs or Search Filter Fields.

How to make changes in Search Layout

Object => Edit Object => Search Layout => Go to Desired Profile => Edit => Add Fields to show

How we can see the Search Layout

 28

Record Types
Salesforce record types are ways to group records within a specific object. These are typically
focused on what will make the most sense to the end user. Below are examples of when record
types may be needed:
●​ Accounts types that different groups need to access – customer accounts, partner
accounts, etc.
●​ Opportunity types from different revenue streams – online, retail, etc.
●​ Campaigns types based on lead source – trade show, website, etc.
Record types are used to:
●​ Capture different information for each type (i.e., fields or picklist values).
●​ Allow users access to only the records that are relevant for their jobs.

Record Types can Control:

●​ Picklist
●​ Page Layout

Business Processes with Record Types

●​ Sales Processes
○​ Create different sales processes that include some or all of the picklist values
available for the opportunity Stage field.
●​ Lead Processes
○​ Create different lead processes that include some or all of the picklist values
available for the Lead Status field.
●​ Support Processes
○​ Create different support processes that include some or all of the picklist values
available for the case Status field.
●​ Solution Processes
○​ Create different solution processes that include some or all of the picklist values
available for the Status field.
After creating a sales, support, lead, or solution process, assign the process to a record type. The
record type determines the user profiles that are associated with the business process.
 29

Record Type Consideration

●​ Default Record Type is “Master”
●​ When we create the custom record type there we can see the “Master” as default record
type.
●​ If the Record type is Active then only we can see it.
●​ If we make any record type default then to delete that record type we have to remove it
as default.
●​ If RT is default for many profiles then we need to remove it one by one from all profiles.
●​ These special picklist fields aren’t available for record types because they’re used
exclusively for sales processes, lead processes, support processes, and solution
processes:
○​ Opportunity Stage
○​ Case Status
○​ Solution Status
○​ Lead Status
●​ These campaign member picklists aren’t available for these record types:
○​ Status
○​ Salutation
○​ Lead Source
●​ If the object is referenced in Apex, you can’t edit or delete a record type for the object.
●​ If a record type is in use by an email routing address for Email-to-Case or On-Demand
Email-to-Case, you can’t deactivate the record type.
●​ We recommend creating no more than 200 record types. While there’s no limit, orgs can
have difficulty managing their record types if they exceed 200.
 30

Business Processes in Salesforce

There are 4 Business processes in Salesforce:
●​ Sales Processes
○​ Create different sales processes that include some or all of the picklist values
available for the opportunity Stage field.
●​ Lead Processes
○​ Create different lead processes that include some or all of the picklist values
available for the Lead Status field.
●​ Support Processes
○​ Create different support processes that include some or all of the picklist values
available for the case Status field.
●​ Solution Processes
○​ Create different solution processes that include some or all of the picklist values
available for the Status field.

How to Create Sales Process

Setup => Feature Setting => Sales => Sales Process => Give Name
●​ In the Sales Process we can set values of the Opportunity Stage field.

How to Create Lead Process

Setup => Feature Setting => Marketing => Lead Process
●​ In Lead Process we can set values of Lead Status field.

How to Create Support Process

Setup => Feature Setting => Service => Support Process => Give Name
●​ In the Support Process we can set values of Case Status fields.
 31

Rules in salesforce
●​ Validation Rules
●​ Duplicate Rules
●​ Workflow Rules
●​ Assignment Rules
●​ Auto Response Rules
●​ Escalation Rules
●​ Entitlement Rules

Limitations
●​ Total rules across objects
○​ (Applies to any combination of workflow, assignment, auto-response, and
escalation rules, active and inactive.) = 2000
●​ Active rules per object
○​ (Applies to any combination of active workflow, assignment, auto-response, and
escalation rules, as well as record change processes.) = 50
●​ Total rules per object
○​ (Applies to any combination of workflow, assignment, auto-response, and
escalation rules, active and inactive.) = 500
●​ Entries per rule = 3000
●​ Formula criteria entries per rule = 300
●​ Filter criteria per rule entry = 25
●​ Actions allowed per rule = 200

Entitlement Rules
●​ The entitlement process is used to deliver support in a timely manner and indicate the
type and level of support customers entitled to. It Provides the best solution for customer
support and offers the correct support to customers.
●​ Entitlement processes are timelines that include all of the steps (or milestones) that your
support team must complete to resolve cases.
 32

Assignment Rules
●​ Definition: Assignment rules in salesforce are used to automatically assign lead or Case
to owner (User Or Queue). Assignment rule is used to automate owner assignment on
Case and Lead based on conditions on Case or Lead.
●​ Assignment rules automate your organization’s lead generation and support processes.
Use lead assignment rules to specify how leads are assigned to users or queues. Use
case assignment rules to determine how cases are assigned to users or put into queues.
●​ Lead assignment rules can assign leads regardless of whether leads are created
manually, are generated from Web-to-Lead forms, or are imported using the Data Import
Wizard.
●​ Case assignment rules can assign cases regardless of how cases are created. Cases can
be created manually or automatically using Web-to-Case, Email-to-Case, On-Demand
Email-to-Case, the Self-Service portal, the Customer Portal, Outlook, or Lotus Notes.
●​ Organizations typically use one rule for each overall purpose. For example, use one lead
assignment rule for importing leads and use a different lead assignment rule for
web-generated leads. Or use one case assignment rule for standard use and one case
assignment rule for holiday use. For each rule type, only one rule can be in effect at any
time.
●​ Each rule consists of multiple rule entries that specify exactly how the leads or cases are
assigned. For example, your standard case assignment rule can have two entries: cases
with “Type equals Gold” are assigned to the “Gold Service” queue, and cases with “Type
equals Silver” are assigned to the “Silver Service” queue.

How to Create Lead Assignment Rule

Setup => Feature Setting => Marketing => Lead Assignment Rule

How to Create Case Assignment Rule

Setup => Feature Setting => Service => Case Assignment Rule

Note: While creating Lead & Case there is a checkbox “Assign using active assignment rule”, if we
check that, then only assignment rule assign owner.
 33

Thing to Remember for Assignment Rule

●​ Order - Sets the order in which the entry is processed in the rule, for example, 1, 2, 3.
Salesforce evaluates each entry in order and tries to match the criteria for the entry. When
a match is found, Salesforce assigns the item and stops evaluating the rule entries for that
item. If no match is found, the item is reassigned to either the default Web-to-Lead owner,
the administrator doing a lead import, or the default case owner.
●​ Criteria - Specifies conditions that the lead or case must match for it to be assigned.
●​ User - Specifies the user or queue that the lead or case is assigned to. Users specified
here cannot be marked “inactive”, and they must have “Read” permission on leads or
cases.
●​ Do Not Reassign Owner - Specifies that the current owner on a lead or case will not be
reassigned to the lead or case when it is updated.
●​ Email Template - Specifies the email template to use for the notification email that is
automatically sent to the new owner. If you don’t specify an email template, then
Salesforce doesn’t send a notification email. When a lead or case is assigned to a queue,
the notification email is sent to the Queue Email address specified for the queue and all
queue members.
●​ Predefined Case Teams (Case Assignment Rule) - Specifies the predefined case teams
to add to a case. A case team is a group of people that work together to solve cases. To
select a predefined case team to add to the assignment rule, click the Lookup icon
(Lookup icon). To add more predefined case teams, click Add Row to add a row in which
you can specify a predefined case team.
●​ Replace any existing predefined case teams on the case (Case Assignment Rule) -
When a case matches the condition, any existing predefined case teams assigned to the
case are replaced with the specified case teams.
 34

Duplicate Rules
●​ Definition: A duplicate rule defines what happens when a user views a record with
duplicates or starts creating a duplicate record. Salesforce provides standard duplicate
rules for business and person accounts, contacts, and leads. You can also create
duplicate rules.

Standard Duplication Rules

●​ Standard Account Duplicate Rule
○​ The standard account duplicate rule defines what happens when a user views an
account with duplicates or starts to create a duplicate account. It’s activated by
default.

●​ Standard Person Account Duplicate Rule

○​ The standard person account duplicate rule defines what happens when a user
views a person account with duplicates or starts to create a duplicate person
account. To use this rule, enable person accounts, and then activate the standard
person account matching and duplicate rules in Setup.

●​ Standard Contact Duplicate Rule

○​ The standard contact duplicate rule defines what happens when a user views a
duplicated contact or starts to create a record that duplicates a contact. If your org
was created in Summer ’17 or later, this duplicate rule includes a cross-object
matching rule: It matches contacts that duplicate other contacts and leads that
duplicate contacts. If your org was created before Summer ’17, you can get the
same functionality by activating a new duplicate rule available in Setup. Otherwise,
your default rule matches only contacts that duplicate other contacts.

●​ Standard Lead Duplicate Rule

○​ The standard lead duplicate rule defines what happens when a user views a lead
with duplicates or starts to create a record that duplicates a lead. If your org was
created in Summer ’17 or later, this duplicate rule includes a cross-object matching
rule: It matches leads that duplicate other leads and contacts that duplicate leads.
If your org was created before Summer ’17, you can get the same functionality by
activating a new duplicate rule available in Setup. Otherwise, your default rule
matches only leads that duplicate other leads.
 35

Things to Remember for Duplicate Rules

●​ We can not create duplicate rules for standard objects except Account, Contact and Lead.
●​ We can create duplicate rules for Custom Objects.
●​ For creating duplicate rules we must have matching rule otherwise we can create it while
duplicate rule creation.
●​ Number of Duplicate and Matching Rules
○​ You can use up to five active duplicate rules per object.
○​ You can add up to three matching rules in each duplicate rule, with one active
matching rule per object. When you use multiple duplicate rules, you can include
up to five active matching rules per object.
●​ Global picklist values aren’t supported in duplicate rules.
●​ Custom picklist fields aren’t supported in matching rules used in cross-object duplicate
rules. For example, you can’t use a custom picklist field on the lead object in a rule that
matches contacts which duplicate leads.
●​ When a rollup summary field value changes, duplicate rules run, and the Allow option (to
save a duplicate record) isn’t supported.
●​ Conditions Under Which Duplicate Rules Don’t Run
○​ Records are created using Quick Create or Community Self-Registration.
○​ Leads are converted to accounts or contacts, and Use Apex Lead Convert isn’t
enabled.
○​ Records are restored with the Undelete button.
○​ Records are added using Lightning Sync or Einstein Activity Capture.
○​ Records are manually merged.
○​ A Self-Service user creates records, and the rules include conditions based on the
User object.
○​ Duplicate rule conditions are set for lookup relationship fields and records but no
value for these fields has been saved. For example, a condition specifies that a
duplicate rule runs when a campaign doesn’t contain “Salesforce.” If you then add
a record with no value for the Campaign field, the duplicate rule doesn’t run.
●​ Conditions Under Which Duplicate Rule Settings Are Overridden
○​ In the following situations, no alert is shown and users can’t save records.
○​ Records are added using the data import tools.
○​ A person account is converted to a business account, and the newly created
business account matches an existing business account.
○​ Records are added or edited using Salesforce APIs.
●​ The Translation Workbench doesn’t support the customizable alert text in duplicate rules.
●​ If you have more than one active duplicate rule for a particular object, consider adjusting
the order in which the rules are processed. Reorder rules by clicking Reorder on any
rule’s detail page.
 36

Matching Rule Creation

Setup => Data => Duplicate Management => Matching Rules

Things to Remember while Creating Matching Rule

●​ First we need to select the Object
●​ Then Rule Name and API Name.
●​ Then we have to select the field, Exact Matching Method.
●​ Match Blank Fields - If we are selecting Email as field to Match and we have Match Blank
Field option checked then Blank Email field also comes under duplicate.
●​ After Saving the matching Rule, by default it is inactive. We need to activate it.

Things to Remember while Creating Duplicate Rule

●​ First we need to select the Object
●​ Then Rule Name and API Name.
●​ Record-Level Security
○​ Enforce sharing rules - The matching rule compares only records that the user has
access to, and the resulting list of possible duplicates includes only records the
user has access to.
○​ Bypass sharing rules - The matching rule compares all records, regardless of user
access, but the resulting list of possible duplicates includes only records the user
has access to.
●​ Action On Create - If we Allow then by using duplicate rule we can show warning but
allow to save record. If we choose a block then system will block creating the duplicate
record.
●​ Action On Edit - If we Allow then by using duplicate rule we can show warning but allow to
save record. If we choose a block then the system will block editing the duplicate record.
●​ After creating the Duplicate Rule, by default it is inactive, we need to activate it.

Note: For Edit record, if we are editing the Field added for matching criteria, then duplicate rule
works. If we are editing other field along with it then the duplicate rule does not works.
 37

Auto Response Rules

To create an Auto Response Rule, First we need to create Email-To-Case.

How to Setup Email-To-Case

Feature Setting => Service => Email-To-Case

Things to Remember While setting up Email-To-Case

●​ First we have to make “Enable Email-to-Case” TRUE. Then only Email To Case works.
●​ Then we have to set a Routing Address.
●​ Routing Information
○​ Routing Name - The Email-To-Case routing Name.
○​ Email Address - If someone sends an email on this ID, then a case will get created.
●​ Task Setting
○​ Create Task from Email - When a user create Case from email, automatically case
gets created.
○​ Task Status - We can set the task.
●​ Case Setting
○​ Case Owner - We can set any user or Queue as a case owner.
○​ Case Priority and Status can be set from here.
Note: After setting up all things there will be an Email Services Address getting generated, if a
customer sends mail on that ID then the case will get created.

How to Set Up Auto Response Rule

Feature Setting => Service => Auto Response Rule

Things to Remember While setting up Auto Response Rule

●​ First we have to set the Name of the Auto Response Rule.
●​ We have to Activate it.
●​ Then we have to add criteria to it.
●​ Then we have to provide a name and the email to which system can send the Auto
Response mail.
 38

Escalation Rules
●​ Definition: Case escalation rules in Salesforce are used to reassign and optionally notify
individuals when a case is not closed within a specified time period. Generic Use cases
for escalation rule. If a Tier 1 agent is unable to close the case in a specific amount of time
the case will automatically get assign to Tier 2 Team.

How to Set Up Escalation Rule

Feature Setting => Service => Escalation Rule

Things to Remember while setting up Escalation rules

●​ First we have to Escalation Rule, give it Name, API, and Activate it.
●​ Then as a Step 2, we have to set Rule.
●​ In the rule we have to specify the criteria, based on which Escalation rule works.
●​ Then set a business hrs criteria.
●​ Then we have to set the time from which escalation time starts
○​ When case is created
○​ When the case is created, and disable after case is first modified
○​ Based on last modification time
●​ Then we have to set Escalation Action
○​ Specify the time criteria for this rule - This is the Hrs and we can set 0 or 30 Mins
○​ Auto-reassign cases - Then we can auto reassign case to User or Queue
○​ Notify users - By using this we can notify other users using this option.

Note: If case status is closed then Escalation Rule will not work. & Cases fit under escalation can
be monitored in Environment => Monitor => Case Escalations.
 39

Workflow Rules
Definition: Workflow in Salesforce is basically a container or business logic engine which
automates certain actions based on particular criteria. If the criteria are met, the actions get
executed. When they are not met, records will get saved but no action will get executed.

Difference Between Entry Criterias:

●​ Created : It works after saving a New Record for the first time only. It will not work when
anyone tries to update a record.
●​ Created, and every time it's edited : It works for New Records as well as Old Records
●​ Created, and any time it's edited to subsequently meet criteria : This works on create,
For edit let's consider an example
○​ Condition is : If Country == India or USA then Update Account Name == Prasad
○​ I have created a record with having India as a country (Acc name should get
update with "Prasad")
○​ Then I have edited that record and change Country from India to USA (It will not
update the record because in previous transaction record was updated)
○​ Then i changed country to England and Name to Shubham (Condition did not get
match so no update and record get save)
○​ Then i changed england to India (Then will update name to Prasad)

Structure of Workflow Rule.

●​ To create WFR we need to select an Object first.
●​ Then we have to select when that WFR fire : (we called them as Entry Criteria)
○​ Created
○​ Created, and every time it's edited
○​ Created, and any time it's edited to subsequently meet criteria
●​ Then we need to add conditions for WFR
●​ Then we have to set actions:
○​ New Task
○​ New Email Alert
○​ New Field Update
○​ Outbound Message
●​ Then we need to decide when those actions are going to execute :
○​ Immediate Action
○​ Time Trigger Action
 40

Things to Remember
●​ Workflow Rule is related to the Automation Process.
●​ Workflow Rule is always used to Automate the things.
●​ WFR never fires an error.
●​ It works after saving the record.
●​ For each workflow rule:
○​ You can only have 10-time triggers for every workflow rule
○​ It is not possible to exceed 40 immediate actions
○​ You only get access to 40 time-dependent actions for each time trigger
●​ For both time-dependent and immediate actions in workflow rule:
○​ You only get ten email alerts
○​ The number of tasks is restricted to 10
○​ You can only have ten field updates
○​ The number of outbound messages is limited to 10
●​ Workflow time trigger limit for different editions (hourly):
○​ Professional: 250
○​ Enterprise: 500
○​ Developer: 50
○​ Unlimited and Professional: 1000
●​ Daily email limit for Workflow:
○​ With Standard Salesforce license: 1000
○​ For every organization: 200,000

Examples
For Entry Criteria Created
●​ Selected Object == Opportunity
●​ Entry Criteria == Created
●​ Condition == Country == India
●​ Action == Opp Name == Prasad
●​ Steps
○​ I'm creating a new record with country India = Yes it will update Opp name with
prasad
○​ I have edited that record and change country to England = No, it will not update
(opp name remain as it is)
○​ I have updated the record and changed country to India = No, as this is old record
update system will not update anything
 41

For Entry Criteria Created and Every time it's edited

●​ Selected Object == Opportunity
●​ Entry Criteria == Created and Every time it's edited
●​ Condition == Country == India or USA
●​ Action == Opp Name == Prasad
●​ Steps
○​ I'm creating a new record with country India = Yes it will update Opp name with
prasad
○​ I have edited that record and change country to USA = Yes it will update Opp
name with prasad with prasad
○​ I have updated the record and changed country to India = Yes it will update Opp
name with prasad with prasad
○​ I have edited that record and change country to England = No, it will not update
(opp name remain as it is)

For Entry criteria Created, and any time it's edited to subsequently meet criteria
●​ Selected Object == Opportunity
●​ Entry Criteria == Created and Every time it's edited
●​ Condition == Country == India or USA
●​ Action == Opp Name == Prasad
●​ Steps
○​ I have created a record with Country England = No,as criteria does not match then
no updates, user need to give manual name
○​ I have edited that record and change country to USA = Yes, it will update Opp
name with prasad with prasad
○​ I have edited that record and change country to India and with the name Shubham
= It will not update record automatically but as we are giving name manually so it
will save Shubham as name.

Note: Workflow rules are not in use now, Salesforce deprecated the WFRs. Old created wfrs are
in use, just we can not create new ones.
 42

Validation Rules
Definition: Validation rules verify that the data a user enters in a record meets the standards you
specify before the user can save the record. A validation rule can contain a formula or expression
that evaluates the data in one or more fields and returns a value of “True” or “False".

Things to Remember
●​ Validation rules are a bunch of functions.
●​ Sometimes we can create bad data, to stop that we can create a bunch of functions to
throw the errors.
●​ We can make any field required by using Validation Rules.
●​ Validation Rules fires before saving the Record.
●​ We can make any field Read-Only by using Validation Rules.
●​ We can not delete any record by using the validation rule.
●​ We can fire VR only for new records by using the “ISNEW()” function.
●​ We can fire VR only for old record updates by using the “ISCHANGED()” function.
●​ To use a single selectable picklist inside VR then we have to use the “ISPICKVAL(Name
of Picklist, Value)” function.
●​ We can make the single selectable picklist required by using following
○​ ISPICKVAL (Country__c, ‘ ‘)
■​ Country__c considered as a single selectable picklist.
■​ ‘ ‘ indicates blank value
■​ It can be read as “Is Country Picklist Blank?”
●​ If Yes then it will throw the validation.
●​ We can make Multi Selectable Picklist required by using following
○​ ISBLANK (District__c)
■​ District__c considered as a Multi Select Picklist
■​ It can be read as “Is District Picklist Blank?”
●​ If Yes then it will throw the validation.
●​ We can show Error at “Top of the Page” or at “Below Specific Field”.
●​ If we are showing an error below any field and we hide that field from Page Layout then
the error location changes to First Field which comes alphabetically first.
●​ We can refer to the Parent Object field from the Child object VR.
●​ We can not refer to the Child object field from the Parent Object VR.
●​ We can not delete the field which is referred to in any VR.
●​ When one validation rule fails then it will check other validations also and throw all
validation errors at the same time.
 43

●​ Order of Execution for all Rules

○​ Validation Rule
○​ Assignment Rule
○​ Auto Response Rule
○​ Workflow Rule
○​ Escalation Rule
●​ If we have a validation rule on Activity & we are creating activity records at time of Lead
Conversion then the Validation Rule will not fire.
●​ Validation will fire on activity on lead conversion, only if we enable validation, Trigger on
lead conversion.
●​ Validations are not applicable on Campaign Hierarchies.
●​ When we are creating Web-To-Lead or Web-To-Case then the validation rule will fire.
●​ If we are changing the owner of an individual record then validation will fire, but when we
use a mass transfer tool for owner change then validation will not fire.
●​ When we have a field update through WFR, Approval then it bypasses the VR.
●​ Assignment Rules, field updates, FLS or Hidden field can cause Validation failure so
investigate it accordingly.
●​ If we are using related object fields, then make sure that object is deployed.
●​ To use record types, use RecordType.ID field for the same.
●​ BEGINS () or CONTAINS (), function consider Blank values as Valid.
●​ To check opportunity ClosedWon Stage, do not use the following functions ISClosed ()
or ISWon ().
●​ If we have Assignment Rule, Auto Response Rule, WFR, Immediate field update then they
can bypass validation rules. Only by creating or Updating records we can not bypass the
validation rule.
●​ To bypass Validation Rule for Data Loader
○​ Create a API Named Field (Checkbox)
○​ Add condition in VR that API__C = False
○​ Hide field on page layout
○​ While inserting data mark API__c = True
○​ This way we can bypass VR for Data Loader.
 44

Examples
1. Implement a validation rule in which if a country picklist has value as India, then only user can
enter value in currency.
Ans: ​ AND
​ ​ (
​ ​ ​ NOT (ISPICKVAL (Country__c, ‘India’)),
​ ​ ​ NOT (ISBLANK (Currency__c))
​ ​ )

2. Implement a validation rule that if an account has the “opportunity create permission”
checkbox is true, then only the user can create the opportunity. Otherwise the user should get an
error “You do not have permission to create an opportunity”.
Ans: AND
​ ​ (
​ ​ ​ Opportunity.Account.Opportunity_create_permission__c = False,
​ ​ ​ ISNEW ()
​ ​ )
●​ System Will check like​
○​ Both Conditions are in AND so both must be TRUE
○​ Second line will check whether the checkbox on the account is false.
○​ Third line will check whether the Opportunity record is newly created.

3. Admin wants to avoid deletion of child records in MD Relationship. Is it possible to achieve it

through point & click functionality?
Ans:
●​ Create Roll Up Summary of Account.
●​ Write validation rule that checks, where the count on Roll Up is less than current
○​ Priorvalue (Roll Up Field) < Roll Up Field
●​ When we delete a child then on Parent count, it will reduce by 1. This can prevent child
deletion.
 45

4. What is the difference between AND or OR operator with example.

Ans: AND Operator
AND
​ ​ (
​ ​ ​ ISPICKVAL ( Country__c, ‘India’),
​ ​ ​ NOT (ISPICKVAL (Language__c, ‘Hindi’)
​ ​ )
●​ System will throw an error when
○​ Country is India
○​ Language is not Hindi
○​ If both are True, then validation will fire an error.
OR Operator
​ OR
​ ​ (
​ ​ ​ ISPICKVAL ( Country__c, ‘India’),
​ ​ ​ NOT (ISPICKVAL (Language__c, ‘Hindi’)
​ ​ )
●​ It will fire validation when,
○​ If Country != India, Language != Hindi,
○​ If only Language != Hindi, country is other than India,
○​ If Country = India, Language = Hindi
○​ This means that if any of the conditions is True, then validation will fire an error.

5. Create a validation rule in which. Create a checkbox on Account. When a user tries to edit a
checkbox, if the user has a profile system admin then only allows the user to edit that checkbox.
Checkbox Name = Active.
Ans: AND
​ ​ (
​ ​ ​ User.Profile != System Admin,
​ ​ ​ ISCHANGED ( Active__c )
​ ​ )
 46

6. Create a validation rule in which make a field read only. Field must be the checkbox. Field
Name = Active.
Ans: OR
​ (
​ ​ AND
​ ​ ​ (
​ ​ ​ ​ ISNEW (),
​ ​ ​ ​ Active__c = False
​ ​ ​ ),
​ ​ AND
​ ​ ​ (
​ ​ ​ ​ NOT ( ISNEW() ),
​ ​ ​ ​ ISCHANGED (Active__c )
​ ​ ​ )
​ )

7. Create a validation rule in which the user should have edit access at time of creation of record
& after creation field should be read only.
Field Data Type = Date
Field API Name = Contract_Date__c
Ans: AND
​ ​ (
​ ​ ​ NOT( ISNEW() ),
​ ​ ​ ISCHANGED (Contract_Date__c)
​ ​ )
 47

8. On the contract object, make the phone field mandatory when email contains ‘test@gmail.com’,
this validation should only fire on existing data.
Ans: AND
​ ​ (
​ ​ ​ CONTAINS (Email, ‘test@gmail.com’),
​ ​ ​ ISBLANK (Phone),
​ ​ ​ NOT ( ISNEW() )
​ ​ )

9. Create a field on user object 1. Segmentation__c, 2. Data Type == Picklist, 3. Values == Europe,
Asia, USA
Create a field on Opportunity 1. Sales_Segment__c, 2. Data Type == Picklist, 3. Values == SMB,
Mid Market
When the value SMB & Owner (User) has segmentation Asia then fire validation.
Ans: AND
​ ​ (
​ ​ ​ ISPICKVAL ( Sales_segment__c, ‘SMB’ ),
​ ​ ​ ISPICKVAL ( Opp.Owner.segmentation__c, ‘Asia’ )
​ ​ )

10. Create a validation rule where, If someone is going to Closed Won the opportunity then
previous stage must be “Negotiation”
Ans: AND
​ ​ (
​ ​ ​ ISPICKVAL ( Stage, ‘Closed Won’),
​ ​ ​ NOT (ISPICKVAL (PriorValue (Stage), ‘Negotiation’ )),
​ ​ ​ ISCHANGED (Stage)
​ ​ )
 48

11. Create a field on Account,

●​ Data Type = Picklist
●​ Field Name = Country__c
●​ Values = USA, Canada, India
Create another field on Account
●​ Data Type = Text
●​ Field Name = Market_size__c
Conditions are-
●​ When Country = USA , then user should be able to enter “Mid Market”
●​ When Country != USA, then user should not be able to enter any data
Ans: OR
​ (
​ AND
​ ​ (
​ ​ ISPICKVAL (Country___c, ‘USA’),
​ ​ NOT ( CONTAINS (Market_size__c, ‘Mid-Market’))
​ ​ ),
​ AND
​ ​ (
​ ​ NOT (ISPICKVAL(Country__c, ‘USA’)),
​ ​ ISCHANGED (Market_Size__c)
​ ​ )
​ )
 49

12. Create a Validation Rule

●​ Create RT on Account = Main Account
●​ Create a checkbox on account = Active
●​ Condition
○​ If user creates an opportunity under that Group Restaurant, then the user should
be able to create an opportunity when only Active__c = True.
Ans: As we have to restrict Opportunity creation, VR should be on the Opportunity.
​ AND
​ ​ (
​ ​ ​ Opp.Acc.RrcordType.DeveloperName = Main_Account,
​ ​ ​ ISNEW(),
​ ​ ​ Opportunity.Account.Active__c = False
​ ​ )
 50

Process Builder
Definition: Process builder is used to automate more complex business processes just by a few
point and click actions. It provides a user – friendly representation for building a process in
Salesforce.

Considerations
●​ Execution Sequence
○​ Validation rules
○​ Assignment rules
○​ Auto-response rules
○​ Workflow rules and processes (and their immediate actions)
○​ Escalation rules
●​ Processes Evaluate Record Changes When:
○​ A record is saved or created. Processes that are created after records are saved
don’t evaluate those records retroactively.
○​ A standard object in a master-detail relationship is reparented.
○​ Users synchronize records that were changed while using Connect Offline.
○​ Leads are converted, if the lead setting Require Validation for Converted Leads is
enabled.
○​ Another process, workflow rule, or flow updates the record in the same save
operation, if the process is configured to reevaluate records.
○​ Processes can reevaluate records up to five times in one save operation. In a
batch update, processes reevaluate only changed records.
●​ Processes Don’t Evaluate Record Changes When:
○​ Campaign statistic fields, such as individual campaign statistics or campaign
hierarchy statistics, are updated.
○​ Picklist values are mass replaced.
○​ Address fields are mass updated.
○​ Divisions are mass updated.
○​ Territory assignments of accounts and opportunities are modified.
○​ Self-Service Portal, Customer Portal, or partner portal users are deactivated.
○​ State and country/territory data is converted with the Convert tool.
○​ Values for state and country/territory picklists are modified using AddressSettings
in the Metadata API.
 51

What we can do with Process Builders

●​ Create a Record​
○​ Creates a record by manually entering values or by using the values of related
records.
●​ Update any related record
○​ Updates one or more records—that are related to the record that started the
process—by manually entering values or by using the values from related records.
●​ Quick Actions
○​ Create a record, update a record, or log a call by using an object-specific or global
action that you or another administrator created for your organization
●​ Launch a Flow
○​ Launches a flow from your process to automate complex business
processes—creates flows to perform logic and enables events to trigger the flows
via processes—without writing code.
●​ Send an Email
○​ Easily send an email from a process by using an email alert. Email alerts are
configured outside of the Process Builder and contain the standard text, list of
recipients, and template for the email.
●​ Post to Chatter
○​ Post to the feed of a user, a Chatter group, or the record that started the process.
●​ Submit for Approval
○​ Submit the record that started the process for approval.
●​ Apex
○​ Now, you can call an Apex from a process builder for a particular scenario without
going for triggers and Visualforce.
○​ And also that Apex should have @invokeablemethod.

How to Create a Process Builder

Setup => Quick Find Box => Type “Process Builder”
 52

Process Builder Structure

●​ Button Bar (1)

○​ Use the button bar to collapse and expand actions, clone the process and
activate/deactivate the process.
●​ Canvas (2)
○​ Canvas is a main workplace for the process
●​ Add Objects (3)
○​ The records that the process should evaluate
●​ Criteria nodes (4)
○​ Entry criteria node includes conditions that are used to evaluate the records.
●​ Actions. (5&6)
○​ If the criteria met for the record that starts the process, the actions start
immediately or at a scheduled time.
 53

Entry Criteria
●​ Creation: When we create a Process Builder we have to choose the Entry criteria for it:

●​ There are 3 Entry Criterias

○​ A Record Changes - When records get created or updated.
○​ A Platform Event Message is Received - When Platform event message get
generated then PB Invokes
○​ It’s invoked by another process - When other PB outputs work as input for this
i.e., PB called from other PB.
 54

Object Selection w.r.t. Entry Criteria “A Record Changes”

The first block is for selecting the Object

●​ Object
○​ Here we can select any Standard or Custom object except Big Object.
●​ Start The Process
○​ Only when a record is created
○​ When record is created or updated
●​ Advance
○​ Recursion - It updates records multiple times if it get fit into many processes like
PB, WFR, Approval process etc.

Note:
●​ We can select object at time on new PB creation or change the object before Activating it
(The very first version only).
●​ After Activating we can not make any changes into it.
●​ If we want to do any changes in Start The Process or at Advance then we need to clone
the PB.
●​ After cloning and if PB’s new version is not activated then also we can not change the
object.
 55

Evaluation Criteria

Here in the evaluation criterias we can set the Criterias on the basis of which PB invokes
●​ Criteria Name
○​ We can give the name to criteria (Name should be meaningful according to
business)
●​ Criteria for Executing Actions
○​ Conditions are met - We can set the any field values and it these values met then
PB start working
○​ Formula evaluates to true - We can set the custom formula, if it evaluates to true
then PB starts working.
○​ No criteria—just execute the actions! - PB Executes without any condition.
●​ Set Condition
○​ This box is visible only when we select “Conditions are met”.
○​ If we select formula evaluates to true then a formula editor appears.
○​ If we select no conditions then everything below criteria selection disappears.
●​ Conditions (Logics)
○​ AND, OR, Custom
●​ Advance
○​ Do you want to execute the actions only when specified changes are made to the
record?
■​ If we select it, then PB works when we update the mentioned fields in
criteria or formula and meet the condition.
 56

Record Update Using a Process builder

●​ Create a Process Builder to Update Account Records.
●​ Select “A Record Update” as an Entry Criteria.
○​ For this we have below sub criterias
■​ When Record is created
■​ When record is created or Edited
●​ Then add Account as an object in the Object selector and select any sub criteria.
●​ Then select the Criteria box and add following
○​ Add Criteria Name
○​ Select conditions are met as an evaluation criteria
○​ Add criteria
■​ Field = Account Type
■​ Operator = Equals
■​ Type = Picklist
■​ Value = Prospect
●​ Add condition as All of the conditions are met (And)
●​ Then we have to add the “Immediate Action”
○​ Select Action Type as “Update Record”
○​ Give Action Name
○​ Select Record Type as “Select the Account record that started your process”
○​ In criteria for updating record select no condition just update the record
○​ Select field to update
■​ Field - Active
■​ Type - Picklist
■​ Value - Yes

Output: When we create any record which has Account Type = Prospect then after saving it will
update Active = True.
 57

Email Alert through Process Builder

Prerequisite: We should have an Email Alert action before creating the PB
How to create Email Alert = Setup => Quick Find Box => Select Email Alert

●​ Create a Process Builder on the Contact Object.

●​ Select “A Record Update” as an Entry Criteria.
○​ For this we have below sub criterias
■​ When Record is created
■​ When record is created or Edited
●​ Then add Contact as an object in the Object selector and select any sub criteria.
●​ Then select the Criteria box and add following
○​ Add Criteria Name
○​ Select conditions are met as an evaluation criteria
○​ Add criteria
■​ Field = Contact Lead Source
■​ Operator = Equals
■​ Type = Picklist
■​ Value = Web
●​ Add condition as All of the conditions are met (And)
●​ Then we have to add the “Immediate Action”.
○​ Select Action Type as “Email Alert”.
○​ Give action name and select previously created Email Alert.

Output: When we create the Contact Record with lead Source as Web then the system sends the
Email Alert, which can appear in Spam of Email.
 58

Create a Record using Process Builder

Use Case: When Account Type is prospect then create Opportunity Under that Account.

●​ Create a Process Builder to Update Account Records.

●​ Select “A Record Update” as an Entry Criteria.
○​ For this we have below sub criterias
■​ When Record is created
■​ When record is created or Edited
●​ Then add Account as an object in the Object selector and select any sub criteria.
●​ Then select the Criteria box and add following
○​ Add Criteria Name
○​ Select conditions are met as an evaluation criteria
○​ Add criteria
■​ Field = Account Type
■​ Operator = Equals
■​ Type = Picklist
■​ Value = Prospect
●​ Add condition as All of the conditions are met (And)
●​ Then we have to add the “Immediate Action”
○​ Select Action Type as “Create Record”
○​ Give action name
○​ In Record Type select Opportunity (It will show some required fields to fill up
information)
■​ Field = Closed Date
■​ Type = Date
■​ Value = Mar 21, 2023
■​ Field = Name
■​ Type = String
■​ Value = New Opp
■​ Field = Stage
■​ Type = Picklist
■​ Value = Prospecting
●​ To associate this opp to Acc we have to select Account ID , field Reff to Account, so that
this opp is created under this account.

Output: When a user creates an Account with Type picklist then the system will create an
opportunity under the account.
 59

Post to Chatter through Process Builder

Use Case: When an account record is created and its annual revenue is not null, then post
account name and annual revenue on Chatter.

●​ Create a Process Builder to Update Account Records.

●​ Select “A Record Update” as an Entry Criteria.
○​ For this we have below sub criterias
■​ When Record is created
■​ When record is created or Edited
●​ Then add Account as an object in the Object selector and select any sub criteria.
●​ Then select the Criteria box and add following
○​ Add Criteria Name
○​ Select conditions are met as an evaluation criteria
○​ Add criteria
■​ Field = Account Revenue
■​ Operator = IS NULL
■​ Type = Boolean
■​ Value = False
●​ Add condition as All of the conditions are met (And)
●​ Then we have to add the “Post to Chatter”
○​ Give action Name and provide Post to : This Record
○​ Add Message

Output: When a user creates an account with Annual Revenue, then go to Related List => Chatter.
There we can see the chatter message.

When we select Post To: User then a chatter message will appear in the chatter object.
 60

Parent to Child Record field update through Process Builder

Use Case: When an account record is created or updated and its description is not null, then
populate Description of account Record on all child opportunities.

●​ Create a Process Builder to Update Account Records.

●​ Select “A Record Update” as an Entry Criteria.
○​ For this we have below sub criterias
■​ When Record is created
■​ When record is created or Edited
●​ Then add Account as an object in the Object selector and select any sub criteria.
●​ Then select the Criteria box and add following
○​ Add Criteria Name
○​ Select conditions are met as an evaluation criteria
○​ Add criteria
■​ Field = Account Description
■​ Operator = Is Null
■​ Type = Boolean
■​ Value = False
●​ Add condition as All of the conditions are met (And)
●​ Then we have to add the “Update Action”.
●​ Give action Name and provide Record Type to Select a record related to the Account =
Opportunity.
●​ Then add “Set new field values for the records you update” to
○​ Field: Description
○​ Type: Field Reference
○​ Value: Account Description

Output: Whenever Account description gets changed then related opportunities will have
updated description on them.
 61

Child to Parent Record Field Update through Process Builder

Use Case: Whenever a new opportunity is created, updates its Created by id on Account.

●​ Create a Process Builder to Update Account Records.

●​ Select “A Record Update” as an Entry Criteria.
○​ For this we have below sub criterias
■​ When Record is created
■​ When record is created or Edited
●​ Then add Opportunity as an object in the Object selector and select any sub criteria.
●​ Then select the Criteria box and add following
○​ Add Criteria Name
○​ Select Criteria as no Criteria
●​ Create an Immediate Action
●​ Select Record Update as Action
○​ Give field reference of Created by to Account Description

Output: Whenever a user created opp under an account, it will populate opp created by id on acc
description.
 62

Approval Process
Considerations
●​ Associated Object
○​ If the approval object is a detail object in a master-detail relationship, Owner isn’t
available for approval page layouts or approval post templates.
●​ Approval Criteria
○​ In approval criteria—either the entry criteria or step criteria—don’t reference
expressions that resolve to random values. That way, if the criteria must be
evaluated again, the record is evaluated the same every time.
●​ Compatibility with Other Features
○​ Flows can delete records that are pending approval.
○​ Design automated actions so that you can use them for both workflow rules and
approval processes.
●​ Field Update Actions in Approvals
○​ An approval process can specify a field update action that reevaluates workflow
rules for the updated object. If, however, the reevaluated workflow rules include a
cross-object field update, those cross-object field updates are ignored.
○​ Field updates that are executed as approval actions don’t trigger workflow rules or
entitlement processes.
●​ Anticipate Errors
○​ Consider reviewing the content on approvals errors. That way, you can anticipate
common issues and configure your approval process so that the error is less likely.
●​ Approvals in Unlocked Packages
○​ Unlocked packages can include Approvals with steps that reference related users
or queues as approvers; users aren’t supported.
○​ Queues and related user fields (lookup fields) referenced by the approval steps
must be included in the unlocked package.
○​ An Approval Process can only be included in unlocked packages that don’t have a
specified namespace.
 63

Considerations for Assigning Approvals to Queues

●​ Any queue member can approve or reject an approval request that is assigned to the
queue.
●​ Approval request emails are sent to the queue email address. If the queue is set up to
send email to members, approval request emails get sent to the queue members, unless
their approval user preferences are set to never receive approval request emails.
●​ Because email notifications to a queue aren’t intended for an external audience,
{!ApprovalRequest.External_URL} returns the equivalent internal URL.
●​ Salesforce mobile app notifications for approval requests aren’t sent to queues. For each
approval step involving a queue, we recommend adding individual users as assigned
approvers, so at least those individuals can receive the approval request notifications in
the Salesforce mobile app. To have both queues and individual users as assigned
approvers, select Automatically assign to approver(s) instead of Automatically assign to
queue in the approval step.
●​ When an approval request is rejected and returned to the previous approver and the
previous approver was a queue, the approval request is assigned to the user who
approved it instead of the queue.
●​ The Approval History related list displays the queue name in the Assigned To column and
the actual user who approved or rejected the approval request in the Actual Approver
column.

Considerations for Managing Approvals

●​ Admin Permissions
○​ Users with one of these permissions are considered approval admins.
○​ Modify All object-level permission for the given object
○​ Modify All Data user permission
○​ Approval admins can:
○​ Approve or reject pending approval requests without being part of the approval
process
○​ Edit records that have been locked for approval
●​ Activating Approval Processes
○​ An approval process must have at least one step before you can activate it.
○​ Before you activate your approval process, test it in your Salesforce sandbox.
○​ After an approval process is activated, you can’t add, delete, or change the order
of the steps or change its reject or skip behavior, even if the process is inactive.
●​ Monitoring In-Flight Approval Processes
○​ Standard reports for approval requests are included in both the Administrative
Reports folder and the Activity Reports folder.
○​
 64

●​ Deleting Approval Processes

○​ Before you delete an approval process:
○​ Make sure it’s inactive.
○​ Delete all approval requests that are associated with it, and remove them from the
Recycle Bin.

Structure
●​ Aim : To approve or reject the record on the basis of some criteria
●​ Only two results : Approve or Reject
●​ Steps
○​ Entry Criteria
■​ Initial Criteria to enter in the process
■​ Initial Submission Action (When record send for approval)
○​ Record Lock
■​ Email, Field Update, Outbound Message
○​ Approval Steps
■​ Decides criteria for sending record to diff diff approvers
○​ Final Approval Action
■​ Record Lock / Unlock
■​ Email, Field Update, Outbound Message
○​ Final Rejection Action
■​ Record Lock / Unlock
■​ Email, Field Update, Outbound Message
○​ Recall Action
■​ Record Lock / Unlock
■​ Email, Field Update, Outbound Message
 65

Limits
 66

Security Model
Definition: Salesforce provides a detailed and versatile data protection model to safeguard data
at different levels to ensure and provide a security framework that fulfills numerous exceptional
proper business instances. It furthermore includes salesforce security tools to access the security
database on the business necessities.

There are 4 Levels of security provided by Salesforce.

●​ Org Level Security
●​ Object Level Security
●​ Field Level Security
●​ Record Level Security
 67

Profiles in Salesforce
A profile is a collection of settings and permissions that determine which data and features in the
platform users have access to.
It is like a template, it means whenever we want to create a new profile we have to choose a
profile that is already given by Salesforce and then we can customize them according to our
requirements.
We must choose a profile while creating a new profile so we don’t have to set all the permissions
and settings from scratch.
Settings determine what users can see for example apps, tabs, fields, and record types whereas
Permission determines what users can do for example create or edit records of a certain type, run
reports, and customize the app.

Profiles Can Control

●​ Object Permission
●​ Field Permission
●​ User Permission
●​ Tab Settings
●​ App Settings
●​ Apex class access
●​ Visualforce page access
●​ Page Layouts
●​ Record Types
●​ Login Hours
●​ Login IP Ranges

Note:
●​ Object permissions on the Standard profile cannot be edited. So to overcome this, it is
good to make a new profile by copying/cloning standard profiles and then customize the
copies to fit the needs of the organization. The profile functionality in an organization
depends on the user license type.
●​ Every profile should have at least one visible app.
●​ If an app is visible, its tab won’t show up unless a profile has permission to view the
associated objects.
●​ A profile can be assigned to many users but the user can be assigned to only one profile
at a time.
 68

Some Standard Profiles

●​ Standard User
○​ Standard User profile has Read, Edit, and Delete permissions to most standard
objects
●​ Read Only
○​ The Read-only users had permissions exactly similar to the standard user but
limited access to read-only.
●​ Marketing User
○​ Permissions of Standard User + Additional Permissions.
●​ Contract Manager
○​ Permissions of Standard User + Additional Permissions.
●​ Solution Manager
○​ Permissions of Standard User + Additional Permissions.
●​ System Administrator
○​ The System Administrator profile has the widest access to data and the greatest
ability to configure and customize Salesforce. The System Administrator profile
also includes two special permissions namely “View All Data” and “Modify All
Data”.
 69

Users in the Salesforce

Definitions: A user is anyone who logs in to Salesforce. Users are employees at your company,
such as sales reps, managers, and IT specialists, who need access to the company's records.
Every user in Salesforce has a user account.

Usernames
●​ Usernames must be unique across all Salesforce orgs, including trial and Sandbox orgs.
●​ The username must be in the format of an email address, for example,
jane@salesforce.com.
●​ The email used in your username need not function or match the email address used for
the account.
●​ You can have the same email address associated with your account across multiple orgs.
For example, create unique usernames like jane@company.sandbox and
jane@trialorg.company.com, for different accounts that are associated with the same
email address.
●​ Keep in mind that Salesforce Customer Support can’t change usernames or deactivate
users from an org.
●​ If you get a Duplicate Username error, check if the username is already in use in your
production, trial, or Sandbox orgs.
●​ Deactivate or change the username for the user record, then create your account with
your desired username in your production org.
●​ If you’re unable to change or deactivate a username, contact your Salesforce admin for
help.
●​ If you’re unable to locate the org where the username is already in use, try a different
username to create your account.

Personal information
●​ Users can change their personal information after they log in.

User Sharing
●​ If the organization-wide default for the user object is Private, users must have Read or
Write access to the target user to access that user’s information.
 70

Changing email addresses

●​ If you change a user’s email address and the Generate new password and notify the user
immediately, the setting is disabled, Salesforce sends a confirmation message to the
updated email address.
●​ Before the new email address is active, the user must click the link provided in the
message.
●​ If a user changes their own email address, Salesforce sends a confirmation message to
the user’s new email address and a verification code to the old address.
●​ When the user receives the confirmation email, they must enter the verification code to
finish updating their email address.
●​ If you change a user’s email address and the Generate new password and notify the user
immediately, setting is enabled, Salesforce sends a password reset link to the new email
address.
●​ Before the new email address is active, the user must create a new password.

Domain Names
●​ You can restrict the domain names of users’ email addresses to a list of specific domains.
Any attempt to set an email address with another domain results in an error message. To
enable this functionality for your organization, contact Salesforce.

Unlock Users
●​ Users can be locked out of their org when they enter incorrect login credentials too many
times. Unlock users to restore their access.
●​ From Setup, enter Users in the Quick Find box, then select Users.
●​ Select the locked user.
●​ You can view the number of failed login attempts for the user’s account in the Failed Login
Attempts field. When the maximum number of failed login attempts is reached, the
counter resets and the user’s account is locked. If there’s a successful login before the
maximum number of failed login attempts is reached, the counter resets and the user’s
account remains unlocked.
●​ Click Unlock.
●​ This button appears only when a user is locked out.
 71

Delete Users
●​ While you can’t completely delete a user, you can deactivate a user’s account so they
can’t log in to Salesforce.
●​ Salesforce lets you deactivate users, but not delete them outright. A user can own
accounts, leads, and groups, and can be on multiple teams.
●​ Removing a user from Salesforce affects many processes in the org. After departure from
the org, you obviously don’t want the user to retain access to their account.
●​ However, merely deleting a user can result in orphaned records and the loss of critical
business information.
●​ For these reasons, deactivating rather than deleting the user is the appropriate action to
take.
●​ Deactivation removes the user’s login access, but it preserves all historical activity and
records, making it easy to transfer ownership to other users.
●​ For situations where changing ownership to other uses must be done before deactivation,
freezing the user prevents login to the org and access to the user’s accounts.

Deactivate Users
To deactivate a user’s account so they can no longer log into Salesforce, complete these steps.
●​ From Setup, in the Quick Find box, enter Users, then select Users.
●​ Click Edit next to a user’s name.
●​ Deselect the Active checkbox, and then click Save.
Considerations for Deactivating an User
●​ The user remains in the list of users, but is shown as not active.
●​ The user still appears as a member of public groups they’ve been a part of and any
default accounts and sales teams.
●​ Deactivating the user doesn’t affect the records they owned until ownership is transferred
to others.
●​ All the user’s overrides remain, but they’re frozen.
●​ In Chatter, the user’s profile remains, but it shows they’re inactive. However, the user
remains the owner of any Chatter group they owned until an admin reassigns ownership.
●​ You’re prevented from deactivating a user if the user is the:
○​ default owner of leads
○​ default or automated case owner
○​ default lead creator or owner
○​ default workflow user
○​ recipient of a workflow email alert
○​ a user selected in a custom hierarchy field
○​ a customer portal administrator.
 72

●​ In these cases you can prevent the user from accessing their accounts by freezing them.
Freezing a user is done from the user’s User Record. Later, after updating ownership and
other processes, you can deactivate the user’s account.
●​ Finally, if the deactivated user was an approver, you must remove the user from all
approval processes, or reassign their approval responsibilities to other users.
●​ Situations preventing deactivation
○​ Some situations can prevent you from deactivating a user. In these cases, you
must freeze the user’s account first to prevent logins while you reassign
ownership, memberships, and so on, as needed. Then you can deactivate later.
●​ User licenses and billing
○​ A deactivated user doesn’t count against your organization’s available user
licenses. However, deactivating a user doesn’t reduce the number of licenses for
which your organization is billed. To change your billing, you must change your
organization’s license count.
●​ Users in custom hierarchy fields
○​ You can’t deactivate a user that’s selected in a custom hierarchy field even if you
delete the field. To deactivate a user in a custom hierarchy field, delete and
permanently erase the field first.
●​ Process Builder
○​ Processes can't update records that are owned by inactive users. When you
deactivate a user, also transfer that user's records to an active user to avoid failed
processes.
●​ Workflow email alert recipients
○​ You can’t deactivate a user that’s assigned as the sole recipient of a workflow
email alert.
●​ Customer Portal Administrator users
○​ You can't deactivate a user that’s selected as a Customer Portal Administrator.
●​ Record access
○​ Deactivated users lose access to any records that were manually shared directly
with them, or implicitly shared with them as team members. Users higher in the
role hierarchy relative to the deactivated users also lose access to those records.
However, you can still transfer their data to other users and view their names on
the Users page.
●​ Chatter
○​ If you deactivate users in an organization where Chatter is enabled, they’re
removed from the Following and Followers lists. If you reactivate the users, the
subscription information in the Following and Followers lists is restored.
○​ If you deactivate multiple users, subscription information isn’t restored for users
that follow each other. For example, user A follows user B and user B follows user
A. If you deactivate users A and B, their subscriptions to each other are deleted
 73

from Following and Followers lists. If user A and user B are then reactivated, their
subscriptions to each other aren’t restored.
●​ Salesforce Files
○​ Files owned by a deactivated user aren’t deleted. The deactivated user is the file
owner until an admin reassigns the files to an active user. Files shared in a content
library can be edited by other library members with author or delete permissions.
Sharing rules remain active until an admin modifies them.
●​ Created By fields
○​ Inactive users can be listed in Created By fields even when they’re no longer
active in an organization. Some system operations create records and toggle
preferences, acting as an arbitrary administrator user to complete the task. This
user can be active or inactive.
●​ Accounts and opportunities owned by deactivated users
○​ You can create and edit accounts, opportunities, and custom object records that
are owned by inactive users. For example, you can edit the Account Name field on
an opportunity record that’s owned by an inactive user. This feature requires
administrator setup.
●​ Enterprise Territory Management
○​ Deactivated users are no longer assigned to territories and are removed from the
territories they were assigned to.
●​ Opportunity and account teams
○​ Deactivated users are removed from the default opportunity and account teams of
other users. The deactivated users’ default opportunity and account teams aren’t
removed.
●​ Account teams
○​ When a user on an account team who has Read/Write access (Account Access,
Contact Access, Opportunity Access, and Case Access) is deactivated and then
reactivated, access defaults to Read Only.
●​ Opportunity teams
○​ If you deactivate users in an orgwhere opportunity splitting is enabled, they aren’t
removed from any opportunity teams where they’re assigned a split percentage.
To remove a user from an opportunity team, first reassign the split percentage.
●​ Delegated external user administrators
○​ When a delegated external user admin deactivates a portal user, the admin can’t
remove the portal user from teams that user is a member of.
●​ CRM Analytics
○​ When you deactivate a user who scheduled a dataflow, the dataflow schedule is
deleted and the dataflow is unscheduled.
 74

Freeze or Unfreeze User Accounts

●​ In some cases, you can’t immediately deactivate an account, such as when a user is
selected in a custom hierarchy field. To prevent users from logging in to your organization
while you perform the steps to deactivate them, you can freeze user accounts.
●​ How to Freeze
○​ From Setup, enter Users in the Quick Find box, then select Users.
○​ Click the username of the account you want to freeze.
○​ Click Freeze to block access to the account or Unfreeze to allow access to the
account again.
●​ Freezing user accounts doesn’t make their user licenses available for use in your
organization. To make their user licenses available, deactivate the accounts.

Restrict User Email Domains

●​ You can define an allowlist to restrict the email domains allowed in a user’s Email field.
●​ How to Restrict
○​ From Setup, in the Quick Find box, enter Allowed Email Domains, and then select
Allowed Email Domains.
○​ Click New Allowed Email Domain.
○​ Enter a Domain.
○​ You can enter a top-level domain, such as sampledoc.org, or a subdomain, such as
emea.sampledoc.org.
○​ Click Save.
 75

Public Groups in Salesforce

Definition: Salesforce public groups are groups of users who can share records. Groups differ
from Permission Set Groups in that they only contain users while Permission Set Groups manage
permission sets based on user needs.
●​ For example, when there are multiple offices for a company, you may want to provide
access to records or list views based on location. A public group for each office would
allow each user to view only records related to them.
●​ How to Create
○​ From Setup, in the Quick Find box, enter Public Groups, and then select Public
Groups.
○​ Click New.
○​ Enter a label.
○​ From the Available Members list, select the members who you want to assign to
the group. To move the selected members to the Selected Members list, click Add.
○​ Save your changes.

Queues In Salesforce
Definition: Salesforce queues are lists of records that have no owner. The records that are not
assigned to anyone are added to a queue, and any queue member can take ownership of those
records. One with queue authority can go through the records in the queue and take
responsibility for the ones they wish.
●​ Once a new record is added to the queue, all queue members receive an email. The
email for queue members can be set from the Salesforce queue email template. The
records will remain in the queue itself until a queue member picks them up.
●​ Queues can assign records to teams by prioritizing the task.
●​ Queues are mostly used for leads and sales.
●​ The sales and support team has a lot of leads and issues to resolve in their work.
●​ The records stay in a queue until someone owns them. A queue helps an organization’s
employees as well as customers. Because of a queue, the employees will not be
overworked, and all customer concerns will be dealt with promptly. This will also help to
make sure that no record is left behind.
 76

Org Level Security

Definition: Org Level security is 1st level of security which users face, which includes, Password
Policies, IP Ranges.

Password Policies
How to Apply Password Policies
There are 2 ways to apply org level security
●​ From Setup : Setup => Security => Password Policies
●​ From Profiles : Setup => Profile => Open Any Profile => Password Policies

What is the diff between applying Password Policies from Setup & Profiles
●​ If we apply Password policies from setup then it is applicable to all active users present in
the org.
●​ If we apply Password Policies from Profiles then it is applicable to that particular profile
users only.

What options which we have in Password Policies

●​ User passwords expire in: 30, 60, 90, 180, one year, never expires
●​ Enforce password history: 1 to 24 passwords remember or no password remember
●​ Minimum password length: 5 to 50 Characters
●​ Password complexity requirement
●​ Password question requirement
●​ Maximum invalid login attempts
●​ Lockout effective period
●​ Obscure secret answer for password resets​
●​ Require a minimum 1 day password lifetime​
●​ Don't immediately expire links in forgot password emails
 77

IP Ranges
How to Apply IP Ranges
There are 2 ways to apply IP Ranges
●​ From Setup : Setup => Security => Network Access
●​ From Profiles : Setup => Profile => Open Any Profile => Login IP Ranges

How IP Ranges works

Enter a valid IP address in the Start IP Address field and a higher IP address in the End IP Address
field. The start and end addresses define the range of allowable IP addresses from which users
can log in, including the start and end values.

Session Settings
How to Apply Session Settings
There are 2 ways to apply Session Settings
●​ From Setup : Setup => Security => Session Setting
●​ From Profiles : Setup => Profile => Open Any Profile => Session Setting

How Session Settings Works

Use the Session Settings screen to configure session security. You can configure settings such as
the session connection type, timeout restrictions, and IP address ranges to protect against
malicious attacks.

Login Hours
How to Apply Login Hours
We can apply login Hours from Profile only
●​ From Profiles : Setup => Profile => Open Any Profile => Login Hours

How Login Hours Works

Login Hours is used to restrict users to avoid logging into Salesforce during Non-Login hours. We
can specify the timing for each day during which the users are allowed to login.
 78

Object Level Security

Definition: Object Level security derives what type of access we have to the records of a
particular object.

Things to Remember
●​ We can Give obj level security through Profiles and Permission sets.
●​ We can give obj level security to Standard obj and Custom obj.
●​ We can give Read, Create, Edit, Delete, View All & Modify All access to profiles.
●​ Permission sets are just add ons to security provided.
●​ We can not remove already given security through Permission Sets.

Options Available for Object Level Security

●​ Create : User Can create records for the object
●​ Read : User can only read already created records
●​ Edit : User can edit the already created records
●​ Delete : User can delete created records
●​ View all : User can see the records (All Records)
●​ Modify all : User can Read, Edit, Delete all records
(Note: The “View All” and “Modify All” permissions ignore sharing rules and settings, allowing
administrators to quickly grant access to all records associated with a given object across the
organization.)

How to give Object Level Security Through Profiles

●​ Setup => Profiles => Select Profile => Object Setting => Select Object

Permission Sets
●​ Permission sets are used to provide extra access like if we have Create access through
profile for an obj then through permission sets we can give Extra access like delete.
●​ But we can not downgrade access through it.

How to Create Permission Set

●​ Setup => Permission Set => New => Give Name & API Name
 79

Observation for Object Level Security

●​ Create, Read, Edit, Delete : User can create new Records, User can Edit & Read previous
Records, and can delete his own records.
●​ Create, Read, Edit : Users can only create New Records, Can Read and Edit old records.
●​ Create, Read : Users can Create New Records, Read Old Records but can not Edit or
Delete Records.
●​ Read : Users can only Read old records but can not Create, Edit or Delete records.
●​ No Access : Users can not see the particular Object.
 80

Field Level Security

Definitions: Field-level security—or field permissions—control whether a user can see, edit, and
delete the value for a particular field on an object. They let you protect sensitive fields without
having to hide the whole object from users. Field permissions are also controlled in permission
sets and profiles.

Things to Remember
●​ Is use to show or hide the field.
●​ It has two levels of access i.e., Edit & Read.
●​ If given edit access then the user can enter data in the field while creating records or can
change value for old records.
●​ Read only : This defines that this field is only for read purposes.
●​ To hide any field we need to remove Edit & Read access.

Field level vs page layout vs field creation

●​ We can give Read access from P.L. but this PL is assigned to the multiple profiles at a time
●​ So changes on PL will apply for all profiles
●​ But from FLS we can give profile or user specific access.

How to give FLS

●​ From Profiles
●​ By using permission sets.
●​ While creating Field

Which Option we have while giving field level security

●​ Edit
●​ Read
 81

Observations
Object Level Security Field Level Security Output

Create, Read Read Record is non editable, but

while creating a new Record
field is read only.

Create, Edit, Read Read Users can create & Edit

records, but while creating
and editing that field is read
only.

Edit, Read Read Users can only edit old

records & That field is read
only.

Read Read Record & field both are Read

Only.

Read Read & Edit Record & field both are Read
Only.

Edit, Read Read & Edit Users can only edit old
records & That field is
editable.

Create Read & Edit Can not edit record and Field
value, but can create new
record and enter value in field

Create, Edit Read & Edit Can create new & Edit old
records, field is editable fr
new creation as well as old
record edit.

No Access Read & Edit Object is not visible to the

user.

Create, Edit No Access Users can see the object but

not the field.
 82

Record Level Security

Record Level Security is divided into following 4 Parts
●​ Organization Wide Default
●​ Sharing Rules
●​ Manual Sharing
●​ Role Hierarchies

Organization Wide Default

Definition: Organization-Wide Defaults, or OWDs, refer to the baseline access levels that are set
for your entire Salesforce organization. They determine the default access that the users have to
records they do not own. OWDs can be set as public (all users can access), private (only the
record owner and users who are above in the hierarchy can access), or read-only (all users can
read, but only the owner can edit).

Types of OWD
●​ Public OWDs
○​ With public OWDs, all users can access the records they do not own. Public OWDs
provide the most open access and are suitable only if you want to share all the
data with everyone in your organization.
●​ Private OWDs
○​ Private OWDs limit access to records to only the record owner and users higher in
the role. This is the most restrictive OWD, and it provides maximum data security.
Private OWDs are suitable when you want to guard sensitive data closely.

How to set OWDs

Go to Setup > Security > Sharing Settings

Sharing Rule Considerations

When you set private OWDs, consider whether you need additional sharing rules to grant extra
access. For example, you may set Account OWD to Private but create a sharing rule to provide
Read-Only access to certain product support representatives.
 83

How do OWDs affect user permissions and access?

●​ Public OWDs: Allow all users access to Read and Edit
●​ Public Read-Only OWDs: Allow all users Read-Only access
●​ Private OWDs: No default access is granted for users. Access must be granted through
sharing rules or role hierarchy.

How do OWDs interact with user permissions?

●​ The OWD is Public Read-Write, but the user has Read-Only permission: The user can only
read the records
●​ The OWD is Private, but the user has Edit permission: The user still cannot access the
records without a sharing rule
●​ The OWD is Read-Only, but the user has View All permission: The user can only read the
records

Example

Observations
 84

Object Level Security OWD Access on Record

Create, Read Private Can see only his records but

can not edit them but can
create new

Edit, Read Private Can see only his records &

Can edit them but not able to
create new

Create, Edit, Read Private Can only see his records &
also can create new and edit
old once

Create, Read Public Read Only Can see all users records &
Can create new records but
can not edit own records and
others too.

Edit, Read Public Read Only Can see all users records &
can see, edit own records,
can only see others but can't
create new

Create, Edit, Read Public Read Only Can see, edit, create new
records, but others users
records only he can read
them

Create, Read Public Read / Write Can see all users record and
own records as read only but
can create new

Edit, Read Public Read / Write Can see and edit all users
record but can not create new
records

Create, Edit, Read Public Read / Write Can see and edit all users
record but can also create
new records
 85

Role Hierarchy
Definition: Role hierarchy works together with sharing settings to determine the levels of access
users have to your Salesforce data. In most cases, the Salesforce hierarchical roles allow
employees access to data of all the users directly below them in the hierarchy.

Things to Remember
●​ Role Hierarchies can be used to extend the record access automatically so that a
Manager will always have access to the same data as his/her employees regardless of the
org-wide default settings.
●​ Role hierarchies don’t have to match your org chart exactly. Instead, each role in the
hierarchy should just represent a level of data access that a user or group of users needs.
●​ Depending on the organization’s sharing settings, roles can control the level of visibility
that users have into the organization’s data. Users at any given role level can view, edit,
and report on all data owned by or shared with users below them in the role hierarchy
unless the organization’s sharing model for an object specifies otherwise.
Note:
●​ “Grant Access Using Hierarchies” option is enabled for all objects and can only be
changed for custom objects.
●​ If the “Grant Access Using Hierarchies” option is disabled for a custom object then only
the record owner and users granted access by the org-wide defaults can access the
object’s records.
●​ However users such as with the “View All” and “Modify All” object permissions and the
“View All Data” and “Modify All Data” system permissions can still access records they do
not own.

How Role Hierarchy Looks Like

 86

Sharing Rules
Definition: Sharing rules in Salesforce are used to create automatic exceptions to the
Organization-Wide Default settings for the users who do not own the record.
They should be applied to the objects whose org-wide defaults are set to Public Read-only or
Private because sharing rules can only extend the access, they cannot restrict the access
provided by Organization-wide defaults. We can not share records to specific users by using the
sharing rule.

Types Of Sharing Rules In Salesforce

There are 2 types of Sharing Rules in Salesforce based on which records are to be shared:
●​ Owner Based
○​ Owner-based shares the records owned by certain users. Owners can be
identified through public groups, roles and roles, and subordinates.
●​ Criteria Based
○​ Criteria-based shares the records that meet certain criteria.

Things to Remember
●​ Share which records?
○​ This identifies the records that need to be shared. They can be categorized based
on the owner of the records or the criteria that the records met.
●​ With whom do the records need to be shared?
○​ Records can be shared with public groups, roles, and roles & subordinates.
●​ What kind of access should be provided for these records?
○​ The users with whom the records are shared should have Read-Only or
Read/Write access is decided by this question.
Note:
●​ As they cannot restrict access this is the reason it gives Read-Only and Read/Write as
access parameters in sharing rules.
●​ They work best when they are defined for a particular group of users that can be
determined or predicted in advance rather than a set of users that frequently changes.

Limits
A general sharing rules limit that counts for all sharing rules, including criteria-based. The default
limit is 300 and can be increased to a maximum of 500 through a Support case.
 87

Manual Sharing
Definition: Manual Sharing is only available on individual records, it is not available for all records
of a certain object. Only applicable on records that have Private or Public Read Only access in
OWD. When setting Automatic and Manual Sharing users and admins should define if the security
should be extended to related records.

Things to Remember
●​ Sometimes, granting access to one record includes access to all its associated records.
For example, if you grant another user access to an account, the user automatically has
access to all the opportunities and cases associated with that account.
●​ To grant access to a record, you must be one of the following users.
○​ The record owner
○​ A user in a role above the owner in the hierarchy (if your organization’s sharing
settings control access through hierarchies)
○​ Any user granted Full Access to the record
○​ An administrator
●​ If a user transfers ownership of a record, Salesforce deletes any manual shares created
by the original record owner, which can cause users to lose access. When account
ownership is transferred, manual shares created by the original account owner on child
records, such as opportunities and cases, are also deleted.
●​ Apex-managed shares aren’t editable.
●​ Admins can’t modify the share access of record owners.
●​ Personal groups aren’t available in Lightning Experience.
●​ When navigating through a Sharing Hierarchy table, JAWS and NVDA screen readers
don’t announce that there’s a link inside of a table cell, and they don’t provide a keyboard
shortcut to open the link. Use another form of input or assistive technology instead.
●​ With more than 2,000 users, roles, and groups, if your query doesn’t match any items in a
particular category, that category doesn’t show up in the Search dropdown menu. For
example, if none of your group names contain the string CEO, after searching for CEO, the
Groups option no longer appears in the dropdown. If you enter a new search term, all
categories are still searched even if they don’t appear in the list. You can repopulate the
dropdown by clearing your search terms and pressing Find.
●​ You can't grant access to unauthenticated guest users with manual sharing.
 88

●​ In Lightning Experience, both sharing and the Sharing Hierarchy action are available for
custom objects and these standard objects.
○​ Account
○​ Action Plan
○​ Action Plan Template
○​ Appointment Invitation
○​ Appointment Bundle Configuration
○​ Appointment Bundle Policy Service Territories
○​ Asset
○​ Campaign
○​ Case
○​ Contact
○​ Engagement Interaction
○​ Expense
○​ Expense Report
○​ Job Profile
○​ Lead
○​ Maintenance Plan
○​ Maintenance Work Rule
○​ Opportunity
○​ Product Item
○​ Product Request
○​ Product Service Campaign
○​ Product Transfer
○​ Recordset Filter Criteria
○​ Return Order
○​ Serialized Product
○​ Service Appointment
○​ Service Contract
○​ Service Crew
○​ Service Resource
○​ Service Territory
○​ Shift
○​ Shift Pattern
○​ Survey
○​ Survey Invitation
○​ Time Sheet
○​ Travel Mode
○​ Video Call
○​ Warranty Term
 89

Security Model Questions

Q. What is Sharing and Security in Salesforce?
Ans: Data Security is important because you need to control what a user or group of users can
see in the org or app.
● Salesforce provides a layered sharing model.
● You can easily assign different data sets to different groups of users.
● You can control access to your whole org, any specific object, fields, and records.

Q. Sharing & Security Model

Ans: Organization Level Security
● Object Level Security
● Field Level Security
● Record Level Security

Q. Organization Level Security

Ans: Maintain a list of authorized users
● Set password policies
● Limit login to certain hours and locations
○ Limit IP Addresses from which users can log in
○ Limit the times at which users can log in

Q. Object Level Security

Ans: You can control object level permissions for both Standard and Custom Objects.
● You can set permissions for a particular object.
● You can give permissions to view, create, edit and delete any records of that object.
● You can control object permissions using profiles and permission sets.
 90

Q. How many ways we can share a record?

Ans: With the help of the given below methods we can share records in Salesforce:
Role hierarchy:
Whenever a user is added to a role, the user above the current user in the hierarchy of roles will
have access to reading the records and inheriting the permissions. Follow the steps for role
hierarchy: Go to Setup → find manage users’ → roles → set up roles → click on ‘add role’ → provide
name and click on save.
OWD:
OWD(Organization-Wide Defaults) allows you to give permissions to the organization-wide and to
define baseline setting for the organization. It is also helpful in defining the user’s accessibility
level to the user where a user can see other user’s records. OWD settings can be Public Read
Only, Private, Public Read, and Write. Follow the steps for OWD: Go to Setup → find the Security
Controls → click on ‘sharing settings’ → click on ‘Edit.
Manual sharing:
Manual sharing is sharing a single record/file to a single user or group of users through manual
access. We can see a button for manual sharing on the detail page of the record and it can be
seen only when the OWD setting is private.
Criteria based sharing rules:
If we want to share records based on conditions such as share records with a group of users with
the criteria of the country is India. Follow the steps for criteria-based sharing rules: Go to Setup →
security controls → sharing settings → select the object and provide name and conditions then
click on save.
Apex sharing:
Sharing object is available for each and every object in Salesforce. For example, the Account
object’s share object is AccountShare. By using Apex, if we want to share the records then we
have to create a record to the shared object.

Q. Field Level Security

Ans: You can restrict access to certain fields in Salesforce, even if user has object level access.
● You can make a field visible to a particular user and can hide that from another user.
● You can give Read or Edit permission to a field, if you don’t give both then that field will not be
visible.
● Field Level Security can be controlled using Profiles and Permission Sets.
Q. What is Profile?
 91

Ans: A profile is a collection of settings and permissions.

● Profile settings determine which data the user can see, and permissions determine what the
user can do with that data.
● A profile can be assigned to many users, but a user can have only one profile at a time.

Q. What can be controlled through a Profile?

Ans: Assigned App & Assigned Connected Apps
● Object Settings
● App Permissions
● Apex Class & VF Page Access
● External Data Source Access
● Named Credential Access
● Flow Access
● Custom Permissions & Custom Metadata Type
● Custom Setting Definitions
● System Permissions

Q. Enhanced Profile User Interface?

Ans: You can switch to Enhanced Profile User Interface through Setup > User Management
Settings.
● If enabled then you can Browse, search and modify settings and permissions in a profile
through a streamlined user interface.

Q. What is Permission Set?

Ans: A permission set is a collection of settings and permissions that give user access to various
tools and functions.
● Permission sets extend users functional access without changing their profile.
● Through Permission sets permission can be granted and any time it can be taken away as well.
● Users can have only one profile, but they can have multiple permission sets assigned.
 92

Q. What can be addon through a Permission Set?

Ans: Assigned App & Assigned Connected Apps
● Object Settings
● App Permissions
● Apex Class & VF Page Access
● External Data Source Access
● Named Credential Access
● Flow Access
● Custom Permissions & Custom Metadata Type
● Custom Setting Definitions
● System Permissions

Q. What is Permission Set Group?

Ans: Permission Set group bundles different permission sets together based on a persona.
● A permission set group includes all the permissions available in the permission sets.
● One permission set can be included in more than one permission set groups.
● A user can be assigned one or more Permission Set Groups.
● Also we can assign Permission Set and Permission Set Groups together to users.

Q. What is MUTE in Permission Set Group?

Ans: One can mute some permissions in Permission Set Groups so that they won’t be given to
the user.
● If you mute particular permission in Permission Set Group then it won’t impact individual
Permission Set, they remain intact.
● You can anytime unmute the permissions in permission set group.

Q. How many Profiles can be assigned to a user?

Ans: One
 93

Q. How many Permission Sets can be assigned to a user?

Ans: Zero or Any number of Permission Sets

Q. Record Level Security

Ans: You can restrict access to records for users, even if user has object level permissions.
● For example, a user can view his own records but not others.
● You can manage Record Level Access in following ways:
○ Organization-wide defaults
○ Role hierarchies
○ Sharing rules
○ Manual sharing

Q. What is the use of writing sharing rules? Can you use sharing rules to restrict data access?
Ans: Sharing rules are written to give edit access (public read and write) or public read only
access to certain individuals in Salesforce org. A classic example is when:- only your managers or
superiors need to be given extra credentials to your records in objects as compared to your
peers.
By default, all users in your organization will have organization-wide-default sharing settings of
eitherPublic Read Only or Private. To give access to more records, which users do not own, we
write sharing rules. Example: Sharing rules are used to extend sharing access to users in public
groups or roles. Hence, sharing rules are not as strict as organization-wide default settings. They
allow greater access for those users. As far as the second part of the question is concerned, the
answer is no. We cannot use sharing rules to restrict data access. It is only used for allowing
greater access to records.

Q. What is Role Hierarchy?

Ans: Role Hierarchy gives access for users higher in the hierarchy.
● That user can access all records owned by the users below them in the hierarchy.
● Each role in the hierarchy should represent a level of data access that a user or group of user
needs.
● You can assign users to role through Role Hierarchy or User detail page.
 94

Q. What is OWD?
Ans: It specifies the default level of access of records.
● Org-wide sharing setting lock down the data to the most restrictive level.
● Here you have three access level:
○ Private
○ Public Read-Only
○ Public Read/Write
● You can use other Record Level security and sharing tools to open up the sharing of records.
Q. What is Grant Access Using Hierarchies?
Ans: This feature controls whether the user who is above in the role hierarchy can access the
records of subordinates or not.
● It is checked by default for all standard object.
● We can control it for custom objects.

Q. What is Sharing Rule?

Ans: Sharing Rules are exceptions to Org-Wide defaults.
● Through sharing rules you can share records to a group of users or to roles, roles &
subordinates.
● So that, they can get access to the records they don’t own or can’t manually see.

Q. Two ways to create Sharing Rule?

Ans: Owner Based Sharing
● Criteria Based Sharing

Q. What is Manual Sharing?

Ans: Manual Sharing allows owners of particular records to share them with another users.
● Manual sharing is not automated like Org-wide defaults, Role hierarchy or sharing rules.
● It can be useful in some situation where you manually want to share a record with another user.
 95

Q. What is Public Group?

Ans: A group of users
● You can add or remove users from one public group any time.
● Following can be member of a public group:
○ Public Group
○ Roles
○ Roles and Subordinates
○ Users
● You can also control Grant Access using Hierarchies while creating public group.

Q. Object does not have EDIT permission but OWD is Public Read/Write?
Ans: User won’t be able to edit the record.

Q. View All & Modify All?

Ans: Grant access to all records of the object regardless of the sharing and security settings.
● View all and Modify all permissions ignore the sharing model, roles and sharing rules.

Q. Explain Guest users?

Ans: Guest users are the users who do not have user accounts in our organization. They are also
known as unauthorized users as they do not have to log in. We can make the pages accessible.
Unauthorized users can create or edit the records.
Generally, we have various limitations and considerations for assessing. Yet, we can use this
feature for solving use cases, and we do it financially because the guest user licenses are free.

Q. What is Setup Audit Trails?

Ans: Setup Audit Trail shows a list of changes done by users in the org in different components.
● One can download past 6 months changes.
 96

Q. Different ways to make a field required?

Ans: Field itself
● Page Layout
● Validation Rule
● Trigger

Q. Different ways to make a field read only?

Ans: FLS (Field Level Security)
● Page Layout
● Validation Rule
● Trigger

Q. What is Duplicate Rule & Matching Rule?

Ans: Duplicate Rule : Prevent creation of duplicate records. It shows either warning or block
record creation and updation in case of duplicates. We can create reports on duplicate records as
well.
Matching Rule : Here we need to set the criteria for duplicate check.
 97

Reports and Dashboards

Reports
What is Report?
●​ Report is a list of records related to objects that meet the criteria defined.
●​ One can filter, Group and do maths on reports.
●​ One can display reports graphically through charts.
●​ Every report is stored in a folder.
●​ Report folder determines how one can access reports to View, Edit or Manage.
●​ Report folders can be Public, Hidden or Shared.

Report Folder
●​ Every report is stored in the folder.
●​ Report folder determines how one can access reports to View, Edit or Manage.
●​ Report Folders can be public, Hidden or Shared.
●​ We can control access to the contents of the folder based on Roles, Permissions, Public
Groups, Territories, and License Type.

Dashboard
What is a Dashboard?
●​ Dashboard is visual Representation of Reports.
●​ Source of Dashboard is Report.
●​ You can place one report in multiple Dashboards components on a single dashboard.
●​ Having Multiple Reports on a single dashboard page makes it a powerful Visual Display
tool.

Dashboard Folder
●​ Like reports, dashboards are also stored in the folder.
●​ Dashboard folders can control who has access to its content.
●​ If one has access to the folder then only one can access its dashboards.
●​ However, to view the dashboard components, one needs access to underlying reports as
well.
 98

Things to Remember about Dashboard

●​ Each Dashboard has a running user.
●​ Running user’s security settings determine which data to display in the dashboard.
●​ If the running user is a specific user, then all dashboard viewers see the data based on
the security setting of that user, regardless of their own security settings.
●​ Dynamic Dashboards are those for which a running user is always logged in user. Here,
each user views the dashboard.

Custom Report Types in Salesforce

Setup => Feature Setting => Analytics => Reports and Dashboards => Report Type
●​ Why we create Custom Report Type
○​ Choose which objects to display to users creating and customizing reports
○​ Define the relationships between objects displayed to users creating and
customizing reports
○​ Select which objects' fields can be used as columns in reports
●​ Step 1
○​ We have to Provide Primary object i.e., Main Object, like if we need to create a
Report Type “Contacts with Opportunities” then Contact is a primary Object.
○​ In the Primary object list we can see the All Standard and Custom Objects.
○​ Then we have to give a Label, Report Type Name and Description.
○​ Then we have to store it in Category. Category is like Administrative, Developers
or Other. We can see the Category while creating the Report.
●​ Step 2
○​ Here in Step 2 we need to select the Secondary Object.
○​ To Choose a secondary object we must have at least a lookup or MD relationship
between Primary and Secondary Object.
○​ We have 2 options related to the Primary and Secondary Object.
■​ Each ‘A’ record must have at Least one related ‘B’ Record: That means we
can get the records which are common. Example if we are creating the
Accounts with Opportunities Report Type then by using this option we can
get only records like Account having opportunities.
■​ ‘A’ records may or may not have related ‘B’ records: That means we can
get those Accounts which are having Opportunities or not having
associated opportunities.
○​ We can add a 3rd Object also.
 99

●​ Step 3
○​ In step 3 we can review and edit fields which are available to record type by
clicking on edit layout.
Report Formats or Types of Reports (Using Salesforce Lightning)
●​ Tabular Reports
○​ Tabular Reports are simple Table Like structured reports.
○​ We can not add charts for Tabular Report.

Above is an example of what a Tabular Report looks like.

●​ Summary Report
○​ If we Group Tabular Report by Rows then it is called a Summary Report.
○​ We can add charts for Summary Report.

●​ Matrix Reports
○​ If we Group Tabular Reports by Rows and Columns then it is called a Matrix
Report.
○​ We can add charts for the Matrix Report.

●​ To add Reports to the dashboard, go to dashboard and select Report first then we can
create a dashboard.
 100

Global Quick Actions

Definition: You can add global quick actions to almost any page that supports actions. Use global
actions to let users log call details, create or update records, or send email, all without leaving the
page they’re on. Global create actions enable users to create object records, but the new record
has no direct relationship with other records.

Things to Remember
●​ Global actions live on a special layout of their own, known as the global publisher layout.
The layout isn’t associated with an object, and it populates the global actions menu in

Lightning Experience. Users can access the global actions menu by clicking Global
Actions menu icon in the Salesforce header.
●​ If you delete an action, the action is removed from all layouts that it’s assigned to.
●​ Actions to create records for an object that is the detail object in a master-detail
relationship must be object-specific, not global.
●​ Supported Objects for Create Actions
○​ Account
○​ Asset
○​ Badge
○​ Campaign
○​ Case
○​ Contact
○​ Contract
○​ Custom objects
○​ Event (without invitees)
○​ Goal
○​ Group
○​ Knowledge object
○​ Lead
○​ Note
○​ Opportunity
○​ Orders
○​ Person Account
○​ Question
○​ Reward
○​ Task
○​ Work Order
 101

●​ If you create an action on a detail object in a master-detail relationship, the action’s target
object can’t be a different detail object of the same master.
○​ For example, master object A has two detail objects, B and C. You can create
actions on object A with B or C as the target object. However, when creating an
action on object B, the target object can’t be object C because B and C have the
same master. To create an action on B with C as the target, you can do one of the
following:
■​ Change the relationship between B and C to master-detail so that A is the
master of B, and B is the master of C.
■​ Change the relationship between C and A to a lookup relationship. A is still
the master of B with this option, so you can’t create a quick action on B
with a target object of A.

How to Create Global Action

Setup => User Interface => Global Action => Global Action =>Click on New Action
●​ First Provide the Action Type, Action Type can be:
○​ Create a Record
○​ Send Email
○​ Log a Call
○​ Custom Visualforce Page
○​ Custom Canvas
○​ Lightning Component
○​ Lightning Web Component
●​ Then we need to choose an Object
●​ Then Provide Label, Success Message and save it.
●​ After saving we have to choose which fields we need to select for creating the record.

How to Add Global Action on page

Setup => User Interface => Global Action => Publisher Layout => Edit => Go to Mobile & Lightning
Actions => Add it to layout
 102

Object Specific Actions

Object Specific actions are visible at the top of the records. It is a type of Global Quick Action.

How to Create Object Specific Action

Setup => Object Manager => Select an Object => Go to Button Links and Actions => New Action

After Creating an Action we need to add it to the Page Layout.

 103

Scenario Based Questions

Q. Name a few global variables which are used in formula and validation rules.
Ans: $User, $Organization, $Setup, $Objecttype, $Action etc.

Q. Is there any special permission available to edit read only fields. Please explain.
Ans: Yes. There is a system permission named ‘Edit Read Only Fields’ which allows to edit read
only field values. For System Administrator profile, this is enabled by default.

Q. What are the differences between Object-specific action and global actions?
Ans: Both types can create records, but only object-specific actions can update records.
Object-specific create actions create records that are automatically associated with the
current record. A record created by a global create action has no relationship with other
Records.

Q. Mention one impact point to check before deleting a role from the org.
Ans: Before deleting a role, we should check whether the role has been used in any sharing
rule. If the role is deleted, the sharing rule is also deleted.

Q. Let’s say I create two accounts a1 and a2. Now I make a2 as the parent of a1. Now what will
happen if I try to make a1 parent of a2.
Ans: The error ‘A parent account can’t be the child of an account it’s already a parent of’ will be
shown.

Q. How do you pass the current record id to a screen flow? Also is it possible to send the
entire record?
Ans: In order to pass current record Id, we need to declare a variable of name ‘recordId’ of type
text and select the option ‘Available for Input’. To pass the entire record, we can create a variable
of name ‘recordId’ of type Record and select the object type as that particular SObject.
 104

Q. How do you check your org is in which release.

Ans: From Setup, go to Company Information and copy the instance Id. Now go to
status.salesforce.com and search with the same instance id to get the details.

Q. What is a big object? Give an example of a standard big object.

Ans: A big object can store a massive amount of data from other objects and even from external
objects. Clients and external systems use a standard set of APIs to access bi object data. A big
object provides consistent performance, whether you have 1 million records, 100 million, or even 1
billion. Example of a standard big object is FieldHistoryArchive.

Q. Is it possible to use formula fields in rollup summary calculation which is referring to

another object?
Ans: No. In order to get the value from the formula field, we need to create some automation to
copy the data to a new field and use that field in the roll up summary calculation.

Q. Suppose there is a custom field which has a default value but not added to the page layout.
Now, if you clone a record from the UI, what would be the value of the field in the new record?
Ans: The value would be the default value set at the field level, not the value which was
populated in the previous record.

Q. What is the consideration while deleting an approval process?

Ans: Approval processes can be deactivated and deleted. If there are already records in pending
status, an approval process can be deactivated but not deleted. In order to delete an approval
process, we need to ensure there are no records in the org which is locked in the approval
process else an error will be encountered

Q. What happens during Lead merging?

Ans: We can select up to 3 leads during merging. Those are identified as duplicates based on the
duplicate rule condition on the org. One of the lead is considered as a Master record and the
read only and hidden field values are retained from that lead. Once it is merged, the resultant
record is a single lead record and the other two records are deleted.
 105

Q. What is Apex Hammer?

Ans: Before each major service upgrade, Salesforce runs all Apex tests on your behalf through a
process called Apex Hammer. This is run across all the orgs.

Q. How do you convert 15 digit record Id to 18 digit Id in formula and validation rule?
Ans: Using CASESAFEID() function.

Q. Is it possible to hard delete records using a data loader?

Ans: Yes. We need to enable a system permission ‘Bulk API Hard Delete’ for the user in order to
do hard delete. Also, we need to select the Bulk API option in the data loader before the deletion.

Q. Is it possible to show validation errors in screen flow?

Ans: Yes. We can show validation error messages in screen flow for certain components using
the Validate Input option. In this option, the condition which is provided must be false for the
validation rule to fire which is in contrast with the standard/contrast validation rules.

Q. You have created a custom object. While creating a report on the object, you are not
getting the option to select the object in the report builder. What could be the issue?
Ans: Check if the Allow Reports checkbox is enabled in the object detail page.

Q. What are the possible statuses of a permission set group?

Ans:
●​ Updated. The group is current.
●​ Outdated. The group requires recalculation.
●​ Updating. The group is in recalculation mode.
●​ Failed. The group recalculation failed.

Q. How can we enable email approval responses? Mention a few response keywords which
will approve/reject the request.
Ans: From Setup -> Process Automation Settings, we can enable the settings. Approve,
Yes, Reject, No etc. are few of the responses.
 106

Q. You are not getting an option to create list custom settings. Which setting needs to be
enabled?
Ans: From Setup -> Schema Settings -> Enable Manage list custom settings type.

Q. Once a lead is converted it is not visible anymore in the UI. Is there any permission
available to view converted leads?
Ans: Yes. There is app permission, View and Edit Converted Leads.

Q. You are trying to convert a master detail relationship field to lookup relationship. But you
are not able to see the change field type button. What could be the reason?
Ans: Check there should be no roll up summary field present in the parent object. Also, if there is
any deleted roll up field present in recycle bin that needs to be erased as well.

Q. One of the users in your org is not able to create campaigns. You checked the profile/
permission sets and ensured that he has access to create campaigns. What could be the
reason?
Ans: Check if the Marketing User checkbox is selected in the user detail page of the user.

Q. What happens when you try to delete a public group?

Ans: If the public group has been used in any sharing rule and associated with any records in the
context of sharing, the associated records appear. Now, an option is given to delete the public
group as well as the sharing of all the records.

Q. What happens when you try to delete a queue?

Ans: If the queue is associated with any records or sharing rules, the references are displayed.
The queue cannot be deleted unless the references are removed.

Q. Is it possible to schedule a dynamic dashboard in Salesforce?

Ans: No, it is not possible to schedule a dynamic dashboard in Salesforce.

Q. Is it possible to write a validation rule on record delete?

Ans: No, only in insert and update events you can write validation rules.
 107

Q. Difference between formula field and rollup summary in Salesforce ?

Ans: Rollup Summary field is used to calculate the sum of a field in the child object record.
●​ It is compulsory to be in a Master-Detail relationship to use the rollup summary.
●​ A rollup summary field is always created on Master record. (Parent to Child).For example.
You have an Account and multiple Contacts under that Account. Each of the Contacts
have a number field on it say Contacted People. Now on the Account you can create a
Rollup summary to check the Number of Contacted People via all your contacts.
●​ Where else a formula field is mostly used for calculations within a certain object. And it is
a child to Parent.

Q. Is there any standard object which also acts as a junction object ?

Ans: Yes, there are some standard objects which act as a junction object. For Example, Standard
object OpportunityContactRole acts as junction object between Opportunity and Contact objects.

Q. What is the default DateTime format of Salesforce ?

Ans: DateTime:
●​ Salesforce stores all DateTimes in Coordinated Universal Time (UTC) format.
●​ Remember that dateTime field values are stored as Coordinated Universal Time (UTC).
●​ When one of these values is returned in the Salesforce application, it is automatically
adjusted for the timezone specified in your organization preferences.
●​ Your application may need to handle this conversion.
Date:
●​ Date fields contain no time information and completely ignore timezones.
●​ Whatever date you specify when you set it will be the date every user sees, with any time
and zone information being ignored.

Q. How to insert null values into Dataloader ?

Ans: Go to data loader -> setting -> check Is null values checkbox.

Q. Maximum batch size of data loader?

Ans: 200
 108

As we conclude this Salesforce Admin module, it's important to reflect on the simplicity
and power that this foundation brings to the entire Salesforce ecosystem. The Admin
module isn’t just about creating fields or configuring profiles — it’s about understanding
the logic that drives business processes and user experience.

For testers, this knowledge is not optional — it is essential. A clear understanding of the
admin configurations helps identify potential issues early, test with greater accuracy, and
ensure that the system behaves as expected under various user roles and conditions.
From validation rules and record-level security to automation — every test scenario
starts with understanding how the system is configured.

To beginners, this is your gateway. Grasping these fundamentals will give you
confidence to navigate and contribute meaningfully to Salesforce projects.

To the experienced, let this be a reminder that mastering the basics leads to excellence
in more advanced areas. No matter how far you grow, the Admin layer remains the
backbone of every successful implementation and every well-designed test strategy.

Let’s carry this knowledge forward — not just to test better, but to build with purpose,
think with clarity, and grow continuously as Salesforce professionals.

Thank You

-​ Prasad Kadam
-​ www.linkedin.com/in/prasad-arun-kadam