Salesforce Phase-2

Workflow Rules:
===============
Workflow Rules are used to Automate the Business Processes inside the Organization.
i.e. Instead of performing all the operations manually as part of the Organization
Policies, we can make certain operations automated with the help of Workflow Rules.
Note:
Each Workflow Rule should be associated with an Object. (i.e. Workflow To
Object we have One-One Association). But, an object can have one or more Workflow
Rules.
Note:
Each Workflow Rule Contains 2 Parts.
1. Event / Criteria / Evaluation / Criteria:

Event Describes, When the Workflow Rule should get fired.
Salesforce provides the below 3 Events for the Workflow Rule,

from Which we can select only one.
1. Created:
This Event will fire the Workflow Rule, Once a New
Record has been Created inside the Object.
2. Created, and EveryTime it is Edited:

This Event will fire the Workflow Rule Once a New
Record has been Created inside the Object, and Once an Existing Record has been
Updated inside the Object. (i.e. on After Insert, After Update).
3. Created, and AnyTime it is Edited and Meeting Subsequent

Criteria
This Event will fire the Workflow Rule, Once a New
Record has been Created inside the Object, and Once an Existing Record has been
updated, which meets the specified conditions.
2. Actions:
Once the Workflow Rule has been fired, then it can perform one or
more actions. Workflow supports the below 4 types of Actions.
1. Email Alerts:
By using this Action, we can send the Email
Notifications to one or more users with a Pre-existing Email Template.
Pre-Requisite: We should have an Email Template with

the Required Subject and with the Required Content.
2. Update a Field:
By using this action, we can update a field value by
assigning the New Value through Workflow Rule.
Each Field update action allows us to update only one

field value.
To update the multiple fields, we have to add

multiple field update actions. Which will make the Workflow Rule complex. Which
leads to the Performance issues. We can solve the problem, with the help of
"Triggers" through Apex Programming.
3. Assign a Task:
By using this action, we an assign a Task record to
the user. Which reminds the user regarding an operation with a Pop-up alert.
4. Send an Outbound Message:

By using this Action, we can send an XML based SOAP
Message to the External System to have the Integration with Salesforce Application.
Types of Workflow Rules:

------------------------
Based on Executing the Actions, Workflow Rules has been Categorized into 2
Types.
1. Immediate Action Workflow Rules:

In this approach, the Workflow Rule will fire the Actions
Immediately as soon as the Criteria has been met.
2. Time-Dependent Action Workflow Rules (Time Triggers):

In this Approach, We can fire the Actions based on the specified
scheduled Time.
Till the Schedule Time is up, the Actions will get awaited inside
the "Workflow Queue".
Navigation:
Setup --> Build --> Create --> Workflow & Approvals --> Workflow Rules.
ICICI Bank Credit Card:
Bill Generation Date: 1st of Month

Due Date : 20th of Month.
10 Days Before the Due Date (10th) ---> SMS,

Email 40
Email 40
Email 40
Email 40
Email
1 Days After the Due Date (21th) ---> Block
the Card.
Queue --> Workflow Queue.
Hyderabad --> Bangalore

Time : @ 10.00 PM IST
Ameerpet.
6 Hours Before the Travel Time : (4.00 PM IST) : SMS, Email
(Bus Number, Contact Number)
2 Hours Before the Travel Time : (8.00 PM IST) : SMS, Email

(Bus
Tracking Link)
30 Minutes Before of Travel Time : 9.30 PM IST : SMS,

Email
10.00
PM IST ......
7.00
AM IST.
After 2 Hours of Travel : 9.00 AM IST : SMS, Email,

(FeedBack)
UseCase:
========
Configure a Workflow Rule on Hiring Manager Object, to Notify the HR Person
Upon Creating a New Hiring Manager Record.
Step 1: We need to Create an Email Template with the required Subject and
Content, to be used to send the Notification.
Step 2: Create a Workflow Rule to Send the Automated Email Alerts.
Object Name : Hiring Manager

Event / Evaluation Criteria : Created.
Rule Condition:
HiringManager:EmailID != Null
Action Type: Immediate Action.

Action Name : Email Alert.
Email Template:
---------------
Email Subject:
Congratulations {!Hiring_Manager__C.Name} ..!! Your HR Record has been
Created
Successfully.
Email Content:
Dear {!Hiring_Manager__C.Name},
Welcome On-Board. Thanks for joining our Organization.
From Today onward you are also part of our HR Department.
We are pleased to Inform you, that your HR Record has been Created
Successfully.
Here are your Details..
Hiring Manager ID : {!Hiring_Manager__C.ID}

Hiring Manager Name : {!Hiring_Manager__C.Name}
Contact Number : {!Hiring_Manager__C.Contact_Number__C}
Email Address: {!Hiring_Manager__C.Email_id__C}
Location Name : {!Hiring_Manager__C.Location__C}
Designation : {!Hiring_Manager__C.Designation__C}
Please contact on the below address, if any Queries.
***This is a System-Generated Email. Please Do Not Reply.
Thanks & Regards,

Talent Acquisition Team,
Axis Bank Inc.,
Contact us: +1 (800) 787-7777
Email us: [email protected]
Visit us: http://careers.axisbank.com
Testing Process:
----------------
1. Click on the Hiring Managers Tab.
2. Click on "New" button.
3. Enter the Details inside the Fields.
4. Click on "Save" button.
Observation:
It will fire the Workflow Rule and will send the Email Alert to the HR Person
Email Id. And along with the CC Copy to the Email Addresses.
UseCase:
========
Configure a Workflow Rule, to Send the Email Alerts to the HR Person Upon
Creating a New Position Record and Upon Updating the Existing Position Record
Details.
Object Name: Position Object

Event / Evaluation Criteria : Created and EveryTime it is Edited.
Rule Condition:
Position : HR Email ID != Null
Action Type: Immediate Action
Recipient Type : Email Field.
Pre-Requisite: We should have an Email Template with the required Subject and
Content.
Assignments:
============
1. Configure a Workflow Rule on Lead Object, to Notify the Lead Person upon
Creating a New Lead Record inside the Object.
Note: Include the Lead Record Details inside the Email Template.
(Event / Criteria: Created)
2. Configure a Workflow Rule to Notify the Account Owner, upon Creating a New
Account Record inside the Object which contains the "Banking Industry"
and "Hot Rating".
(Event / Evaluation Criteria: Created)
3. Configure a Workflow Rule on the Case Object, to Notify the Case Owner
Upon
Creating / Editing a "High Priority New Case Record".
(Event / Evaluation Criteria : Created and EveryTime it is Edited)
4. Create a Workflow Rule on the Candidate Object, to Notify the Candidate

Upon Submitting the Candidature for the Position.
(Event / Evaluation Criteria : Created)
Field Updates:
==============
Field Update actions are used to Update the fields inside the records by
assigning the New Values for the fields.
Each Field Update action is used to update only One field.
To update the multiple fields, we have to add multiple field update actions.
Which makes the Workflow Rule Complex, and will leads to the performance issues.
While updating the fields we have the below 2 Cases.
1. Simple Field Updates:

In this approach, we can Create the Workflow Rule on an object.
And through the Workflow Rule we can update the fields in the Same object.
2. Cross-Object Field Updates:

In this approach, we can Create a Workflow Rule on an Object, and
through the Workflow Rule we can update the fields on the Other Related Object.
Simple Field Update:

====================
UseCase:
--------
Configure a Workflow Rule on the Account Object, to Synchronize the Billing
Address information into Shipping Address fields upon selecting thebCheckbox "Both
Addresses are same".
Object Name: Account Object.

Event / Evaluation Criteria: Created, and EveryTime it is Edited.
Rule Condition:
Account:Both Addresses Are Same Checkbox == TRUE
Action Name : Field Update
Source Field Target Field

--------------------------------------
BillingStreet --> ShippingStreet
BillingCity --> ShippingCity
BillingState --> ShippingState
BillingCountry --> ShippingCountry
BillingPostalCode --> ShippingPostalCode
Pre-Requisite:
We have to Create a Checkbox Field "Both Addresses Are Same?".
Time-Dependent Actions:
=======================
By using this feature, We can Create the Workflow Rules on the object, Which will
fire the Actions based on the Specified Time Period.
Till the Scheduled Time is up, all the Time-Dependent Actions will get awaited
inside the "Workflow Queue". Once the Scheduled Time is up, it will fire the
actions from the Workflow Queue, and the Entry will get removed from the Queue.
Note:
Time-Dependent Actions can't be Applicable on the Workflow Criteria "Created
and EveryTime it is Edited".
Note:
A Workflow Rule can have both Immediate Actions and Time-Dependent Actions.
Limits:
1. A Workflow Rule can have max. of 10 Time-Triggers.
2. Each Time-Trigger can fire max. of 40 Immediate Actions.
UseCase:
========
Configure a Workflow Rule on the Position Object, to Notify the Hiring
Manager Upon Assigning a New Position Record to the HR Person.
And Send the Reminder Alerts to the HR Person as below.
10 Days Before the MileStone Date ---> Email Alert
1 Days After the MileStone Date ---> Change the Status to Closed.
Analysis:
Object Name: Position Object
Event / Evaluation Criteria : Created
Rule Conditions:
1. Position:MileStoneDate != Null
2. Position:HR Email ID != Null
3. Position:Position Status != 'Closed'
Action Type: Immediate Actions.
Action Name: Email Alert to HR Person.
Action Type: Time-Dependent Actions.

Action Name : Email Alerts to HR Person.
Time Triggers:
Pre-Requisite: We should have an Email Template with the required Subject and
Content.
Testing Process:
1. Create a New Position Record inside the Object.
Observation:
If the Specified Conditions has met, then it will fire the Immediate
Actions.
And it will prepare the Time-Dependent Actions and will store inside
the Workflow Queue.
2. Monitor the Workflow Queue.
Setup --> Monitor --> Time-Based Workflow.
Note:
1. We can Remove the Time-Dependent Actions from the Workflow Queue by using
Delete Button.
2. Upon removing the Record from the Object, the corresponding Time-Dependent
Actions inside the Workflow Queue will get removed Automatically from
the Queue.
If we re-store the record back to the actual object, then it won't

restore the Time-Dependent Actions into the Workflow Queue.
Cross-Object Field Updates:

===========================
-----------------------------------------------------------------------------------
Process Builder:
================
-----------------------------------------------------------------------------------
Drawbacks of Workflow:
1. Workflow Rules supports the below 4 Actions to Automate.
1. We can Send Email Alerts.
2. We can Update the Fields.
3. We can Assign a Task to User.
4. We can send an Outbound Message.
2. Workflow Doesn't have the Actions to Insert a Record.
3. Workflow Doesn't have the Actions to Delete and UnDelete the Records.
4. Workflow Doesn't Support the DML Operations.
5. We can perform the Field Update actions as below.
1. We can add max. of 40 Field Update Actions inside a Workflow Rule.
2. While Performing the Cross-Object Field Updates, we have the below

limitations.
1. We can update the fields from "Child To Parent ": object which
are associated with "Master-Detail Association".
2. If the Objects are associated with "Lookup", Workflow won't

support.
3. We can't update the fields from "Parent To Child" through

Workflow Rules.
6. An Object can have max. of 500 Workflow Rules. But max. of 50 Rules can be
in "Active Status" at a time.
7. An Organization can have max. of 2,000 Workflow Rules.
Process Builder:
----------------
Process Builder is a Graphical Representational Tool, Which allows us to
configure the processes, to be get used to Automate the Business Processes inside
the Organization.
Process Builder provides more enhanced facilities than Workflow Rules.

Process Builder provides the below Actions to be get Automated.
1. Email Alerts:
By using this action, We can send the Email Alert to the required
people with the Pre-existing Email Templates based on the requirement.
2. Create a Record:
By using the Process Builder, We can Create a Record inside the
Object, by passing the values for the fields through Process Builder at runtime.
3. Update a Record:
By using this Action, we can update a Record by assigning the New
values for the fields.
Note:
We can perform the Cross-Object field updates by using this
action.
1. We can update the fields from Child To Parent, even

though the
objects are associated with either "Lookup / Master-
Detail" association.
2. We can update the fields from Parent To Child, even

though the
objects are associated with either "Lookup / Master-
Detail" association.
4. Trigger an Apex:
By using this action, we can invoke the Apex Code.
5. Invoke a Process:
By using this Action, we can invoke an another Process.
i.e. We can implement the Chaining Processes inside the
Organization.
6. Post To Chatter:
By using this action, we can post the required information into
the Chatter Feed, which makes the information will be visible to a group of people.
7. Submit For Approval:

By using this action, we can submit the record for the Approval
Process.
8. Custom Notifications:
We can send the Custom Notifications to the users.
9. Invoke a Flow:
We can invoke a Flow by using Process Builder.
Navigation:
Setup --> Build --> Create --> Workflow & Approvals --> Process
Builder.
Email Alert:
============
By using this action, we can send the Email Notifications to the required
people by using a Pre-existing Email Template.
i.e. Email Template is a Pre-Requisite option for Process Builder, to Send
the Email Alerts.
UseCase:
========
Configure a Process on the Hiring Manager Object, to Notify the Hiring
Managers upon Creating a New Record. Use different Email Templates based on the
Location as below.
Hiring Manager:Location == 'Hyderabad' ---> Use Plain Text Template.
Hiring Manager:Location == 'Bangalore' ---> Use HTML Email Template
Hiring Manager:Location == 'Mumbai' ---> Use Custom Email Template.
Step 1: We need to Create the Required Email Templates with the required
Subject and the Content.
We need 3 Email Templates.

1. Plain Text Template
2. HTML Template
3. Custom Template
Step 2: We have to Create the Email Alerts.
Setup --> Build --> Create --> Workflow & Approvals --> Email
Alerts.
1. Click on "New Email Alert" button.
2. Enter the Email Alert Description, and Unique Name.
3. Select the Object Name from the Picklist, on which the
Email
Alert will get associated.
4. Select the Email Template Name by using the "Lookup
Icon".
5. Select the Recipient Type as "Email Field". And add the
Email
Address fields.
6. Enter the CC Email Addresses upto max. of 5.
Note:
We need to Create 3 Email Alerts.
Step 3: Create a Process on the Hiring Manager Object.

Process Starts When : When a Record Changes.
Select the Object Name : Hiring Manager.
Select the Criteria : Created.
Conditions:
Hiring Manager:Location == 'Hyderabad'
Action Type : Immediate.
Select the Email Alert : Enter the
Email Alert Name
Note: Repeat the Conditions Section, to Add Multiple

Conditions and Add the Multiple Actions.
Creating Records:
=================
By using this Action, we create one or more records inside the Object, or We can
Create the Related Records in the Child / Parent Objects.
While Creating the Record, we have to supply the values for the required
(mandatory) fields through Process by hard coding the values or we can get the
values by referencing the Parent Records.
UseCase:
========
Configure a Process on the Account Object, to Create a Related Contact Record
inside the Contact Object, Which meets the below Conditions.
1. Account:Rating == 'Hot'
2. Account:Industry == 'Banking'
3. Account:Active == 'Yes'
Note: Copy the Account Record Data into the Contact Record Fields.
Analysis:
Object Name : Account Object
Process Starts When : A Record Changes.
Criteria : When a New Record Created.
Conditions:
Account:Rating == 'Hot'
Account:Industry == 'Banking'
Account:Active == 'Yes'
Action Name : Create a Record.
Record Type:
Contact Record.
Set the Field Values:
Source Field Target Field
-----------------------------------------------
Account:Name --> Copy -->
Contact:LastName
Account:Phone --> Copy --> Contact:Phone
Account:Fax --> Copy --> Contact:Fax
Account:BillingStreet --> Copy --> Contact:MailingStreet
Account:BillingCity --> Copy -->

Contact:MailingCity
Account:BillingState --> Copy -->
Contact:MailingState
Account:BillingPostalCode--> Copy -->
Contact:MailingPostalCode
Account:BillingCountry --> Copy --> Contact:MailingCountry
Account:ID --> Copy -->

Contact:AccountID
Record Update:
==============
By using this Action, We can update the Records inside the Same object or in
Parent Object Or in Child Object.
It allows us to update the records between the Cross-Objects, which are

associated with either "Lookup / Master-Detail" associations.
While Updating the records, We can supply the New values for the fields
through Process Builder at runtime or we can reference the values from the parent
records.
Note: Process Builder supports to update the records from both "Parent To
Child" and "Child To Parent" also.
UseCase:
========
Configure a Process on the Account Object, to Synchronize the Account Details
into the Related Contact Records upon Creating / Updating the Account Record.
Analysis:
Object Name : Account Object.
Process Starts When : When a Record Changes.
Criteria / Event : When a Record Created, and Edited.
Rule Conditions:
Account : Active == 'Yes'
Action Type : Immediate Action.
Action Name : Record Update
Record Type : Contacts.
Set the Field Values:
Source Field
Target Field
-----------------------------------------------------
Account:Phone --> Copy --> Contact:Phone
Account:Fax --> Copy --> Contact:Fax
Account:BillingStreet --> Copy --> Contact:MailingStreet
Account:BillingCity --> Copy --> Contact:MailingCity
Account:BillingState --> Copy --> Contact:MailingState
Account:BillingPostalCode--> Copy -->

Contact:MailingPostalCode
Account:BillingCountry --> Copy --> Contact:MailingCountry
Assignments:
============
1. Configure a Process on the Candidate Object, to Notify the Candidate
Person
upon Submitting the Candidature for a Hyderabad Location Position.
2. Configure a Process on the Account Object, to Notify the Account Owner

based on the Industry with the Different Email Templates as below.
Account : Industry == 'Banking' ---> Send Email with Plain Text

Template
Account : Industry == 'Education' ---> Send Email with HTML Template
3. Configure a Process on the Position Object, to Notify the Hiring Manager

Upon Assigning a New Position Record to the HR Person.
And Send the Reminder Alerts to the HR Person as below.
----------------------------------------------------------------------------------
Data Management / Data Migration:
=================================
----------------------------------------------------------------------------------
Data Migration allows us to migrate / move the records from One Object to another
Object / One Application to Another Application / One Server to Another Server /
One Organization to Another Organization.
Data means Records.
We can perform the operations on the records like "INSERT, UPDATE, DELETE,
SELECT",..ETC.
Salesforce provides the various approaches to manage the records inside the object.
1. Page Layouts:
By using this approach, we can Perform the Operations (i.e. INSERT,
UPDATE, DELETE) on only one record at a time.
2. Apex Programming:
By using Apex Programming we can perform all the DML operations
(INSERT, UPDATE, DELETE, UNDELETE, UPSERT, MERGE) on max. of 10,000 records at a
time.
3. Data Import Wizard:

It is a feature provided by Salesforce to perform Only the Import
Operations (INSERT, UPDATE) on the bulk records at a time.
We can't perform the Export Operations.
Note: Import wizard allows us to import max. of 50,000 records at a

time
into the object.
Note: Data Import Wizard will support only 5 Standard Objects like
"Account,Contact, Lead, Solution, and Campaign Member" and
all Custom Objects.
We have to supply the input records to the Import wizard in the

form of ".CSV" file ( .CSV --> Comma Separated Value File)
Setup --> Administer --> Data Management --> Data Import Wizard.
4. Data Export:
By using this feature, we can Export the Records from All Standard and
All Custom Objects and store them to the Local System in the form of .CSV file.
We can export the records either Manually or we can make it Scheduled

based on the periodical intervals.
Setup --> Administer --> Data Management --> Data Export.
5. DataLoader Tool:
It is an On-Premise Tool provided by Salesforce to perform both "Import
and Export" operations on bulk records at a time.
It requires the Pre-Installation. DataLoader has been built-up on "Java

Programming". Hence it requires the Java Installation in our local device.(i.e. JDK
and JRE).
DataLoader Tool supports All Standard and All Custom Objects to perform
both "Import and Export" operations.
It allows us to process max. of 5 Million Records at a time.
We have to supply the input records to the DataLoader in the form of

".CSV" file
Note:
DataLoader internally divide the records into the various batches
by using Batch Programming. Where it supports 2 API's as below.
1. Apex API:
Min. Batch Size: 1
Max. Batch Size: 2,000
Default Batch Size : 200
2. Bulk API:
Min. Batch Size: 1
Max. Batch Size: 10,000
Default Batch Size : 2,000
DataLoader will generates 2 Output Files as below.

1. Success File(.CSV):
It contains all the records, which has been processed
Successfully.
2. Error File (.CSV):

It contains all the Failed Records information,
including Failure Reason.
DataLoader Supports the below 7 Operations.
1. INSERT
2. UPDATE
3. DELETE
4. UPSERT
5. HARD DELETE
6. EXPORT
7. EXPORT ALL
DataLoader Comes in 2 Flavors.
1. DataLoader for Windows.

2. DataLoader for Mac.
Setup --> Administer --> Data Management --> DataLoader.

Note:
In-Order to use the DataLoader, we have to Login into the DataLoader by
using any of the below Authentication.
1. OAuth Authentication (Open Authentication)

2. Password Authentication.
Password Authentication:
------------------------
To Login into the DataLoader, by using Password Authentication.
We have to User the Salesforce Account UserName, Password and Security Token.
We can generate the Security Token as below.
Login into your Salesforce Account.

1. Click on Your Name and expand it.
2. Click on "My Settings" link.
3. Goto the "Personal" and Expand it.
4. Click on "Reset My Security Token" link.
5. Click on "Reset Security Token" button.
Observation:
It will generate the Security Token, and will send to
the user's email id automatically.
Note:
User Name : Salesforce Account UserName.
Password : Salesforce Account Password + Security
Token.
(MR47GoTQXVIWibuXaehPFHGV)
Export:
=======
By using this operation, We can fetch either One / More / All the records
from the specified object, and we can store the records inside our local system in
the form of a ".CSV" file.
Note:
While exporting the records, we can add the required user defined
conditions to filter the records based on the business needs.
Ex:
Rating == 'Hot'
Industry == 'Banking'
Active__C == 'Yes' and AnnualRevenue > 5000000
We can fetch the specified number of records form the object, by using
"LIMIT Clause".
Ex:
Limit 5
Limit 10
Limit 2
UseCase:
--------
Export All the Account Records exist inside the object, and store them
to the local system.
Export All:
===========
This feature allows us to Export All the Records exist inside the object,
including Deleted Records also.
Note:
Salesforce Maintains an additional field "IsDeleted" in All Standard
and Custom Objects Which is of type a "CheckBox".
This field indicates, the record has been Deleted or not.
IsDeleted == TRUE --> Record is Deleted.

IsDeleted == FALSE --> Record is Not Deleted.
UseCase:
--------
Export All the Account Records from the Object, including Deleted
Records also from the RecycleBin and store them to the Local System.
Assignments:
------------
1. Export All the Case Records from the object and store them to the local
System.
2. Export All the Lead Records from the Object, Which satisfies the below
conditions and store them to the local device.
Lead : Industry == 'Energy'
Lead : AnnualRevenue >= 5000000.
3. Export All the Records from the Hiring Manager Object, including Deleted
Records.
4. Export All the Opportunity Records, Whose Amount is more than 10,000 and
store them to the local system.
Insert:
=======
By using this feature, we can Insert One / More records into the associated
object at a time.
While Inserting the records, we have to supply the records to the DataLoader
as Input in the form of a ".csv file".
Note:
While Inserting the Records into the object, we have to map the fields
either manually / automated by selecting the button "Auto-Match Fields to the
Columns".
Once the operation has been done, DataLoader will generates 2 Output Files.
1. Success File: Contains the Records details, which has been

processed successfully.
2. Error File: Contains the Failed Records information, including

the
Failure Reason.
success042021095629982
Delete:
=======
By using this feature, we can Delete either one or more records from the
object at a time.
Note: To delete the records from the object, we should have the 'Record ID".
Note: Deleted Records will get resides inside the "RecycleBin" for 15 Days.
Update:
=======
By using this feature, we can update the records by assigning the New Values
for the required fields.
We can update either one or more or all the records inside the object upto
max. of 5 Million Records at a time.
Note:
While updating the records, we have to supply the Record ID also.
Upsert:
=======
Upsert = Update + Insert.
By using this feature, we can perform both "Insert and Update" operations on
the object records at a time.
i.e. We have to place the records inside the ".CSV" file, which needs to be
inserted and updated both
DataLoader will differentiate the records based on the Record ID. The Records
which contains the Id inside the CSV file, will be get Updated. And the Records
which doesn't have the ID in the CSV file will get inserted as New into the object.
Hard Delete:
============
By using this feature, we can Remove the records from the object Permanently
with out moving to the RecycleBin. Which can't be restored back to the object.
Note:
Hard Delete operation requires a Special Permission in the user's
profile level called as "Bulk API Hard Delete".
-----------------------------------------------------------------------------------
Security Features:
==================
----------------------------------------------------------------------------------
Upon Creating a Salesforce account, it will reserve some amount of in the
Salesforce server, based on the Country entered by the user in the Registration
form.
Once the Salesforce has activated the account, then it is called as a

Salesforce.com Organization (Simply: Org)
For Each Salesforce.com organization, it allocates a unique identification number

called as "Salesforce.com Organization Id", which starts from "OOD".
In a single Salesforce instance (Ex: ap2 / ap3 / na41/ etc), it will allocates the
memory for 8000+ Salesforce organizations.
Each organization in the instance will have the access on "Salesforce CRM"
application.
Salesforce maintains Common Set of Standard Objects, for all the organizations in
the instance.
i.e. Salesforce is not maintaining a separate set of objects for each organization.
If any of the organization people, creates a New Account Record, then it will
reside in the Same "Account" table.
To Differentiate the Records, between the Organization Salesforce includes a Field

called as "Organization ID", in each object.
Which holds the Organization Id, along with the account record.
If multiple users exist in an organization, then to differentiate the records

between the users inside the organization, Salesforce maintains "UserID" field in
each object. Which contains the User Id of the Person, who creates the record.
When the user make a request to Salesforce server, then along with the request
details, it will forward the Currently Logged In user Id and Organization id.
Ex: (Request)
Requested URL+
Form Data +
Header Information +
Browser Info.+
O.S. Information +
Session ID +
IP Address +
OrganizationID +
USer ID
We can able to add, One or more users inside a Salesforce organization. All the
User Records will resides in "User" table.
For each user, Salesforce allocates a unique identification number called as

"UserID", which starts from "005".
Licenses:
=========
License provides a Set of features can be accessible by the users within the
Organization.
In-Order to add a User inside the Organization, we should have a "License".

Each User should be associated with a separate License.
Based on the Number of Users wants to access the applications, those many
number of Licenses we should have inside the Organization.
Salesforce provides various Types of Licenses..
1. Salesforce License / Standard License / Full License: (2)

This License will grant the Access on All Standard and All Custom
Functionalities exist inside the Organization.
i.e. By using this License, we can Access All Standard Apps,

Custom Apps, Standard Tabs, Custom Tab, Standard Objects, Custom Objects, Standard
Fields, Custom Fields, Standard Features and Custom Features,...etc.
2. Platform License: (3)

It will purely concentrate on the "Custom Functionalities". i.e.
This License will grant the Access on All Custom Apps, Object, Tabs, fields, and
Custom Features, including 5 Standard Objects like "Account, Contact, Document,
Task and Event".
i.e. They can't access the Standard Applications.
3. Chatter Free License: (5,000)

This License will grant the Permission to post the FeedItems into
the Chatter Feed.
4. Customer Community License: (5)

This License will grant the Access on the Community Portals (Ex:
Customer Community and Partner Community)
....
....
Note: All the Licenses information will get resides inside the "UserLicense"
object.
We can see the available Licenses as below.
Setup --> Administer --> Company Profile --> Company Information link.
1. Goto the "User Licenses" section.
2. View the List of Available Licenses inside the Organization.
Profiles:
=========
Profile is nothing but a Mediator Component between the Organization and
User.
Profile Contains a Set of Permissions can be assigned to One or more Users

Inside the Organization.
By using Profile, we can either Restrict / Grant the Permissions on the

features to the users.
While Creating the User, each User should be associated with a "Profile and a
License". We can't assign the multiple Profiles to the Same User.
Each Profile is associated with a "LicenseType". But, with One LicenseType we

can have multiple associated Profiles.
Note: All the Profiles information will get resides inside the "Profile"
object.
Salesforce provides 2 Types of Profiles.
1. Standard Profiles:
These are the readymade profiles provided by Salesforce by
default.
Standard Profiles can be editable upto some extent. These are not
fully editable. And We can't remove the Standard Profiles from the Organization.
Note:
It is always recommended to Do Not assign the Standard
Profiles to the User. Create the Custom Profiles by cloning the existing one, and
Assign the Custom Profiles to the Users.
2. Custom Profiles:
The Administrator / Developer can create the Profiles by cloning
the existing once. And we can assign the Custom Profiles to the required users.
We can Customize & Remove the Custom Profiles from the

Organization.
Setup --> Administer --> Manage Users --> Profiles.
Creating Custom Profiles:

-------------------------
Setup --> Administer --> Manage Users --> Profiles.
1. Click on "New Profile" button.
2. Select the "Existing Profile" from the Picklist, to be make it
Clone.
3. Enter the "New Profile Name" in the TextBox.
Create the below 2 Profiles:

----------------------------
1. Salesforce Licensed Profile:
Existing Profile : Standard User
New Profile Name : CIS Salesforce Profile
2. Platform Licensed Profile:

Existing Profile Name : Standard Platform User.
New Profile Name : CIS Platform Profile
User Management:
================
Once the Organization is ready with the required Applications, Objects, Features
then we can grant the Access on the Organization features to the required users.
Users are nothing but the people, who can access our Organization features. (i.e.
Applications, Objects, Records,...etc.)
User can be a Partner / Employee / Customer / End User,....etc.
Based on the application requirement, we need to add the users as below...
Note:
While Adding a New User to the Organization, we required a "Profile" and a
"License".
Creating the User involves the below 2 steps.
Step 1: Fill up the User Form with the required Details.
Setup --> Administer --> Manage Users --> Users link.

1. Click on "New User" button.
2. Enter the User Details.
First Name, Last Name, Email ID, Alias Name, Nick
Name, User Name (Email Id format), Title, Department, Division,...etc.
3. Select the License from the Picklist, to be get assigned
to the user.
4. Select the Associated Profile from the Picklist, to be
get assigned to the users.
Observation:
It will add a New User to the Organization with the
specified Details, and will send the User Activation link to the user's email id.
Step 2: Activate the User, by using Activation Link.

1. Goto the Email Account and Open the Email received from
Salesforce
2. Click on "Verify Account" button.
3. Enter the Password, Confirm Password, Security Question and
Answer.
4. Click on "Change Password" button.
Observation:
It will reset the user password and will re-direct the user
to the Salesforce Organization.
Create the below 4 Users:

-------------------------
1. Salesforce Licenses : 1 Available

User: Development User. ([email protected])
2. Platform Licenses : 3 Available

User 1: Manager User ([email protected])
User 2: Customer User ([email protected])
User 3: Testing User ([email protected])
User Management:
================
1. Editing the User Details:
By using this feature, we can modify the user details at any point of
time based on the application requirement.
Setup --> Administer --> Manage Users --> Users.

1. Click on the "User Name", which you would like to
update.
2. Click on "Edit" button.
3. Modify the required field values.
2. Reset User Password:

By using this feature, the Administrator can reset the Password for one
or more user accounts.
1. Select the Checkbox for the Required Users, to reset the
Password.
2. Click on "Reset Password" button.
Observation:
It will generate a Reset Password link and will send to the
user's email id automatically by default.
3. Expire All Users Passwords:

By using this feature, we can make all the user's password will get
expired at a time. So, when the user tries to login into the application, then it
will re-direct the user to the Change Password Screen.
Setup --> Administer --> Security Controls --> Expire All User
Password.
1. Select the Checkbox "Expire All User Passwords".
4. Prevent the User from Login.

1. De-Activate the User
2. Freeze / UnFreeze the User.
5. Login Access Policies:
Setup --> Administer --> Security Controls --> Login Access Policies.
1. Select the Checkbox "Administrator can Login as Any User".
6. Prevent from Force Re-Login.

Setup --> Administer --> Security Controls
1. Click on "Session Settings".
2. Goto the "Require Secure HTTPs Connections".
3. UnSelect the Checkbox "Force Re-Login After Login as the
User".
7. Audit Setup Trials:

Setup --> Administer --> Security Controls --> View Setup Audit Trails.
8. Login History:
Setup --> Administer --> Manage Users --> Login History.
Role Hierarchy:
===============
CEO
|
| ---> CFO
|
| ---> COO
|
---> CTO
|
|
---> Vice President
|
---> Program Manager
|
---> Project Manager
|
----> Tech
Lead
---> SE
SSE
ASE
Role Hierarchy will make the Sub-Ordinates records will get visible to the
Manager by default.
i.e. When a Sub-Ordinate person creates a Record inside the object, then
immediately the record will get visible to the Manager automatically by default.
Based on the Organization requirement, we can configure the Role Hierarchy.

And we can assign the Roles to the required users.
Note:
A User can be associated with only "One Role". But, a Role can be
assigned to one or more users inside the Organization.
Note: All the Roles information will get resides inside the "UserRole"
Object.
Navigation:
Setup --> Administer --> Manage Users --> Roles.
CEO (System Administrator - Training Batch User)

|
| ----> CFO (Manager User)
|
| ----> COO (Customer User)
|
----> CTO (Development User)
|
----> VP (Testing User)
OWD (Organization Wide Defaults):

=================================
Once the Role Hierarchy has been Configured, Then if the user Creates a Record
inside the object, then the Record should be visible to the "Record Owner" and his
Manager automatically by default.
To restrict the visibility of the record, we can use the help of "OWD".
OWD decides, which record will be visible to whom. i.e. While Creating the record
inside the object, up to what level the record will visible, should be decided by
"OWD".
"OWD" can be applicable only at the Object Level.

Salesforce provides the below OWD Options.
1. Private
2. Public ReadOnly
3. Public Read/Write
4. Public Read/Write/Transfer
5. Public Full Access
6. No Access
7. View Only
8. Use
9. Controlled By Parent.
Note:
1. Private, Public ReadOnly and Public Read/Write options will be applicable
to "All
Standard and All Custom Objects", except the "PriceBook Object".
2. Public Read/Write/Transfer option will be applicable only for the "Lead

and Case Objects".
3. Public Full Access option will be applicable only for the "Campaign
Object" in Salesforce.
4. No Access, Use, View Only options are applicable only for the "PriceBook"
object.
5. Controlled By Parent Option will be applicable only for the Child Objects.
Navigation:
Setup --> Administer --> Security Controls --> Sharing Settings.
1. Goto the "Organization Wide Defaults" section.
2. Click on "Edit" button.
3. Select the "OWD Option" for the objects.
Private:
========
When the Object's OWD has been assigned as "Private", then if the user
creates a Record inside the object, then the Record will be visible to only the
Record Owner and his Manager automatically by default.
Other Users inside the Organization (i.e. Siblings, Sub-Ordinates) will not
be able to access the record.
Sharing Mechanism:
1. Manual Sharing
2. Automated Sharing
3. Apex Sharing
Manual Sharing:
===============
By using this approach, we can Share the record to one or more users inside
the Organization with either "ReadOnly Or Read/Write" access.
Manual Sharing can be achieved with the help of "Sharing Button", which will
be visible on the Record's Detail Page.
UseCase:
--------
Create an Account Record by login with the Development User Account,
and Share the Account Record to "Customer User" with "ReadOnly Access".
1. Login into the Development User Account.

2. Create an Account Record by providing the details.
3. Click on "Sharing" button.
4. Click on "Add" button, to Select the Users, to whom we have to
share.
5. Select the User Type as "Users".
6. Select the "User Name" (i.e. Customer User) by using "Add /
Remove"
buttons.
7. Select the Account Access Level from the Picklist (Ex:
ReadOnly)
Testing Process:
1. Login into the Customer User Account.
2. Click on "Accounts" and View All Accounts.
Observation:
This User should be able to See the Record, which has been
shared.
Negative Testing:
1. Try to Edit / Delete the Record, by click on "Edit" button.
Observation: He will get the Error Message "Insufficient
Privileges".
UseCase:
--------
Share the Above Record to the "Testing User" with "Read/Write" access.
Share Record to Multiple Users:

===============================
While Sharing the Records to the multiple users, If we have the Bulk Number
of records, then it will take more time to share each record to the required users
manually.
So that we can combine the users into a Public Group.
Public Group Contains a set of user or Sub Groups. When the user share a
record to the Public Group, then the record will get visible to all the users(Group
Members) inside the Public Group.
Setup --> Administer --> Manage Users --> Public Groups.
Note:
All the Public Groups Information will get resides inside the "Group
Object".
Note: We can Create multiple Public Groups inside an Organization.
UseCase:
--------
Create a Public Group with the name "Hyderabad Sales Group", and add the
"Customer User and Testing User" as the Group Members.
Setup --> Administer --> Manage Users --> Public Groups

2. Enter the Public Group Name and label.
3. Select the Users / Members to be added to the Public Group, by
using "Add / Remove" button.
4. Select the Checkbox "Grant Access Using Hierarchies".
UseCase:
--------
Create an Account Record by login with the "Development User" account, and
Share the Record to the "Hyderabad Sales Group" with "ReadOnly" access.
Automated Sharing:
==================
By using this process, we can share the record to one or more users dynamically at
runtime based on certain conditions.
Automated Sharing can be implemented with the help of "Sharing Rules". Sharing
Rules will always fired "After Insert and After Update" the records inside the
object.
Salesforce provides 2 Types of Sharing Rules.
1. Owner Based Sharing Rules:

By using this approach, we can Share the Records to the required users
based on the Record Owner.
2. Criteria Based Sharing Rules:

By using this approach, we can Share the records to the required users
based on the specified conditions. If the record meets the specified conditions,
then it will share the record to the specified user with the specified access.
Note: An Object can have one or more Sharing Rules.
Setup --> Administer --> Sharing Settings --> Sharing Rules Section.
1. Goto the Required Object's Sharing Rules Section. (Ex: Accounts
Sharing Rules)
Note:
By using Sharing Rules, we can Share the records based on "Role / Roles &
SubOrdinates / Public Group".
UseCase:
========
Configure a Sharing Rule on the Account Object, to Share the Account Records
to "Hyderabad Sales Group", when the Account Record meets the below Conditions.
1. Account:Rating == 'Hot'
2. Account:Industry == 'Finance'
3. Account:CustomerPriority == 'High'
4. Account:Active == 'Yes'
Public ReadOnly:
================
When the Object's OWD has been assigned as "Public ReadOnly". Then if any of
the user creates a record inside the object, then the Record will get visible to
all the users inside the Organization. i.e. It is a Public Record.
The Record Owner and his Manager will get the Full Control on the Record
(i.e. View, Edit, Delete, Share).
But, the Other Users inside th Organization, will have the ReadOnly access on
the record. They can't perform the "Edit and Delete and Share" operations.
Public Read/Write:
==================
When the Object's OWD has been assigned as "Public Read/Write". Then if any
of the user creates a record inside the object, then the Record will get visible to
all the users inside the Organization. i.e. It is a Public Record.
The Record Owner and his Manager will get the Full Control on the Record
(i.e. View, Edit, Delete, Share).
But, the Other Users inside th Organization, will have the Read and Edit
access on the record. They can't perform the "Delete and Share" operations.
Public Read/Write/Transfer:
===========================
By using the "Transfer" option, we can Transfer the Record Ownership from One
User to another User. So that New Owner will get the Full Control on the Record,
and Old Owner will lose the access on the record.
Note:
Public Read/Write/Transfer option will be applicable only for "Lead and
Case" objects in Salesforce.
Note:
While Transferring the Ownership of either "Lead / Case Records", we
can transfer to either a "User / Queue".
Queue:
------
Queue is nothing but a location, where all the pending records are awaiting
for the processing.
Queue Contains 2 things.
1. Queue Members:
These are the users, who can access the Queue records.
2. Queue Supporting Objects:

It indicates the objects, which are supporting by the Queue.
Queue supports the below object records can be hold inside it.
Ex:
Lead, Case, FeedBack, FeedBackQuestion, FeedBackRequest,
FeedBackTemplate, FeedBackQuestionSet, Performance Cycle, Goal, Metric, Macro,
Knowledge Article Version, User Provisioning Request, Score Card, Quick Text,
Coaching, Order, All the Custom Objects.
Note:
While placing the record inside the Queue, All the Queue Members will
receive an email notification automatically.
The Record will exist inside the Queue Until any of the Queue Members
accepted it.
Once a Queue member has accepted the record, then the record ownership
will get Transferred to the Accepted member automatically.
Setup --> Administer --> Manage Users --> Queues.

UseCase:
========
Configure a Queue "Tier 1 Service Queue", Which can store the "Case Object
Records" inside it. And Add the "Development User" as the Queue Member.
Setup --> Administer --> Manage Users --> Queues.

2. Enter the Queue Label, Name.
3. Enter the Queue Email ID.
4. Select the Checkbox "Send Notifications to Members".
5. Select the Queue Members from the Picklist.
6. Select the Queue Supporting Objects.
(Ex: Case)
Note: We can create one or more Queues inside the Organization.
Note:
While Creating a Queue, by adding the Queue Member. Then the Queue
Member will get an "List View Option" for the Queue Supporting Object
automatically.
Transfer the Records to the Queue:

----------------------------------
While Transferring the records to the User / Queue we have the below 2 ways.
1. Manual Transfer:
In this approach, we have to transfer the record Ownership to
either a User / Queue Manually by using "Change" link.
Navigation:
Goto the "Cases" Tab.
1. Open any of the Case Record.
2. Goto the Detailed Page of the Case Record.
3. Goto the "Owner Field" and Click on "Change Link".
4. Select the Owner Type (Ex: User / Queue) from the
Picklist.
5. Select the Owner to Transfer the Case. (Ex: Tier 1
Service Queue)
Observation:
Queue Member will receive an Email Alert
automatically.
Accepting the Queue Record:

---------------------------
Once the Record has been placed inside the Queue, The
Queue Member can see the record inside the object.
Queue Member can accept the record to work on the

Case.
1. Open the Queue, by selecting the "ListView

Option".
2. Select the "Checkbox" of the record to be
get Accepted.
3. Click on "Accept" button.
Observation:
It will transfer the record ownership from
"Queue to the Accepted Member".
2. Automated Transfer:
Assignment Rules. 2 Types.
1. Lead Assignment Rules:

Setup --> Build --> Customize --> Leads --> Lead
Assignment Rules
2. Case Assignment Rules:

Setup --> Build --> Customize --> Cases --> Case
Assignment Rules
3. Custom Assignment Rules. (Apex Programming - Triggers)
Assignment Rules will get fired "After Insert", "After Update".
Note:
We can Create one or more Assignment Rules inside an
Organization. But, Only One Assignment Rule will be in "Active" at a time.
UseCase:
========
Configure a Lead Assignment Rule, to Auto Assign the Lead Records to the
associated Queues based on the Lead City as below.
Lead City Name Queue Name

------------------------------------------------------
Lead:City == 'Hyderabad' ---> Hyderabad Sales Queue
Lead:City == 'Bangalore' ---> Bangalore Sales Queue
Lead:City == 'Mumbai' ---> Mumbai Sales Queue
Lead:City == 'Chennai' ---> Chennai Sales Queue
Step 1: Create the REquired Queues, by adding the "Lead Object" as

Queue
Supporting Object. And "Development User" as the Queue
Member.
Step 2: Create the Lead Assignment Rule.

Setup --> Build --> Customize --> Leads --> Lead Assignment
Rules
Step 3: Test the Lead Assignment Rule.

Click on the "Leads" Tab.
2. Enter the Data inside the Lead Fields.
3. Goto the "Optional" features section.
4. Select the Checkbox "Assign Using Active
Assignment Rules".
Observation:
It will Create the Record and will apply the Lead
Assignment Rule on the Record. If the record satisfies the conditions, then it will
transfer the record to the associated Queue.
So that Queue Member will accept the record and will

work on the record.
Web To Lead:
============
By using this feature, we can capture the Lead Records through the Company
Website.
i.e. The people can access the Company Website and they show their interest
on our products through Online.
The Lead records, which has been captured through the Company Website is
called as "Online Leads".
We can Configure the Web To Lead feature as below..
Step 1: Enable the Web To Lead feature for the Organization. (By default it
will be
enabled for all the Organization's)
Setup --> Build --> Customize --> Leads --> Web To Leads.
1. Goto the "Web To Lead Settings" section.
2. Select the Checkbox "Enable Web To Lead".
Step 2: Generate the "Web To Lead" form, which can be placed inside the
Organization
Website.
Setup --> Build --> Customize --> Leads.
1. Click on "Web To Lead" link.
2. Click on "Generate Web To Lead Form" button.
3. Select the Fields to be get placed on the Web To Lead
Form by using
"Add / Remove" buttons.
4. Arrange th fields in the required order by using "Up /
Down"
navigation buttons.
5. Enter the "Return URL".
6. Click on "Generate" button.
Observation:
It will generate the HTML code based on the Selected
Fields.
Step 3: Create the HTML Page / Form, and place inside the Company Website.
1. Open a Notepad Document.

2. Type the HTML Tags as below.
<html>
<body>
// Paste the HTML Generated Content.
</body>
</html>
3. Save the file with the extension ".html / .htm".
4. Share the HTML Code to the Organization's WebDesigner, to
place the form inside the Company Website.
Step 4: The End Users, Customers will access the Form from the Company
Website, and
they can show the interest by filling th fields.
Then it will Create a Lead Record inside the object with the same
details.
Note:
Assignment Rules will get fired for the "Web To Lead Records Automatically by
default".
Web To Case:
============
Setup --> Build --> Customize --> Self Service --> Web To Case.
UseCase:
--------
Configure the Web To Case Feature, to Create the Case Records through the
Organization WebSite. And Assign the Case Records to the Associated Queues
Automatically based on the Assignment Rule as below.
Conditions Queue Name

---------------------------------------------
Case:Priority == 'High' ---> Tier 1 Service Queue
Case:Priority == 'Medium' ---> Tier 2 Service Queue
Case:Priority == 'Low' ---> Tier 3 Service Queue
Email To Case:
==============
[email protected]
4sbboeac.ap24.case.salesforce.com
[email protected]
[email protected]
Profiles:
=========
By using the Profiles, we can grant the Permissions on the various features as
below.
1. We can Specify, What Applications the User can Access.
UseCase:
--------
Configure the Profile Permissions to grant the Access on only
"Sales and Talent Acquisition Applications" to the Development User.
2. We can specify, What Tabs the User can Access:
1. Default ON: By default this tab will be visible on the TabBar.
2. Default OFF: By default, the Tab will not be visible on the

TabBar. But
we can see the Tab inside the "All Tabs (+)" option. So
that we can make it add onto the TabBar, when ever it is needed.
3. Tab Hidden: The User won't have the Access on the Tab.
UseCase:
--------
Configure the Profile Permission for the Development User to
restrict the Tab Permissions as below.
Default ON : Accounts, Contacts, Opportunities.

Default OFF: Campaigns, Leads
Tab Hidden : Cases, Solutions, Orders.
3. We can specify, What Objects the User can Access.
4. We can specify, What Operations the user can perform on each object.
UseCase:
--------
Configure the Profile Permissions to the Development User, to
grant the Access on the Objects as below.
Account : C, R, E, D
Contact : C, R, E
Opportunity : R, C
Hiring Manager : C , R, E, D
Position : C,R,E
5. We can specify, What Fields the User can Access:
UseCase:
--------
Configure the Profile Level Permissions to the Development user,
to remove the Access on the below Account Object fields.
1. Account Site.
2. Account Source.
3. Annual Revenue
4. Industry.
6. We can specify, What Page Layouts can be accessible by each profile users.
7. We can specify, What General Permissions to be Applicable.
8. We can specify, What Administrative Permissions to be applicable.
9. We can specify, What Custom Permissions to be applicable.
10. We can specify, What System Permissions to be applicable.
Ex:
1. To Delete the Records Permanently from the Organization: we
need a
Permission "Bulk API Hard Delete".
2. To Create the Apex Classes: We need a Permission "Author

Apex".
11. We can specify, What Session Settings to be Applicable.
12. We can specify, What Password Policies to be applicable.
13. We can specify, What Login Hours to be Applicable.

14. We can specify, What Login IP Ranges to be applicable.
15. We can specify, What Apex Classes can be accessible.
16. We can specify, What Visualforce Pages can be accessible.
17. We can specify, What External DataSources can be accessible.
18. We can specify, What Custom MetaData types can be accessible.
19. We can specify, What Custom Settings can be accessible.
PermissionSets:
===============
Setup --> Administer --> Manage Users --> PermissionSets.
UseCase:
--------
Configure a PermissionSet to Grant "Edit and Delete" permissions on the
Account Object to the "Manager User".
Step 1: Create a PermissionSet, by assigning the Required Permissions.
Step 2: Assign the PermissionSet to the required users.

1. Goto the Users Detailed Page.
2. Goto the "PermissionSet Assignments" section.
3. Click on "Add" button.
4. Select the "PermissionSets" by using "Add /
Remove" buttons, to
be get assigned to the users.
Salesforce Security Model:

--------------------------
System Level Security (Login IP Ranges, Login Hours, SSO)

^
|
|
----- Application Level (Profile, PermissionSets)
Security
^
|
|
----- Object Level (Profiles,
PermissionSets)
Security
^
|
|
----- Field Level
(Profiles, PermissionSets)
Security
^
|
----- Record Level
Security
(Roles, OWD, Manual Sharing, Sharing Rule, Apex Sharing, Profile)
---------------------------------------------------------------------------------
Reports & Dashboards:
=====================
---------------------------------------------------------------------------------
Salesforce CRM
|
---> Sales
Service
Marketing
Content
Chatter
....
....
Talent Acquisition System
Story Pulse
Banking Automation
....
....
|
---> Objects. (Standard & Custom Objects)
|
--> Reports
Analytics --> Reports & Dashboards.
Report: Report Contains a Collection of records collected from one or more objects.
Dashboard: Dashboard will represent the report data in the pictorial format.
(Ex: Chart Formats --> Horizontal Bar Charts, Vertical Bar Charts,..etc)
Salesforce Provides 2 Types of Reports
1. Standard Reports: Readymade Reports provided by Salesforce by default.
2. Custom Reports: The Developer / Administrator can configure the reports

based on the application requirement.
Report Contains the below features. (Report Configuration Parameters)

1. Contains a Set of Columns.
2. Contains one or more Conditions / Filters.
3. Chart Components.
4. Scheduling Information.
5. Report Type.
Note:
Report Data will be always a RealTime Data. It will represent the records
based on the currently logged in user's context.
Reports Tab & Dashboards Tab:
All the Reports will get stored inside a Report Folder.
Salesforce provides 2 types of Report Folders.
1. Standard Report Folders: Readymade Folders provided by Salesforce

Ex:
Unfiled Public Reports Folder.
My Personal Reports Folder
Sales Reports Folder
Service Reports Folders
Marketing Reports Folder
...
...
2. Custom Reports Folders:

Developer / Administrator can create the Report Folders.
Ex:
Banking Daily Reports Folder
Banking Loan Reports Folder
Banking Customer Reports Folder
...
...
To access the report, the user should have the access on the Report Folder.
We can grant the below 3 Types of Access permissions on the Report Folder to users.
1. Viewer Permission :
The user can just run the report and can see the report data.
2. Editor Permission:
The user can Run the Report and He can modify the Report
Configuration Parameters. But, he can't remove the report from the folder.
3. Manager Permission:
The User will get Full Permission. He can View, Run, Edit and
Delete the reports from the Folder.
Upon Creating the Reports, we have the below 4 Types of Reports.
1. Tabular Reports
2. Summary Reports
3. Matrix Reports
4. Joined Reports
Note:
While representing the object records in a Report, we have to make sure the
"Allow Reports" Checkbox has been selected while creating / editing the object.
Tabular Reports:
================
These are the Basic Type of Report, which will represent the report data in
the Tabular format along with the Grand Total.
Note:
We can't Generate the Chart Component for the Tabular Reports.
We can add one more filters to filter the records to be get represented in
the report.
Upon adding the filters, we can add either "Field Filters, Cross-Object
Filters and Row Limit Filters" to filter the records from the report.
UseCase:
========
Configure a Tabular Report, to represent All the Customers(Accounts)
Information in Tabular format along with the Grand Total.
UseCase:
========
Configure a Tabular Report, to represent only Hot Rating Customers Data in
the Tabular format along with Grand Total.
(Field Filters)
UseCase:
========
Configure a Tabular Report, to represent 5 Active Customer Records in the
Tabular format.
(Row Limit Filter)
UseCase:
========
Configure a Tabular Report, to represent all the Customers who are associated
with few Cases.
(Cross-Object Filters)
Summary Reports:
================
Summary Reports allows us to represent the records by dividing them to the
various smaller groups based on one or more columns.
On Each Group we can apply the Summarized features like "Count, Sum,
Average,...etc.".
Note:
We can represent the Summary Reports data in the format of a Chart
Component.
UseCase:
========
Configure a Summary Report to represent all the Account Records by dividing
them to the various groups based on the Rating Field.
And represent the records in a Chart Component.
Bucket Fields / Bucketing:

==========================
Total Marks: 100

Pass Marks: 50
Student Name Marks Result

-----------------------------------
Ramesh 89 PASS
Kumar 67 PASS
Shankar 51 PASS
Praveen 32 FAIL
Prasad 90 PASS
Customer Type
-------------
PREMIUM AnnualRevenue > 50,00,00,000
BASIC AnnualRevenue < 50,00,00,000
Joined Reports:
===============
Joined Reports are used to combine the multiple tabular reports data into a single
report.
UseCase:
========
Configure a Joined Report, to represent the Service Cases based on the Status
like "New, Working, Closed and Escalated" by dividing the records to 4 different
tables.
Note: We can't Schedule the Joined Reports to be get run on periodical intervals.
Note: We can add max. of 5 Blocks in a Joined Report.
Matrix Reports:
===============
Creating a Dashboard:
---------------------
Dashboard is nothing but a component, which represents the report data in the
pictorial format either in "Horizontal Bar Chart, Vertical Bar Chart, Line Chart,
Pie Chart, DoNut Chart, Guage Chart, Scattered Chart".
Note:
We can represent the Summary Reports and Matrix Reports Data in the
Dashboard Component.
Note:
A Dashboard can have max. of 20 Dashboard Components.

Salesforce Phase-2

Uploaded by

Copyright:

Available Formats

Salesforce Phase-2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Salesforce Phase-2

Uploaded by

Copyright:

Available Formats

Workflow Rules:

1. Event / Criteria / Evaluation / Criteria:

Salesforce provides the below 3 Events for the Workflow Rule,

2. Created, and EveryTime it is Edited:

3. Created, and AnyTime it is Edited and Meeting Subsequent

Pre-Requisite: We should have an Email Template with

Each Field update action allows us to update only one

To update the multiple fields, we have to add

4. Send an Outbound Message:

Types of Workflow Rules:

1. Immediate Action Workflow Rules:

2. Time-Dependent Action Workflow Rules (Time Triggers):

ICICI Bank Credit Card:

Bill Generation Date: 1st of Month

10 Days Before the Due Date (10th) ---> SMS,

Queue --> Workflow Queue.

Hyderabad --> Bangalore

6 Hours Before the Travel Time : (4.00 PM IST) : SMS, Email

(Bus Number, Contact Number)

2 Hours Before the Travel Time : (8.00 PM IST) : SMS, Email

30 Minutes Before of Travel Time : 9.30 PM IST : SMS,

After 2 Hours of Travel : 9.00 AM IST : SMS, Email,

Step 2: Create a Workflow Rule to Send the Automated Email Alerts.

Object Name : Hiring Manager

Action Type: Immediate Action.

Welcome On-Board. Thanks for joining our Organization.

From Today onward you are also part of our HR Department.

Here are your Details..

Hiring Manager ID : {!Hiring_Manager__C.ID}

***This is a System-Generated Email. Please Do Not Reply.

Thanks & Regards,

Object Name: Position Object

4. Create a Workflow Rule on the Candidate Object, to Notify the Candidate

Each Field Update action is used to update only One field.

While updating the fields we have the below 2 Cases.

1. Simple Field Updates:

2. Cross-Object Field Updates:

Simple Field Update:

Object Name: Account Object.

Source Field Target Field

Action Type: Time-Dependent Actions.

If we re-store the record back to the actual object, then it won't

Cross-Object Field Updates:

2. Workflow Doesn't have the Actions to Insert a Record.

4. Workflow Doesn't Support the DML Operations.

5. We can perform the Field Update actions as below.

1. We can add max. of 40 Field Update Actions inside a Workflow Rule.

2. While Performing the Cross-Object Field Updates, we have the below

2. If the Objects are associated with "Lookup", Workflow won't

3. We can't update the fields from "Parent To Child" through

7. An Organization can have max. of 2,000 Workflow Rules.

Process Builder provides more enhanced facilities than Workflow Rules.

1. We can update the fields from Child To Parent, even

2. We can update the fields from Parent To Child, even

7. Submit For Approval:

We need 3 Email Templates.

Step 2: We have to Create the Email Alerts.

Step 3: Create a Process on the Hiring Manager Object.

Note: Repeat the Conditions Section, to Add Multiple