CRM Cheatsheet

WEBSITE & SOCIAL WEB-TO-LEAD FORM

• Organic web traffic • Free trial

• Email responses • “Contact me” request
• Social mentions • Event registration

INBOUND CALLS CREATE NEW LEADS LEAD CAPTURE MY OPEN LEADS DUPLICATE LEAD?

• Referrals • Search first, then • Set up auto-response Set up different Set up duplicate
• Google Maps create a new lead emails: “Thank you views to manage management
in Salesforce for your interest” your leads. to prevent
• Your trial information For example, duplicates at the
today’s leads or point of entry.
• Event details leads sorted by Manually merge
• Set up lead lead type. legacy records.
assignment rules
– Geography
LISTS IMPORT DATA – Company size
– Product ofinterest
• Purchased list • Use the import
• Trade show wizard or dataloader
• Legacy data

PLAN AND EXECUTE

MARKETING CAMPAIGN
• Email marketing • Radio Sales
• Direct mail • Events
• Cold calls • Trade shows
• Partners • PR
• TV
Marketing
Opportunity teams
Opportunity splits
Products & Price books
ARCHIVE YOUR DEAD LEADS
CPQ
Use email marketing and
call downs to re-market to Approval
unqualified or no-contact leads Document generation
Digital signature
Forecasting Support

WORKING LEADS QUALIFIED? OPPORTUNITIES PRESENTATION, PROPOSAL, NEGOTIATION WON

When you’re working Create a set of Opportunity is Customize Salesforce to fit your Salesforce gives your
a lead, set up a series qualification assigned manually internal sales processes, making it entire company a
of tasks based on the questions, such as on conversion easier to monitor your sales pipeline 360-degree view of your
type of lead. current situation, (lead owner). If customers and facilitates
product of interest, automatic collaboration across your
For example: timeframe, key assignment is organization, helping
Day 1: Personalize decision makers. needed use you build strong, lasting
mass email custom package customer relationships.
If the lead is workflow rules.
Day 2: Call/
voicemail qualified, convert
it to a contact, Monitor your
Day 3: Call/ opportunities
with an associated
voicemail reports and
opportunity
Day 4: Personalize and account. dashboards to keep ARCHIVE YOUR DEAD OPPORTUNITIES
mass email track of top deals
and Use email marketing and call downs to
re-market to Closed Lostopportunities
prioritize your time.
 Service Cloud Cheatsheet

WEBSITE, SOCIAL,
ONLINE COMMUNITIES WEB-TO-CASE & MORE

• Website visits • Support inquiries

• Social mentions • Private questions
• Community posts

CREATE OR SUPPORT
CALLS UPDATE CASES CASE CREATION PROCESSES ENTITLEMENTS

• Incoming calls • Search in Salesforce • Set up auto-response Define case Enhance

and update open emails statuses to and enforce
cases orcreate a new • Direct to self- support your your support
case service options process. Create processes. Verify
multiple processes if yourcustomers
• Smart routing
as needed. are eligible for
– Evenly distribute cases
support. Specify
to qualified agents
Service Level
EMAILS, CHATS, EMAIL-TO-CASE • Set up queues Agreements
& MORE & MORE and case (SLA) for each
assignment rules customer.
• Incoming emails • Automatically create – Channel
• Incoming chats cases from emails & – Product
• Video calls &more incoming chats – Geography

Marketing

Support
ESCALATION REPORTS AND
RULES DASHBOARDS KNOWLEDGE CTI COMMUNITIES CONSOLE LIVE AGENT
FEATURES

Automatically Track Key Centralized, Make and receive Provide your Gain a 360-degree Skills
escalate cases open Performance searchable calls right from customers with an view of your
beyond a certain Indicators (KPI) repository of Salesforce with online experience Branding
customers with a
period of time or and important up-to-date content. integrated where they can Save Transcript
user experience
where an SLA service metrics Make articles softphone controls. ask questions, Sneak Peek
designed for fast-
has expired. including average accessible to access articles, and paced environments. File Transfer
resolution time, employees and connect with each Users can toggle Assistance flag
first call resolution, customers. other. Promote case between tabs,
and customer Chat transfer &
deflection while collaborate in
satisfaction. conferencing
providing a rich self- context, and build
service experience. Quick text
lasting relationships
with customers.
 Forecasting
Forecasts can be used to predict future sales within an organization. Forecast data is aggregated from each user’s
opportunity records, and the related forecast category of each opportunity’s stage.

The advantage of Salesforce.com Forecasting is that it’s relatively easy for a sales rep to maintain an accurate
representation of an opportunity’s status. The software adds up the numbers and produces a forecast based on the
close dates of opportunities. Further, Salesforce.com populates pipeline dashboards and allows management to
visualize, analyze, optimize and prioritize.

The disadvantage of using pipeline reports as a forecasting tool is that inconsistent and inaccurate opportunity
updates by sales reps can severely affect data integrity. Adding to the problem are mutated methodologies and a
rep’s desire to maintain the 3:1 pipeline ratio requested by management.

Customizable forecasting Collaborative forecasting

Used for customizing the forecast for the needs of Provides your business with more flexibility and
your business. This kind of forecasting is used for more intuitive user interface. The unique features of
custom fiscal year, opportunity lead adjustments, this kind of forecasting include ability to rename the
territory management, snapshots and forecast forecast categories, expandable forecast tables and
history forecasting on the opportunity splits

• Product Family Forecasts • Forecast revenue and/or quantity based on

• Opportunity Products Schedule Forecasts opportunity data
• Forecast Sharing • Forecast viewable in monthly or quarterly rollups
• Forecast Snapshots & History • Customizable forecast categories
• Opportunity-level Adjustments • Mutually exclusive forecast categories
• Opportunity Product Level Adjustments • Forecast numbers and related Opportunities on the
• Ability to Override Forecast Category same page
• Ability for Sales Reps to adjust their Forecast • Manager ability to adjust forecasts
• Revenue or quantity quotas for sales teams (via
API only)
• Ability to create Custom Report Types & Custom
Reports on Forecast, Opportunity & Quota data
• API support
• Interactive and easy user experience

Territory Management
Territory management is an account sharing system that grants access to accounts based on the characteristics of the
accounts. It enables your company to structure your Salesforce data and users the same way you structure your sales
territories.
Particularly if your organization has a private sharing model, you may need to grant users access to accounts based on
criteria such as postal code, industry, revenue, or a custom field that is relevant to your business. You may also need to
generate forecasts for these diverse categories of accounts. Territory management solves these business needs and
provides a powerful solution for structuring your users, accounts, and their associated contacts, opportunities, and cases.
Accounts and users can belong to multiple territory, while an opportunity can belong to only one territory.

Account ownership and its effect on record sharing remains valid and unchanged when territory management is in use.

Original Territory Management is available only with Customizable Forecasts and is not supported with Collaborative
Forecasts. If original Territory Management is enabled, you can no longer use Collaborative Forecasts. The newer
Enterprise Territory Management can’t be used with Customizable Forecasts. Enterprise Territory Management and
Collaborative Forecasts can both be enabled and used at the same time in your Salesforce organization, but the two
features are not currently integrated to work together.

A territory model represents a complete territory management system for your organization. Modeling lets you create and
preview multiple territory structures and different account and user assignments before you activate the model that works
best.
Both Territory management sharing and role hierarchy sharing can be active at the same time. Users will receive whatever
access is most permissive across both hierarchies.
 Chatter Licenses
Salesforce Licenses
Identity Licenses

Other Licenses
Salesforce Data Model
Encryption methods
CLASSIC ENCRYPTED FIELDS

• Only Text (Encrypted) field type is supported

• Only users with the permission “View Encrypted Data” can see data and clone th evalue
• Cannot be unique, have an external ID, or have default values.
• For leads are not available for mapping to other objects.
• Are limited to 175 characters because of the encryption algorithm.
• Are not available for: Salesforce Mobile Classic, Connect Offline, Salesforce for Outlook, lead conversion, workflow
rule criteria or formulas, formula fields, outbound messages, default values, and Web-to-Lead and Web-to-Case
forms.
• Existing custom fields cannot be converted into encrypted fields nor can encrypted fields be converted into another
data type.
SHIELD PLATFORM ENCRYPTION

• Gives your data a whole new layer of security while preserving critical platform functionality.
• Data stored in many standard and custom fields and in files and attachments is encrypted using an advanced HSM-
based key derivation system
• You can reference encrypted fields in most places in your flows and processes.
• You can encrypt certain fields on the Account, Contact, Case, and Case Comment objects.
• You can encrypt custom fields of type email. Phone, url , datetime and all text type fields
• Only users with the “View Encrypted Data” permission can see the contents of encrypted fields
• Not supported by many SF Apps (Heroku, SF CPQ, Data.com, Marketing Cloud)
Object relationship types
Master-detail
• Closely links objects together such that the master record controls certain behaviors of
the detail and subdetail record.
• Detail and subdetail records inherit security settings and permissions from the master
record. You can’t set permissions on the detail record independently.
• The Owner field on the detail and subdetail records is not available and is
automatically set to the owner of the master record. Custom objects on the “detail”
side of a master-detail relationship can't have sharing rules, manual sharing, or
queues, as these require the Owner field.
• The master-detail relationship field (which is the field linking the objects) is required
on the page layout of the detail and subdetail records.
• Deleting a detail record moves it to the Recycle Bin and leaves the master record
intact; deleting a master record also deletes related detail and subdetail records.
Undeleting a detail record restores it, and undeleting a master record also undeletes
related detail and subdetail records. However, if you delete a detail record and later,
separately, delete its master record, you cannot undelete the detail record, as it no
longer has a master record to relate to.

Lookup
• Links two objects together. Lookup relationships are similar to master-detail
relationships, except they do not support sharing or roll-up summary fields.
• Can be required, prevent deletion and cascade delete if setup

External lookup
• An external lookup relationship links a child standard, custom, or external object to a
parent external object.
• The standard External ID field on the parent external object is matched against the
values of the child’s external lookup relationship field. External object field values come
from an external data source.

Indirect lookup
• Links a child external object to a parent standard or custom object.
• When you create an indirect lookup relationship field on an external object, you specify
the parent object field and the child object field to match and associate records in the
relationship. Specifically, you select a custom unique, external ID field on the parent
object to match against the child’s indirect lookup relationship field, whose values come
from an external data source.

Hierarchical
• A special lookup relationship available for only the user object. It lets users use a lookup
field to associate one user with another that does not directly or indirectly refer to itself.
For example, you can create a custom hierarchical relationship field to store each user's
direct manager.

Many to many
• Created by creating a junction object with 2 master-detail or lookup relationships
Different ways to manage files & content
Apex transaction Limits
Organization strategy
An org strategy is a plan of how to best use Salesforce with your business. It outlines the
underlying org architecture that will be used in your Salesforce solution. Two possible approaches:
• Single-Org
• Multi-Org

Approach Pros Cons

Single-Org Cross business unit collaboration Org complexity could become a barrier to
Salesforce Chatter shared in the progress
organization Potential to hit specific Org limits, such as
Aligned processes, reports, number of custom tabs, objects and code
dashboards, security – consolidated lines
customization Org-wide settings could become difficult to
Ability to share data govern and manage
Unified reporting Time to market and innovate could be
Single login to access multiple impacted by number of teams rolling out
business functions new functionality
360 view from a central point of view More teams updating shared configuration
– overall reports possible and code means more regression testing is
Interfaces are easier to maintain needed as complexity increases over time
Fewer sandbox environments reduces
testing capabilities
Local administration is difficult
Multi-Org Logical Separation of data Harder to get a clear global definition of
Reduced risk of exceeding Org limits processes and data
Org-wide settings are easier to be Less reuse of configuration and code
governed and managed. Lower data Solutions for shared common business
volumes within a single Org – requirements need to be deployed into
potentially improves performance multiple Orgs
Improved time to market and freedom Inferior collaboration across business units
to innovate (no shared Chatter)
Fewer teams impacted by shared Duplicated administration functions required
updates Increased complexity for single sign on
Reduced complexity within a single Merging/Splitting Orgs and changing
Org integration endpoints is very difficult.
More sandbox environments means The administration is extensive for
more testing capabilities configurations which cannot be deployed by
Local administration and customization automated processes. (deployment strategy
possible needed)

The multi-org strategy can be declined in different approaches:

1. Complete Autonomy
• each organization is not directly linked to each other environment
2. Master Child
• a master org pushes a subset of data to all child linking organizations
3. No centralized org
• each organization is directly linked to other organizations using
Salesforce2Salesforce integration for exchanging and updating data
Sandbox strategy
 Asynchronous Apex

Apex Unit tests

• At least 75% test coverage is required

• Every trigger must have some test coverage.
• All classes and triggers must compile successfully.
• Classes and methods defined as @isTest can be either private or public.
• Classes defined as @isTest must be top-level classes and can't be interfaces or enums.
• Methods of a test class can only be called from a running test, that is, a test method or code
invoked by a test method, and can't be called by a non-test request.
• Test methods can’t be used to test Web service callouts. Instead, use mock callouts.
(Test.setMock + HttpCalloutMock, WebServiceMock interface)
• You can use @testVisible to enable access to private methods
• Annotate your test class or test method with IsTest(SeeAllData=true) to open up data access to
records in your organization.
• Use test setup methods (methods that are annotated with @testSetup) to create test records
once and then access them in every test method in the test class.
• The runAs method enables you to write test methods that change the user context to an existing
user or a new user so that the user’s record sharing is enforced. You can also use the runAs
method to perform mixed DML operations in your test by enclosing the DML operations within the
runAs block.
• You can use Test.startTest and Test.stopTest to manage governor limits consumption
Deployment methods
Tool Best for Limitations
Change Sets • Straight sandbox to production migrations
• Change management without using a local file system
• Auditing previously deployed changes
• Enforcing code migration paths
• Deploying the same components to multiple orgs

Ant Migration Tool • Development projects for which you need to populate a
test environment with a lot of setup changes—Making
these changes using a web interface can take a long time.
• Multistage release processes—A typical development
process requires iterative building, testing, and staging
before releasing to a production environment. Scripted
retrieval and deployment of components can make this
process much more efficient.
• Repetitive deployment using the same parameters—You
can retrieve all the metadata in your organization, make
changes, and deploy a subset of components. If you need
to repeat this process, it’s as simple as calling the same
deployment target again.
• When migrating from stage to production is done by IT—
Anyone that prefers deploying in a scripting environment
will find the Ant Migration Tool a familiar process.
• Scheduling batch deployments—You can schedule a
deployment for midnight to not disrupt users. Or you can
pull down changes to your Developer Edition org every
day.

Force.com IDE • Project-based development • Some setup required

• Deployment to any org • Not always upgraded at the same time as
• Synchronizing changes other Salesforce products
• Selecting only the components you need • Repeatable deployments require re-
selecting components, which can be time
consuming and introduce errors

Force.com • Ad hoc queries • Not an officially supported product

Workbench • Deploy or retrieve components with a package.xml file • No project management features
• Metadata describes
• Lightweight data loads
Force.com CLI • Scripted commands and automated tasks • Logging in can be difficult behind a firewall
• When your security policies dictate that passwords must
not be stored on disk; forces interactive login

Unmanaged • One-time setup of a development environment • You can’t make further changes to
Packages • A starting point configuration that can be customized packaged components using subsequent
packages
• Requires a Developer Edition org

Managed Packages • Commercial applications • Access to code is limited or hidden

• Functionality you want to add in multiple, possibly non- • Unique namespace can be bothersome or
related orgs a blocker
• Difficult to modify or delete components
• Requires a Developer Edition org
Support multiple languages
• An administrator can enable multiple languages in setup. Every language has to be enabled separately
• Standard objects and fields are translated automatically and translations can be edited in „Rename tabs &
labels” interface
• Use Translation Workbench to maintain your translated labels in your org. You can manage translated
values for any Salesforce supported language.
• Almost everything can be translated including object names, field labels, picklist values, validation
messages, etc.
• If a customized component doesn’t have a translated value, the component uses the org’s default language.
When you deactivate a language, all translations for that language are still available in the Translation
Workbench, but users with that language selected see the org’s default language values.
• Translations can be exported and imported from a file

Multi-Currency
• By default, Salesforce organizations use a single currency. Once you set the required currency locale in your
company settings, all currency values on records display in that currency.
• Once you activate multicurrency for your org, you can specify which currencies are supported by activating
or deactivating them
• Every record has a Currency field that specifies the currency type for amounts in that record. All currency
amounts display in the record’s currency and are also converted to the personal currency of the record
owner, based on the conversion rates entered by your administrator. Amounts in the user’s personal
currency are displayed in parentheses
• Amounts in reports are shown in their original currencies, but can be displayed in any active currency
• An administrator can modify conversion rates in Setup. By default, previous conversion rates are not stored
and all conversions within opportunities, forecasts, and other amounts use the current conversion rate.
• Advanced currency management allows you to manage dated exchange rates within opportunities using
Salesforce
• Dated exchange rates are used for opportunities, opportunity products, opportunity product schedules,
campaign opportunity fields, opportunity splits, and reports related to these objects and fields. Dated
exchange rates are not used in forecasting, currency fields in other objects, or currency fields in other types
of reports.
• Cross-object formulas always use the static conversion rate for currency conversion.

Protecting Custom Sharing Code

• Sharing records with „Manual” row cause sharing reason are deleted on record owner change
• Sharing records via custom code can be protected by:
• Using Apex Sharing Reasons (supported on custom objects only)
• Using Outbound Messaging to external system which will restore sharing
• Using a Trigger which calls an Assignment engine built on Salesforce (CoreSite SM)
• Using a Shadow Sharing Table with a trigger
Testing Types
Testing type Description When & where
Unit testing The process of testing each unit of code in a single During development on a
component. This testing is carried out by the developer as developer environment
the component is being developed.

Code review Systematic examination of computer source code. It is At the moment of

intended to find mistakes overlooked in software merging, commiting code
development, improving the overall quality of software. on a developer
Reviews are done in various forms such as pair environment
programming, informal walkthroughs, and formal
inspections.

Functional Testing A type of black-box testing that bases its test cases on the After development of a
specifications of the software component under test. certain piece of
Functional testing usually describes what the system does. functionality, on the QA
environment

Integration testing Testing the interface between the modules; it can be top After merging multiple
down, bottom up, big bang. functionalities or features
on the CIT environment

System Integration A high-level software testing process in which testers verify SIT phase on the SIT
testing that all related systems maintain data integrity and can environment
operate in coordination with other systems in the same
environment. The testing process ensures that all
subcomponents are integrated successfully to provide
expected results.

User Acceptance Last phase of the software testing process. During UAT, UAT phase on the UAT
testing actual software users test the software to make sure it can environment
handle required tasks in real-world scenarios, according to
specifications.

Performance Includes Stress and Load testing. Coordinated with Scheduled during
testing Salesforce,. Done using LoadRunner, SilkPerformer, Red development, SIT, UAT
View, ...

Smoke testing Preliminary testing to reveal simple failures severe enough After deployment to any
to reject a prospective software release environment

Regression testing A type of software testing that ensures that previously After deployment to any
developed and tested software still performs the same environment
way after it is changed or interfaced with other software

Data migration Testing that data is correctly migrated and that data UAT or Staging phase on
testing integrity is maintained between systems. the UAT or Staging
environment
Salesforce Sharing Methods
Method Description

Profiles A profile is a group/collection of settings and permissions that define what a user can do in salesforce. A
profile controls “Object permissions, Field permissions, User permissions, Tab settings, App settings,
Apex class access, Visualforce page access, Page layouts, Record Types, Login hours & Login IP ranges.
Permission Sets Very similar to profile. The main difference between these two is that user can have only one profile
and can have multiple permission sets at time. In such case, most permissive setting applies.
Organization Wide Organization-wide sharing defaults set the baseline access for your records. Options include Private,
Defaults Public Read Only, Public Read/Write and Controlled By Parent
Role Hierarchy Represents a level of data access that a user or group of users needs. Users assigned to roles near the
top of the hierarchy get to access the data of all the users who fall directly below them in the hierarchy.
Sharing rules Automatic exceptions to your organization-wide sharing settings for defined sets of users. Standard way
to open up record access.
Sharing Sets Grants high-volume users access to any record associated with an account or contact that matches the
user’s account or contact. You can also grant access to records via access mapping in a sharing set,
which supports indirect lookups from the user and target record to the account or contact. For example,
grant users access to all cases related to an account that’s identified on the users’ contact records.
Sharing Groups Allow you to share records owned by high-volume community users with internal and external users in
your communities.
Partner Super Users Partner Super Users have access to data owned by their peers (same role). Partner super user access
applies only to cases, leads, custom objects, and opportunities.
Public Groups A group consists of a set of users. A group can contain individual users, other groups, or the users in a
particular role or territory. It can also contain the users in a particular role or territory plus all the users
below that role or territory in the hierarchy.
Queues Queues help you prioritize, distribute, and assign records to teams who share workloads. Queue
members and users higher in a role hierarchy can access queues from list views and take ownership of
records in a queue.

Use queues to route lead, order, case, and custom object records to a group.
Teams For accounts, opportunities, and cases, record owners can use teams to allow other users access to
their records. A team is a group of users that work together on an account, sales opportunity, or case.
Record owners can build a team for each record that they own. The record owner adds team members
and specifies the level of access each team member has to the record, so that some team members can
have read-only access and others can have read/write access. The record owner can also specify a role
for each team member, such as “Executive Sponsor.” In account teams, team members also have access
to any contacts, opportunities, and cases associated with an account.
Terrirory An account sharing system that grants access to accounts based on the characteristics of the accounts
management
Implicit sharing Sharing not configured by administrators; it is defined and maintained by the system to support
collaboration among members of sales teams, customer service representatives, and clients or
customers. Includes Parent, Child, Portal and High Volume
Manual sharing Sharing done directly by record owners by clicking the Share button

Apex managed Sharing generated through Apex by creating records in the Sharing objects
sharing
Salesforce Sharing Illustrated
Sharing Architecture

Restricting Org Access

Method Description

My domain Select a login policy to prevent users from logging in with the generic
https://<instance>.salesforce.com/ login page and then being redirected to your
subdomain URLs after login. Supports branding and SSO.
Login IP ranges Control login access at the user level by specifying a range of allowed IP addresses on a
user’s profile. When you define IP address restrictions for a profile, a login from any other
IP address is denied.
Login IP hours Specify the hours when users can log in based on the user profile.

Two-Factor For each profile, you can require a verification code (also called a time-based one-time
Authentication password, or TOTP) instead of the standard security token. Users connect an authenticator
app that generates verification codes to their account.
Trusted IP Ranges Define a list of IP addresses from which users can log in without receiving a login challenge
for verification of their identity, such as a code sent to their mobile phone or token.
Continuous Integration Strategy & tools
ETL & ESB integration
ETL tools support the process of Extracting, Transforming and Loading large volumes of data from multiple data
sources. Used for batcch, scheduled or ad-hoc data operations. They can be used to perform data migration or
data integration. Some examples include Talend, Informatica, Jitterbit, Data migrator, etc.

An enterprise service bus (ESB) is a middleware tool used to distribute work among connected components of
an application. ESBs are designed to provide a uniform means of moving work, offering applications the ability to
connect to the bus and subscribe to messages based on simple structural and business policy rules. The most
often used ESB is MuleSoft.

When to use ESB:

• When system integration points grow beyond two, with additional integration requirements.
• When using multiple protocols such as FTP, HTTP, Web Service, and JMS etc.
• When there is a requirement for message routing based on message content and similar parameters.

How an ESB architecture maps to our five core integration principles:

• Orchestration: Composing several existing fine-grained components into a single higher order composite
service. This can be done to achieve appropriate "granularity" of services and promote reuse and
manageability of the underlying components.
• Transformation: Data transformation between canonical data formats and specific data formats required by
each ESB connector. An example of this would be transforming between CSV, Cobol copybook or EDI formats
to either SOAP/XML or JSON. Canoncial data formats can greatly simplify the transformation requirements
associated with a large ESB implementation where there are many consumers and providers, each with their
own data formats and definitions.
• Transportation: Transport protocol negotiation between multiple formats (such as HTTP, JMS, JDBC). Note:
Mule treats databases like another "service" by making JDBC just another transport (or endpoint) where data
can be accessed.
• Mediation: Providing multiple interfaces for the purpose of a) supporting multiple versions of a service for
backwards compatibility or alternatively, b) to allow for multiple channels to the same underlying component
implementation. This second requirement may involve providing multiple interfaces to the same component,
one legacy interface (flat file) and one standards compliant (SOAP/XML) interface.
• Non-functional consistency: For a typical ESB initiative, this can include consistency around the way security
and monitoring policies are applied and implemented. Additionally, the goals of scalability and availability can
be achieved by using multiple instances of an ESB to provide increased throughput (scalability) and eliminate
single-points-of-failure (SPOFs), which is the key objective for highly available systems.
Account models
B2C account models
Model Description

Person Accounts Person accounts store information about individual people by combining certain
account and contact fields into a single record. Has some limitations and can not be
reverted.
Private Contact Allows Contacts to be created without accounts. Not recommended as an B2C model

Household model The standard Salesforce Account object acts as the household, with numerous
contacts and opportunities associated with it. Default and recommended for NPSP.
1-to-1 Account Model Works by creating an Account object for each Contact you create. The Account is
automatically created when you create a Contact, and the name of the new Account is
identical to the name of the new Contact. The Account object itself, however, acts
"invisibly" behind the scenes, and exists for the sole purpose of conforming to the
standard Salesforce Account model (which requires all Contacts be associated with an
Account).
The Bucket model All Contacts are associated with a single Account, as if all of your contacts have been
dumped in one "bucket".

Account Hierarchy models

Model Description

Global Enterprise Establish one global account and link all contacts, opportunities, cases, and so on to
Account that single overarching account. Using one global account makes it easy to find that
account’s records and to report on that account at the enterprise level. But it’s harder
to manage a large mass of information, and not being able to easily view the big
picture might make it hard to see what each location needs from you for your
relationship to be successful.
Location-Specific Establish accounts for each location and create contacts, opportunities, cases and so
Accounts on separately for each location. With this option, you maintain more accounts and
need to set up a few more complex reports to get the big picture. But using multiple
accounts means you can take advantage of account ownership, hierarchies, specific
sharing settings, and more granular reporting. You can also more easily track and
report on opportunities, cases, and other interactions for each account.

Contacts to multiple Accounts models

Model Description

Account Contact Roles Standard salesforce solution. Does not support custom fields, layouts, validation,
workflow, triggers, record types, field history, etc. Sharing is derived from Account.
Contacts to Multiple Standard salesforce solution. Supports custom fields, layouts, validation, workflow,
Accounts triggers, etc. Supports record types and field history. Sharing is derived from Account
and Contact
Custom Junction Create a custom object to connect a Contact with multiple Accounts. Supports all
Object features, but requires custom development.
Data migration & Backup
Data Loading best practices:
• Use BULK API for more that a few thound records
• Use the fastest operation Insert > Update > Upsert
• Use Public Read/Write security to avoid sharing calculation
• Disable triggers, workflow rules and validation
• Some fields might be transformed during migration (id, autonumber, audit fields)
• When changing child records, group them by parent Id
• Use defer-sharing
• Activate sharing rules after loading and one at a time
• Audit fields can be populated only on insert.

Backup types:
• Full
• Incremental
• Partial

Data archiving options:

• BigObject
• Outside of Salesforce
• Weekly export
• Data loader
• Reporting snapshot

Data governance & stewardship

Data governance is a process to ensure usability, quality, and policy compliancce of the data asset. It includes
business definitions, data quality and security rules, supports UI and integration design.
It defines what is collected, how is it kept secured, who can CRUD, what quality rules are there, how available and
usable is the data, ...

Data stewardship is a cross-functional tactical role and activities to ensure adherence to data governance rules and
spirit. It includes data quality monitoring, work flow, and maintenance.

Mastar data management is the effort made by an organization to create one single master reference source for all
critical business data, leading to fewer errors and less redundancy in business processes. It consists of 3 pillars:
Mastering data, Mastering data relationships and Mastering events.

Understand the linear flow of data:

How are records generated?
Why are they created?
What are they used for?
What is reported on?
Where is the hand-off?
Methods to provision users
Method Description

Manual provisioning A user is created manually by an administrator.

API provisioning Provision users by using the SOAP or REST API on the User object.

Programmatic provisioning Povision users in Apex code.

JIT provisioning with SAML Use a SAML assertion to create regular and portal users on the fly the first
time they try to log in. This eliminates the need to create user accounts in
advance. A user is created when he logs in via SSO.
Mass user provisioning Create a large number of users by using Bulk API, Data Loader or an ETL tool.

Identity connect with AD Integrates Microsoft Active Directory (AD) with Salesforce. User information
entered in AD is shared with Salesforce seamlessly and instantaneously.
Companies that use AD for user management can use Identity Connect to
manage Salesforce accounts. Changes in AD are reflected in Salesforce in
near real time.
Self-registration Users can self-register when first visiting the site. Works with community
users only.
Social sign-on provisioning Users can sign in using a social site credentials. Supported sites include
LinkedId, Facebook, Twitter, Google, Janrain, Salesforce, and any srevice
who implements the OpenID Connect protocol or Oauth. Works with
community users only.

Single Sign On Methods

Method Description

SSO with multiple Orgs SSO between multiple Salesforce orgs. Can be enabled in Setup for both
orgs. Works only with internal users.
SSO with AD Salesforce is integrated with AD using Identity Connect or ADFS

Social Sign On Sign on via a Social site credentials. Works with community users only.

Federated Authentication The platform receives a SAML assertion in an HTTP POST request. The SAML
assertion has a limited validity period, contains a unique identifier, and is
digitally signed. If the assertion is still within its validity period, has an
identifier that has not been used before, and has a valid signature from a
trusted identity provider, the user is granted access to the application. If the
assertion fails validation for any reason, the user is informed that their
credentials are invalid.
Delegated Authentication An internal WS authenticates users. It receives an username, password and
sourceIP and returns true or false.
*Never enable SSO for Admin users
Data quality and duplicate management

Data quality attributes:

• Age
• Completeness
• Accuracy
• Consistency
• Duplication
• Usage

Best data quality and archiving policy is defined at design time.

Use data quality scoring and reporting.

How to safely delete data:

1. Isolate suspects
2. Flag for elimination and color code
3. Hide with security
4. Wait (around 3 months)
5. Backup
6. Delete

Deduplication step order:

1. Accounts vs Accounts
2. Contacts within Account
3. Contacts between Accounts
4. Accounts vs Accounts
5. Leads
6. Leads to Contacts

Data quality tools:

• Data.com (works on Accounts, Contacts, and Leads)
• Duplicate rules (works on Account, Lead, Contact, and Custom object)
• Merging records (works on Accounts, Contacts, and Leads)

Archival strategy options:

1. In place archiving – Storage objects, record archived indicator
2. External archiving – on premise DWH, external cloud solution ,flat file
archiving
3. Hybrid solution – data tiering
Two factor Authentication
As a Salesforce admin, you can enhance your org’s security by requiring a second level of authentication for every user
login. You can also require two-factor authentication when a user meets certain criteria, such as attempting to view reports
or access a connected app.

When a user logs in from outside a trusted IP range and uses a browser or app we don’t recognize, the user is challenged to
verify identity. We use the highest-priority verification method available for each user. In order of priority, the methods
are:
1. Verification via push notification or location-based automated verification with the Salesforce Authenticator
mobile app (version 2 or later) connected to the user’s account.
2. Verification via a U2F security key registered with the user’s account.
3. Verification code generated by a mobile authenticator app connected to the user’s account.
4. Verification code sent via SMS to the user’s verified mobile phone.
5. Verification code sent via email to the user’s email address.
6. Login Flows

After identity verification is successful, the user doesn’t have to verify identity again from that browser or app, unless the
user:
• Manually clears browser cookies, sets the browser to delete cookies, or browses in private or incognito mode
• Deselects Don’t ask again on the identity verification page

Managed packages to propose

Use Case Package/solution

Document generation Conga Composer

WebMerge
Drawloop
eSignature Docusign
EchoSign
ESB Mulesoft
CPQ Salesforce CPQ
CloudSense CPQ
Marketing Marketing Cloud
Marketo
Accounting FinancialForce
Intaact
Analytics Wave analytics

Cloud Data storage Heroku

and long operations AWS
Document Storage Box
Google Drive
SharePoint
DropBox
CRM Content
Mobile Strategy Decision

Native HTML5 Hybrid Salesforce App

Graphics Native APIs HTML, Canvas, HTML, Canvas, Standard
SVG SVG Salesforce +
Visualforce
Performance Fast Slow Slow Slow
Native look and feel Native Emulated Emulated Emulated(VF)
Distribution Appstore Web Appstore Appstore
Camera Yes No Yes No
Notifications Yes No Yes No
Contacts, Calendar Yes No Yes Yes
Offline storage Secure file Shared SQL Secure file Yes
storage system, shared
SQL
Geolocation Yes Yes Yes Yes
Swipe Yes Yes Yes Yes
Pinch, spread Yes No No No
Connectivity Online and offline Mostly online Online and offline Mostly online

Development skills ObjectiveC, Java HTML5, CSS, HTML5, CSS, Visualforce

Javascript Javascript
Cross-Platform No Yes Yes Yes
Easy to deploy No Yes No Yes
Fully customisable UI Yes Yes Yes No
Speed of Development Slow Medium Medium Fast
Salesforce Communities

Community templates:
• Visualforce + Tabs
• Customer Service (Napili)
• Kokua & Koa
• Lightning Communities
• Partner Central
• Customer Account Portal

Rollout Strategy phases:

• Establish
• Manage
• Engage
• Measure

Branding options:
• Select color scheme
• Customize emails
• Logo
• Login page
• Custom domain (my domain)
Project methodology
Agile vs Waterfall

Methodology Artifacts
• Centralized Communication/Collaboration/Documentation repository
• Requirements management from Business Requirements traced all the way through test cases and deployed
technical components
• Governance levels (Steering committee, Center of Excellence, Architectural Review board with a detailed
understanding of interdependency between groups)
• Quality Control (Development of Technical Design Standards, Common Usability Requirements, Peer Review,
Code Review, Deployment checklist, etc.)
• Thorough testing strategy with as much automation that can reasonably be built
• Dependency management through PMO, scrum teams, scrum of scrums, status reports, risk & issue management
• Key Tools:
o Project management software (MS Project, Agile Accellerator)
o Requirements Repository (Rally, Jira, Excel)
o Traceability Matrix
o Test Suite Management (allows to track tests against requirements)

Center of Exellence
• A team of knowledgeable and experienced business process management, customer relationship management,
and business domain experts equipped with an arsenal of best practices and tools. At its most mature state, it is a
highly formalized and self-directing entity that is responsible for supporting business users and shepherding even
the most complex projects to successful completion. The COE promotes the use of business process management
as means of linking an organization’s strategy to their day to day operations.
• A cross-functional team looking both inside and outside the organisation to capture new knowledge and practices
• Scope: Charter, Business backlog, technology release management, communications
• Structure: Consolidated, federated, hybrid
• Roles and responsibilities: Release, business, scrum teams, architectural, training, support
• Key roles: Business Analyst, Enterprise Architect, Project Management Office
• Best Practice Centers – These are the “sharers,” focusing on creating environments where business units can
collaborate with each other on like-minded processes and technologies, designed to more rapidly enable lines of
business.
• DevOps Centers – These are the “doers,” focusing on providing a shared service to scope, design, develop, and
deliver across with optimal IT governance, designed to foster standardization and reuse.
• Competency Centers – These are the “guiders”, focusing on establishing best practices and standards to enable,
build competency, and embed expertise within individual lines of business through the creation of targeted
improvement agendas.
• Innovation Centers – These are the “creators,” focusing on the incubation and experimentation required to
develop the capabilities with (emerging) technologies, designed to accelerate maturity and time to value.
Chatter features
Feature Description

Connect to Business Create support cases, update sales opportunities, and approve
Processes project funds — all from within the community. Connect data and
records to internal systems to maximize efficiency and eliminate
errors.
Actions Approve expense reports, create support cases, update orders, and
more, all from the feed. Customize actions, integrating third-party
or your own custom apps with full social and mobile capability.
Mobile Post to a group, download a file, or update a service case or sales
opportunity using the Salesforce mobile app from any device. Use
custom mobile actions to drive progress forward, wherever you are.
Engagement Engage your organization to participate. Contribution scores give
employees incentives to join the conversation, while badging and
endorsements highlight the key contributors.
Groups Structure a discussion and activity. Create groups for your team, an
event, a new account, or a campaign. Share files and records,
integrate video, and even invite customers. Private groups protect
discussions.
Polls Assess employee opinions on any topic, at any time. Anyone can
post a poll to a group for feedback on a specific subject, or connect
with the broader organization to gauge popular sentiment.
Rich Feeds Do it all in the feed. Keep up with critical projects, topics, and
teams. Post files, videos, images, and other assets. Even collaborate
on sales opportunities, service cases, and marketing campaigns.
Topics Present the most up-to-date content on any subject discussed in
the community. Topics automatically collect relevant posts and
answers, suggest groups, experts, files, and other related resources.
Recommendations No need to search for information, people, or files. Chatter uses
your interests and activity to update content on subjects, projects,
or products and sends it to your personalized feed or profile page.
Salesforce Files Secure, social, and mobile file sharing puts the files you need, and
new resources, right in your feed. Unlock and securely sync files to
any mobile device from third-party repositories with Files Connect.
Answers Collect answers to common questions and structure them so
employees quickly find the information they need. Highlight
questions about internal processes, projects, products, or any
subject you need.
Presentation outline
Slide Description
Title
Agenda
About me Short bio
About the company Who is the client
Requirements A detailed list of all requirements
Assumptions
Actors & licenses
System landscape Diagram
Integrations Explanation of integartion methods
Data model Diagram
Role hierarchy Diagram
Mobile application Native vs Hybrid vs Html5 vs SF1
Communities Customer or Partner
Authentication methods Standard, SSO, Social Sign-On
LDV mitigation Which objects, volume, mitigation strategy
Reporting Object, reporting method
Other Salesforce features used Workflow rules, Profiles, Permission Sets, OWD,
Outbound messaging, Assignment rules, Escalation rules,
Lead conversion, Process builder, territory management,
sharing rules, CRM Content, Translations, ...
Data migration Objects, Systems, process
Project management & Agile vs Waterfall
governance
Methodology artifacts Teams, documents, process
Development strategy CI, Solution design, tools
Sandbox structure Which sandboxes will be used
Testing strategy Which tests will we do & when
Risks & mitigation strategies Other risks
Thank you, Q&A
Other Security features
Certificates and Keys
Salesforce certificates and key pairs are used for signatures that verify a request is coming from
your organization. They are used for authenticated SSL communications with an external web
site, or when using your organization as an Identity Provider. You only need to generate a
Salesforce certificate and key pair if you're working with an external website that wants
verification that a request is coming from a Salesforce organization.
Certificates can be self-signed or signed by an authorization authority.

Named credentials
A named credential specifies the URL of a callout endpoint and its required authentication
parameters in one definition. To simplify the setup of authenticated callouts, specify a named
credential as the callout endpoint. If you instead specify a URL as the callout endpoint, you must
register that URL in your org’s remote site settings and handle the authentication yourself. For
example, for an Apex callout, your code would need to handle authentication, which can be less
secure and especially complicated for OAuth implementations.

WSDL Types
Enterprise WSDL:
a) The Enterprise WSDL is strongly typed which makes it easier to use
b) The Enterprise WSDL is tied (bound) to a specific configuration of Salesforce (ie. a
specific organization's Salesforce configuration).
c) The Enterprise WSDL changes if modifications (e.g custom fields or custom objects) are
made to an organization's Salesforce configuration.

For the reasons outlined above, the Enterprise WSDL is intended primarily for Customers.

Partner WSDL:
a) The Partner WSDL is loosely typed which makes it harder to use
b) The Partner WSDL can be used to reflect against/interrogate any configuration of
Salesforce (ie. any organization's Salesforce configuration).
c) The Partner WSDL is static, and hence does not change if modifications are made to an
organization's Salesforce configuration.

For the reasons outlined above, the Partner WSDL is intended primarily for Partners.
Reports and Dashboards
Report formats
Format Description

Tabular Tabular reports are the simplest and fastest way to look at data. Similar to a spreadsheet,
they consist simply of an ordered set of fields in columns, with each matching record listed in
a row. Tabular reports are best for creating lists of records or a list with a single grand total.
They can't be used to create groups of data or charts, and can't be used in dashboards unless
rows are limited.
Summary Summary reports are similar to tabular reports, but also allow users to group rows of data,
view subtotals, and create charts. They can be used as the source report for dashboard
components. Use this type for a report to show subtotals based on the value of a particular
field or when you want to create a hierarchical list, such as all opportunities for your team,
subtotaled by Stage and Owner. Summary reports with no groupings show as tabular reports
on the report run page.
Matrix Matrix reports are similar to summary reports but allow you to group and summarize data by
both rows and columns. They can be used as the source report for dashboard components.
Use this type for comparing related totals, especially if you have large amounts of data to
summarize and you need to compare values in several different fields, or you want to look at
data by date and by product, person, or geography. Matrix reports without at least one row
and one column grouping show as summary reports on the report run page.
Joined Joined reports let you create multiple report blocks that provide different views of your data.
Each block acts like a “sub-report,” with its own fields, columns, sorting, and filtering. A
joined report can even contain data from different report types.
*Reports can only go 3 levels deep

Dashboard component types

Component Image Description
Type
Use a chart when you want to show data graphically. You can choose from a
Chart variety of chart types.

Use a gauge when you have a single value that you want to show within a
Gauge range of custom values.

Use a metric when you have one key value to display. For example, if you
have a report showing the total amount for all opportunities in
Metric the Closed, Commit, and Base Case stages in the current month, you can
name that value and use it as a revenue target for the month displayed on the
dashboard.
Use a table to show a set of report data in column form. Supports sort order,
Table and conditional highlighting.

Use a Visualforce page when you want to create a custom component or

Visualforce show information not available in another component type. Visualforce pages
N/A
Page must have a StandardSetController (recordsetvar) or a CustomController to
appear in the Dashboards.
Integration
Integration Types Integration Design pattern
• UI Integration • API Wrapper class
• Data integration • Delegator class
• Security integration • Optional components (logging,
• Business process integration mapping, session handling,
exception handling)
Integration Mechanisms
Mechanism Description

External Data is fetched from an external system using Salesforce Connect Adapters. Addapter types supported
objects are: Cross-org, OData 2.0, OData 4.0, Custom adapter created via Apex.
Canvas Canvas enables you to easily integrate a third-party application in Salesforce. Canvas is a set of tools and
JavaScript APIs that you can use to expose an application as a canvas app. This means you can take your
new or existing applications and make them available to your users as part of their Salesforce
experience.
Push Mobile push notifications allow Lightning Platform mobile application developers to easily push
notifications notifications to their users’ mobile devices when business events occur in the customers’ organizations.
REST API REST API provides a powerful, convenient, and simple REST-based web services interface for interacting
with Salesforce. Its advantages include ease of integration and development, and it’s an excellent choice
of technology for use with mobile applications and web projects. It provides the same methods as SOAP
API. It integrates via simple HTTP calls(GET, POST, PUT, PATCH, DELETE) and both XML and JSON.
SOAP API Use SOAP API to create, retrieve, update or delete records, such as accounts, leads, and custom objects.
With more than 20 different calls, SOAP API also allows you to maintain passwords, perform searches,
and much more. Use SOAP API in any language that supports Web services.
Chatter REST Use Chatter REST API to display Chatter feeds, users, groups, and followers, especially in mobile
API applications. Chatter REST API also provides programmatic access to files, recommendations, topics,
notifications, Data.com purchasing, and more.
Bulk API Used to extract and load large volumes of data into and from Salesforce
Metadata API Used to retrieve, deploy, create, update or delete customization information, such as custom object
definitions and page layouts, for your organization. This API is intended for managing customizations
and for building tools that can manage the metadata model, not the data itself.
Streaming API Use Streaming API to receive notifications for changes to Salesforce data that match a SOQL query you
define, in a secure and scalable way. Supported via PushTopics.
Web Service API Allows developers to create Web Services on Salesforce that can be called by external third parties.
Tooling API Use Tooling API to build custom development tools or apps for Lightning Platform applications. Tooling
API’s SOQL capabilities for many metadata types allow you to retrieve smaller pieces of metadata.
Smaller retrieves improve performance, which makes Tooling API a better fit for developing interactive
applications. Tooling API provides SOAP and REST interfaces.
Apex callouts Call external SOAP, Rest or other web services from Apex.
Outbound Standard Salesforce outbound integration. Send an SOAP message with data. The message can include
Messages Session Id and supports 24 hour retry mechanism.
Email Integrate by sending and receiving emails. Must implement InboundEmailHandler
Middleware Integration via ESB or ETL
OAuth & SSO Flows

Flow Description
Apps hosted on a secure server use the web server authentication flow. A critical aspect of the
Web Server web server flow is that the server must be able to protect the client secret. This flow uses an
OAuth 2.0 authorization code grant type.
Users can authorize a desktop or mobile application to access data using an external or
embedded browser (or user agent) for authentication. These apps often use a scripting
User-Agent
language, such as JavaScript, running within the browser. This flow uses the OAuth 2.0 implicit
grant type.
JWT Bearer The main use case of the JWT Bearer Token Flow is server-to-server API integration. This flow
Token Flow uses a certificate to sign the JWT request and doesn’t require explicit user interaction.
Command-line apps or applications that run on devices with limited input and display
Device
capabilities, such as TVs, appliances, and other IoT devices, can use this flow. Users can connect
Authentication
these applications to Salesforce by accessing a browser on a device with more advanced input
Flow
capabilities, such as a desktop or a smartphone. Not supported in Salesforce Communities.
Client applications use this flow to request an asset token from Salesforce for connected
Asset Token devices. An OAuth access token and an actor token are exchanged for an asset token. This flow
Flow combines issuing and registering asset tokens for efficient token exchange and automatic
linking of devices to service cloud asset data.
An app can also reuse an existing authorization by supplying a signed SAML 2.0 assertion, as
SAML Bearer
specified in the SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants.
Assertion Flow
A digital signature applied to the SAML assertion authenticates the authorized app.
SAML Assertion This flow is an alternative for orgs that are using SAML to access Salesforce and want to access
Flow the web services API in the same way.
Because the username and password flow passes credentials back and forth, avoid using this
Username and flow. Use it only for testing, when a user is not present at app startup, or with highly privileged
Password apps. In these cases, set user permissions to minimize access and protect stored credentials
from unauthorized access.
OAuth 2.0 The web server and user-agent flows also use a OAuth 2.0 Refresh Token Flow to renew access
Refresh Token tokens. After a client is authorized for access, it uses a refresh token to get a new access token
Flow (session ID).
Canvas App This is the default authorization method for canvas apps. The signed request authorization flow
User Flow - varies depending on whether the canvas app’s Permitted Users field is set to "Admin approved
Signed Request users are pre-authorized" or "All users may self-authorize."
Canvas supports OAuth 2.0 for authorization. When using OAuth, you have two options:
• Web Server OAuth Authentication Flow—When users run your canvas app, they can
Canvas App
authorize the app to access their data.
User Flow -
• User-Agent OAuth Authentication Flow—When users run your canvas app, they can
Oauth
authorize the app to access their data by using just the browser for authentication.
Recommended to use only for development.
Whether you use signed request or OAuth authorization, you can use SAML-based single sign-
SAML Single on (SSO) to provide your users with a seamless authentication flow. You can leverage
Sign-On for Salesforce as an identity provider or as a service provider. SAML SSO enables you to give your
Canvas Apps users automatic authentication into your canvas app via SAML and authentication into
Salesforce via the signed request.
LDV Mitigation strategies
Strategy Description

Indexes Salesforce supports custom indexes to speed up queries, and you can create custom indexes
by contacting Salesforce Customer Support.
Skinny tables Salesforce can create skinny tables to contain frequently used fields and to avoid joins. Doing
so keeps the skinny tables in sync with their source tables when the source tables are
modified. If you want to use skinny tables, contact Salesforce Customer Support. When
enabled, skinny tables are created and used automatically where appropriate. You can’t
create, access, or modify skinny tables.

For each object table, Salesforce maintains other, separate tables at the database level for
standard and custom fields. This separation ordinarily requires a join when a query contains
both kinds of fields. A skinny table contains both kinds of fields and does not include soft-
deleted records.
Data archiving Remove old data from Salesforce objects that are actively used to another internal or external
archiving object or database
Managing Data Skew Avoid records with a lot of child records (Account Skew, Ownership Skew, Lookup Skew). Use
triggers instead of workflows, picklists instead of lookup and schedule automated updates at
low load times to avoid record locking if needed.

OAuth & SSO Flow diagrams

Social Sign-On
(SP-Initiated SSO + Oauth)
OAuth & SSO Flow diagrams
Web Server Flow

It should be used as soon as the client is a web server. It allows you to obtain a long-lived access token since it
can be renewed with a refresh token (if the authorization server enables it).

Scenario:
1. A website wants to obtain information about your Google profile.
2. You are redirected by the client (the website) to the authorization server (Google).
3. If you authorize access, the authorization server sends an authorization code to the client (the website) in
the callback response.
4. Then, this code is exchanged against an access token between the client and the authorization server.
5. The website is now able to use this access token to query the resource server (Google again) and retrieve
your profile data.
You never see the access token, it will be stored by the website (in session for example). Google also sends other
information with the access token, such as the token lifetime and eventually a refresh token.
This is the ideal scenario and the safer one because the access token is not passed on the client side (web
browser in our example).
OAuth & SSO Flow diagrams
User Agent Flow

It is typically used when the client is running in a browser using a scripting language such as Javascript. This grant
type does not allow the issuance of a refresh token.

Scenario:
1. The client (AngularJS) wants to obtain information about your Facebook profile.
2. You are redirected by the browser to the authorization server (Facebook).
3. If you authorize access, the authorization server redirects you to the website with the access token in the
URI fragment (not sent to the web server). Example of callback:
http://example.com/oauthcallback#access_token=MzJmNDc3M2VjMmQzN.
4. This access token can now be retrieved and used by the client (AngularJS) to query the resource server
(Facebook). Example of query: https://graph.facebook.com/me?access_token=MzJmNDc3M2VjMmQzN.
This type of authorization should only be used if no other type of authorization is available. Indeed, it is the least
secure because the access token is exposed (and therefore vulnerable) on the client side.
OAuth & SSO Flow diagrams
Username Password flow
With this type of authorization, the credentials (and thus the password) are sent to the client and then to the
authorization server. It is therefore imperative that there is absolute trust between these two entities. It is
mainly used when the client has been developed by the same authority as the authorization server. For
example, we could imagine a website named example.com seeking access to protected resources of its own
subdomain api.example.com. The user would not be surprised to type his login/password on the site
example.com since his account was created on it. No refresh token is issued.

Scenario:
1. Acme company, doing things well, thought to make available a RESTful API to third-party applications.
2. This company thinks it would be convenient to use its own API to avoid reinventing the wheel.
3. Company needs an access token to call the methods of its own API.
4. For this, company asks you to enter your login credentials via a standard HTML form as you normally
would.
5. The server-side application (website acme.com) will exchange your credentials against an access token
from the authorization server (if your credentials are valid, of course).
6. This application can now use the access token to query its own resource server (api.acme.com).

Example: Salesforce App

OAuth & SSO Flow diagrams
Device authentication flow
The OAuth 2.0 device authentication flow is typically used by applications on devices with limited input or
display capabilities, such as TVs, appliances, or command-line applications. Users can connect these client
applications to Salesforce by accessing a browser on a separate device that has more developed input
capabilities, such as a desktop computer or smartphone.

Refresh token flow

The OAuth 2.0 refresh token flow is for renewing tokens issued by the web server or user-agent flows.
OAuth & SSO Flow diagrams
JWT Bearer token flow
JSON Web Token (JWT) is a JSON-based security token encoding that enables identity and security information
to be shared across security domains.
The OAuth 2.0 JWT bearer token flow defines how a JWT can be used to request an OAuth access token from
Salesforce when a client wants to use a previous authorization. Authentication of the authorized app is provided
by a digital signature applied to the JWT.

SAML Bearer Assertion flow

A SAML assertion is an XML security token issued by an identity provider and consumed by a service provider.
The service provider relies on its content to identify the assertion’s subject for security-related purposes.
The OAuth 2.0 SAML bearer assertion flow defines how a SAML assertion can be used to request an OAuth
access token when a client wants to use a previous authorization. Authentication of the authorized app is
provided by the digital signature applied to the SAML assertion.
OAuth & SSO Flow diagrams
SAML Assertion flow
The SAML assertion flow is an alternative for orgs that are currently using SAML to access Salesforce and want to
access the web services API the same way. You can use the SAML assertion flow only inside a single org. You
don’t have to create a connected app to use this assertion flow. Clients can use this assertion flow to federate
with the API using a SAML assertion, the same way they federate with Salesforce for web single sign-on.
Example: SSO with a company credentials(AD) using Salesforce App which then connects to Salesforce

Asset Token Flow

The OAuth 2.0 asset token flow is used by client applications to request an asset token from Salesforce for
connected devices. In this flow, an OAuth access token and an actor token are exchanged for an asset token.
This flow combines asset token issuance and asset registration, for efficient token exchange and automatic
linking of devices to Service Cloud Asset data.

During asset token flow, Salesforce attempts to link the asset token to an existing Asset or to create an Asset.
1. If the asset claim contains an ID claim, attempt to link to an existing Asset with a matching ID.
2. Otherwise, if the asset claim contains a SerialNumber claim, attempt to link to an existing Asset with a
matching serial number.
3. Otherwise, if the asset claim contains a Name claim, create (register) an Asset.
4. Otherwise, don’t link to or create an asset. You can separately link an asset later, via the API.
OAuth & SSO Flow diagrams

Canvas App User Flow - Signed Request

The default method of authentication for canvas apps. The signed request authorization flow varies depending
on whether you configure the canvas app so that the administrator gives users access to the canvas app or if
users can self-authorize. The signed request containing the consumer key, access token, and other contextual
information is provided to the canvas app if the administrator has allowed access to the canvas app for the user
or if the user has approved the canvas app via the approve/deny OAuth flow.
OAuth & SSO Flow diagrams
Canvas App User Flow - Oauth
Canvas apps can use the OAuth 2.0 protocol to authenticate and acquire access tokens.

If your canvas app uses OAuth authentication, the user experience varies depending on where the canvas app is
located in the user interface and how the user access is set. This diagram shows the user flow for a canvas app
that uses OAuth authentication.
OAuth & SSO Flow diagrams
SAML Single Sign-On for Canvas Apps
With this feature you can create a canvas app that begins a standard SAML authentication flow when opened by
a user. After this process completes, the user is authenticated into your Web application.

For canvas apps that use signed request authentication, two methods that are included in the Canvas SDK enable
your canvas app to call into Salesforce to receive a new signed request directly or enable Salesforce to repost
the signed request to your Web application endpoint. This results in a complete end-to-end authentication flow.

refreshSignedRequest Method
Returns a new signed request via a callback. After the SAML SSO process is completed, your app can call this
method and receive a new signed request. This method is intended for developers who need to retrieve the
signed request by using a more client-side JavaScript approach. (The Canvas SDK sends the signed request to
your app.)

repost Method
Requests the parent window to initiate a POST to your canvas app and reloads the app page with a refreshed
signed request. After the SAML SSO process is completed, your app can call this method and a new signed
request is sent to your app via a POST. This method is for developers who want to retrieve the signed request
using a more server-side approach. (Salesforce POSTs the signed request to your server.)

SP Initiated SAML SSO

OAuth & SSO Flow diagrams
IdP Initiated SAML SSO

Delegated authentication flow