Back Matter

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Appendix A: Salesforce Authorization Flows

This appendix will provide a flow diagram for each Salesforce authorization flow to assist an architect in choosing the correct authorization flow when designing system access to and from Salesforce. This appendix will focus on the nine primary authorization flows used in Salesforce, including

Web Server Flow
User-Agent Flow
JWT Bearer Flow
Device Flow
Asset Token Flow
Username and Password Flow
Refresh Token Flow
SAML Assertion Flow
SAML Bearer Assertion Flow

Note

Any other authorization flows indicated in Chapter 7 not listed here are a variation of one of the nine authorization flows mentioned in this appendix. Hence, to avoid redundancy of content, only the preceding nine flows have been covered in this appendix.

Web Server Flow

A Web Server Flow is mainly used to integrate an external web-based application with the Salesforce API, leveraging the industry standard OAuth 2.0 authorization code grant type authorization protocol.¹

Figure A-1

Web Server Flow Illustration

Figure A-1 presents an example scenario demonstrating Web Server Flow:

1.
An external website wants to obtain information from an object within your Salesforce instance.
2.
The website makes a request to its own server for authorization.
3.
The website server redirects the authorization code request to the Salesforce authorization endpoint of your instance (i.e., endpoint defined by you within your Salesforce-connected app).
4.
The user is redirected to the Salesforce login page. After a successful login, the user is asked to approve the website’s access to the object data within your Salesforce instance.
5.
After the user approves the website to access the data, Salesforce sends a callback to the website with an authorization code.
6.
The website passes the authorization code to the Salesforce token endpoint, requesting an access token .
7.
Salesforce validates the authorization code and sends back an access token that includes associated permissions in the form of scopes.
8.
Then the website sends a request back to Salesforce to access the information needed by the website. The request includes the access token with associated scopes.
9.
Salesforce validates the access token and associated scopes.
10.
The website can now access the Salesforce data.

Note

The user never sees the access token; it will be stored by the website within a session cookie. Salesforce also sends other information with the access token, such as the token lifetime and eventually a refresh token.

User-Agent Flow

A User-Agent Flow is mainly used when the user authorizes a desktop or mobile app to access data using an external system or embedded browser. Client apps running in a browser using a scripting language such as JavaScript can also use this flow. This flow leverages the industry standard OAuth 2.0 implicit grant type authorization protocol.²

Figure A-2

User-Agent Flow

Figure A-2 presents an example scenario demonstrating User-Agent Flow :

1.
The end user opens the mobile app.
2.
The Salesforce-connected app redirects the user to Salesforce’s login page to authenticate and authorize the mobile app’s access.
3.
The user logs in and approves access requested by the mobile app.
4.
The connected app receives the callback request from Salesforce and gets redirected to the URL in the redirection URL along with the access and refresh tokens.
5.
The connected app uses the access token to access data on the user’s behalf and presents it within the mobile app.

Note

This authorization flow is least secure because the access token is encoded into the redirection URL and is exposed to the user and other apps on the device. Also, the authentication is based on same-origin policy, which means that the redirect_URI must match one of the callback URL values specified in the connected app.

JWT Bearer Flow

A JWT Bearer Flow is mainly used to authorize long-term access for remote systems without requiring them to log in again each time they need to access Salesforce. JWT stands for JSON Web Token. This flow uses a certificate generated by both systems to sign the JSON Web Token request each time one of the authorized systems needs access to the other system. This flow does not require user interaction; however, it does require a trust relationship to be established between the integrating systems. This flow is best for server-to-server integrations without requiring user authorizations each time data is exchanged.

Figure A-3

JWT Bearer Flow

Figure A-3 presents an example scenario demonstrating the JWT Bearer Flow:

1.
An external Salesforce reporting tool needs to pull data from Salesforce to generate a sales report.
2.
In this case, the Salesforce-connected app sends the JSON Web Token to the defined token endpoint. The JSON Web Token enables identity and security information to be shared across the two systems’ security domains.
3.
Salesforce validates the JSON Web Token based on the digital signature previously set up to authorize the external reporting tool.
4.
Salesforce ensures that that the presented JSON Web Token is still valid and that the connected app is till approved for access.
5.
Salesforce issues an access token to the reporting tool .
6.
The reporting tool can now access the required data from Salesforce.

Device Flow

A Device Flow is mainly used to integrate Internet of Things (IoT) devices with limited input or display capabilities such as smart TVs or smart devices such as Amazon’s Alexa. Device Flow can also be used to integrate with command-line apps such as Git. When using this flow, users need to use a web browser or a mobile device that has more input capabilities to connect the device and to configure additional capabilities.

Figure A-4

Device Flow

Figure A-4 presents an example scenario demonstrating the Device Flow:

1.
The user wants to connect Salesforce to their IOT-based home thermostat (such as Google’s Nest) to control their home temperature.
2.
The user opens the Bluetooth app in their home thermostat to connect with their mobile device that has the home thermostat app installed for additional configuration.
3.
After connecting the mobile device to the home thermostat via Bluetooth connection, the user opens the home thermostat app to set up the device .
4.
The home thermostat app is set up as a connected app within Salesforce, in which case the thermostat app posts a request to the Salesforce endpoint for authentication.
5.
Salesforce verifies the request and returns a human-readable user code, verification URL, and device code.
6.
The thermostat app on the user mobile device displays the human-readable code provided by Salesforce and requests the user to enter the code by navigating to the verification URL to add the new thermostat device to the user’s account.
7.
The user goes to the verification URL on their mobile device and enters the code to activate the device.
8.
Once verified, the user authorizes the thermostat app to access data in Salesforce and vice versa.
9.
The thermostat app on the user’s mobile device begins polling the Salesforce token endpoint for an access token.
10.
Salesforce sends an access and refresh token to the thermostat app on the user’s mobile device .
11.
The user can now control the thermostat device via Salesforce.

Asset Token Flow

An Asset Token Flow is used to integrate IoT devices such as smart watches and mobile devices that are not limited by their input capabilities for setup and use. In other words, it is not dependent entirely on the device capability for device registration and data exchange with Salesforce, as in the case of devices integrated using the Device Flow described earlier. The Asset Token Flow leverages the JWT Bearer Flow to identify the device and a back-end server used by the device to process the stream of data and events exchanged with Salesforce. The JWT tokens allow registration of the device within Salesforce and to link the device data with data stored in Salesforce objects.

Figure A-5

Asset Token Flow

Figure A-5 presents an example scenario demonstrating the Asset Token Flow:

1.
User wants to register their wearable smart watch with Salesforce to exchange health data collected by their smart watch.
2.
User logs into a Salesforce app to register their smart watch device, where they provide all data needed from the smart watch to register the device .
3.
Salesforce stores the device information in the standard asset object.
4.
The connected app configured within Salesforce generates an actor token that identifies the user and an asset token that identifies the data based on the data provided in the asset object.
5.
The asset token is sent to the back-end server of the device and stored in the device and completes the device registration process.
6.
After the device is registered, the device transmits data to its back-end server.
7.
The back-end server of the device uses the earlier provisioned asset token to exchange user health data with Salesforce, without requiring re-logins into Salesforce (similar to JWT Bearer Flow).

Username and Password Flow

A Username and Password Flow can be used to authorize a remote system using the user’s username and password that the user uses to log into Salesforce. However, this is the least recommended option for designing integrations, since it exposes the user’s username and password in the URL. Although, the username password can be stored within named credentials to mitigate exposure of user credentials, it should be only used for integration with highly trusted remote systems and other grant types such as Webserver Flow or JWT token flow are not feasible.

Figure A-6

Username and Password Flow

Figure A-6 presents an example scenario demonstrating the Username and Password Flow:

1.
A connected app is configured to integrate a remote system with Salesforce.
2.
The user’s username and password is stored in the connected app (or stored in a named credential and referenced within the connected app).
3.
The connected app requests an access token by sending the user’s login credentials to the Salesforce token endpoint.
4.
After verifying the request, Salesforce grants an access token to the connected app .
5.
The remote system gets access to any data that is accessible by the user themselves.

Refresh Token Flow

A Refresh Token Flow is mainly used to obtain a new access token to start a new session when the current session expires as per the session timeout limit set within the system. The prerequisite for a Refresh Token Flow is to have a valid preexisting session that has expired. The refresh token extends the access for the remote application or user without requiring any reauthentication or reauthorization steps, if nothing has changed within the remote system or user’s access privileges.

Figure A-7

Refresh Token Flow

Figure A-7 presents an example scenario demonstrating the Refresh Token Flow:

1.
An external system is in active session with Salesforce, and the session is about to expire.
2.
As soon as the session expires, the connected app related to the remote system uses the existing refresh token to request a new access token.
3.
After verifying the request, Salesforce grants a new access token to the remote system.
4.
The remote system seamlessly enters into a new session with a reset session timeout. All of this happens within milliseconds and typically does not cause any interruptions when transferring from one session to another .

SAML Assertion Flow

A SAML Assertion Flow is an alternative way to connect remote systems with Salesforce within organizations that already use SAML-based SSO to access Salesforce. 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.

With this flow, the remote system can federate itself within the API using a SAML assertion, the same way users federate within Salesforce via single sign-on. The biggest advantage of this flow is that it does not require configuring a Salesforce-connected app since the SAML assertion manages the authentication and authorization details within this flow.

Figure A-8

SAML Assertion Flow

Figure A-8 presents an example scenario demonstrating the SAML Assertion Flow:

1.
A SAML configuration is set up in Salesforce connecting the remote system.
2.
The remote system exchanges a SAML assertion for an access token.
3.
After verifying the SAML assertion, Salesforce grants an access token in the response, granting the remote system access to Salesforce .

Note

This flow cannot be used by the remote system to connect with more than one Salesforce org. Login flows cannot be used for authentication with this flow, and this flow does not work with Salesforce communities. Also refresh tokens cannot be issued with this flow.

SAML Bearer Assertion Flow

A SAML Bearer Assertion Flow is mainly used to authorize a remote system that has been previously authorized. The SAML Bearer Assertion Flow is similar to the Refresh Token Flow with the exception that the SAML Bearer Assertion flow uses a signed SAML 2.0 assertion to request an OAuth access token instead and the digital signature applied to the SAML assertion authenticates the authorized app.

Figure A-9

SAML Bearer Assertion Flow

Figure A-9 presents an example scenario demonstrating the SAML Bearer Assertion Flow:

1.
A connected app is configured using a digital certificate.
2.
This certificate corresponds to the private key of the remote system.
3.
When the connected app is saved, a consumer key is generated and assigned to the remote system.
4.
When the remote system requests access to Salesforce, the connected app posts the SAML bearer assertion to the Salesforce token endpoint.
5.
Salesforce validates the signature using the certificate registered for the connected app. In addition, it validates the audience, issuer, subject, and validity of the assertion .
6.
Assuming that the assertion is valid and that the user or admin had authorized the app previously, Salesforce issues an access token to the remote system and grants access.

Note

Refresh tokens cannot be issued with this flow either.

Appendix B: Salesforce Integration Patterns

This appendix will provide a one-page flow diagram for each Salesforce integration pattern to assist an architect to better understand the pattern. This appendix will focus on the six most popular integration patterns used in Salesforce, including

Request and Reply
Fire and Forget
Batch Data Synchronization
Remote Call-In
UI Update
Data Virtualization

Request and Reply

A Request and Reply integration pattern supports synchronous communication where message is sent to an external system and the sender is expecting a return of information.

../images/491343_1_En_BookBackmatter_Fig10_HTML.jpg — Figure B-1
Request and Reply Integration – Synchronous Remote Process Invocation

Figure B-1 presents an example flow using a Request and Reply integration pattern. The pattern is initiated when

1.
The Apex controller makes a remote web service call to the remote system or middleware after the browser user initiated an action.
2.
The service call remains open while it waits for a response from the remote system.
3.
The remote system returns a response to the Apex controller which processes the response.

Fire and Forget

A Fire and Forget integration pattern supports asynchronous communication where message is sent to an external system and the sender is not expecting a return of information.

../images/491343_1_En_BookBackmatter_Fig11_HTML.jpg — Figure B-2
Fire and Forget Integration – Asynchronous Remote Process Invocation Using Platform Events

Figure B-2 presents an example flow using a Fire and Forget integration pattern. The pattern is initiated when

1.
The remote system (app) subscribes to a CometD platform event as a listener.
2.
The Salesforce process creates an event on the event stream after an action is recorded.
3.
The remote system listens to the event stream and recognizes an event. It calls a remote process. The system must be prepared to handle the same event processing more than once.

Batch Data Sync

The Batch Data Sync integration pattern is a common pattern used to support data migration in and out of a receiving system.

../images/491343_1_En_BookBackmatter_Fig12_HTML.jpg — Figure B-3
Batch Data Sync Integration – Asynchronous Remote Process Invocation of Change Data Capture

Figure B-3 presents an example flow using a Batch Data Sync integration pattern (similar to the Fire and Forget pattern). The pattern is initiated when

1.
The remote system (app) subscribes to a CometD platform event as a listener.
2.
The Salesforce process creates an event on the event stream after a record creation or update is recorded.
3.
The remote system listens to the event stream and recognizes an event. It calls a remote process to update change sync in the external database. The system must be prepared to handle the same event processing more than once.

Remote Call-In

The Remote Call-In integration pattern is used to support synchronous communication where a message is sent from an external system to the receiving system.

../images/491343_1_En_BookBackmatter_Fig13_HTML.jpg — Figure B-4
Remote Call-In Integration – Synchronous Remote Call Using SOAP or REST

Figure B-4 presents an example flow using a Remote Call-In integration pattern. The pattern is initiated when

1.
An event at the remote client initiates login call to Salesforce and, if authenticated and authorized, returns a sessionid.
2.
The remote client makes a remote call using either SOAP or REST API call to Salesforce to query, update, create, or delete data.
3.
Salesforce returns a response to the client which processes the response.

UI Update

The UI Update integration pattern is used to update the receiving system UI based on changes in the sending system.

../images/491343_1_En_BookBackmatter_Fig14_HTML.jpg — Figure B-5
UI Update Integration – Using Change Data Trigger

Figure B-5 presents an example flow using a UI Update integration pattern. The pattern is initiated when

1.
A UI is expecting to automatically see if a process updates a given field. The save of the process makes the record change.
2.
The controller notifies Streaming API of the change. A PushTopic is defined with the event trigger and the data included in an update.
3.
A JavaScript-based component can use the PushRecords to update the UI.

Data Virtualization

The Data Virtualization integration pattern is used to support synchronous communication where a message is sent from an external system to the receiving system and presented as a virtual object.

../images/491343_1_En_BookBackmatter_Fig15_HTML.jpg — Figure B-6
Data Virtualization Integration – Using OData and Salesforce Connect

Figure B-6 presents an example flow using a Data Virtualization integration pattern. The pattern is initiated when

1.
Read/write access is established using OData to manage and map the external data source.
2.
Salesforce Connect provides authentication and authorization and management of the OData data mapping.
3.
Salesforce external object is defined and presents a virtual data object.

Appendix C: Salesforce Sample Artifacts

This appendix will present a set of artifacts that we created for practice business discussions and mock CTA reviews. The goal of this appendix is to give you different ideas on how to create and present your architectural design. We are including the following artifacts:

System landscape
Data model
Role hierarchy
Project management/governance
Integrations/SSO/OAuth
Actors/licenses

System Landscapes

The system landscape examples highlight different approaches that we created to present how an existing enterprise environment will be changed with a proposed system solution. The diagrams all assume that Salesforce is existing or will be added to support the new system design. Figures C-1 through C-4 are examples of system landscape diagrams.

../images/491343_1_En_BookBackmatter_Fig16_HTML.png — Figure C-1
System Landscape for Greenhouse Recycling Corp

../images/491343_1_En_BookBackmatter_Fig17_HTML.png — Figure C-2
System Landscape for Example System

../images/491343_1_En_BookBackmatter_Fig18_HTML.png — Figure C-3
System Landscape for Mock CTA Review

../images/491343_1_En_BookBackmatter_Fig19_HTML.png — Figure C-4
System Landscape for Mock CTA Review – Version 2

Data Models

The data model examples shown will present different approaches that we have used to present with a proposed system solution. The data models use an ERD to depict the objects, object relationships, and important elements used in the design. Figure C-5 through C-6 are examples and considerations used in data model diagrams.

../images/491343_1_En_BookBackmatter_Fig20_HTML.png — Figure C-5
ERD Elements, Relationships, and Consideration

../images/491343_1_En_BookBackmatter_Fig21_HTML.png — Figure C-6
ERD Elements, Relationships, and Consideration

FUSIAOLA Options

Figure C-7 is a variation of the FUSIAOLA artifact presented in Chapter 2. This version focuses on the objects, systems, actors/licenses, and integrations given.

../images/491343_1_En_BookBackmatter_Fig22_HTML.png — Figure C-7
Systems, Objects, Actors, and Integration Artifact

Lifecycle Management Artifacts

Figures C-8 and C-9 show different approaches to present lifecycle management.

../images/491343_1_En_BookBackmatter_Fig23_HTML.png — Figure C-8
Environment Management – Sandbox Management

../images/491343_1_En_BookBackmatter_Fig24_HTML.png — Figure C-9
Release Management – Sandbox Management

Artifacts Used During a Mock CTA Review

Figures C-10 through C-17 provide an example of a set of artifacts used for mock CTI board review.

../images/491343_1_En_BookBackmatter_Fig25_HTML.jpg — Figure C-10
Agenda with a System, Objects, Actors, and Integration Artifact

../images/491343_1_En_BookBackmatter_Fig26_HTML.jpg — Figure C-11
System Landscape Artifact

../images/491343_1_En_BookBackmatter_Fig27_HTML.jpg — Figure C-12
Role Hierarchy Artifact

../images/491343_1_En_BookBackmatter_Fig28_HTML.jpg — Figure C-13
Data Model Artifact

../images/491343_1_En_BookBackmatter_Fig29_HTML.jpg — Figure C-14
Integration and SSO/OAuth Artifact

../images/491343_1_En_BookBackmatter_Fig30_HTML.jpg — Figure C-15
Release Management and Data Management Artifact

../images/491343_1_En_BookBackmatter_Fig31_HTML.jpg — Figure C-16
Mobile App, Communities, and Reporting/BI Artifact

../images/491343_1_En_BookBackmatter_Fig32_HTML.jpg — Figure C-17
Project Management and Governance Artifact

Index

Access

Access control

Access grants

Account skews

Ackoff knowledge continuum

Agile methodology

Apex-managed sharing

Apex programming language

Apex runtime engine processing apex code

Apex sharing

API protocol types

AppExchange products

Application design

declarative development options

options

order of execution

programmatic options

Application design architecture

Application-level security

Application lifecycle management (ALM) tool

Architectural artifacts

Architecture, Salesforce

application design architecture

data architecture

development lifecycle management

IAM domain

limitations

mobile domain

salesforce integration domain

security architecture

Artifacts

data model

FUSIAOLA analysis

SeeFUSIAOLA analysis

integration and SSO/OAuth

lifecycle management

Mobile App, communities, and reporting/BI

project management and governance

release management and data management

role hierarchy

system landscape

SeeSystem landscape artifact

Asset token flow

Assumptions

Asynchronous communication

Auditing

Audit trails

Authentication

Authorization

flows

OAuth 2.0

OpenID Connect Framework

scopes

Authorization flows

asset token flow

device flow

JWT bearer flow

refresh token flow

SAML assertion flow

SAML bearer assertion flow

user-agent flow

username and password flow

web server flow

Automated testing

Availability

Backups

Batch Data Sync integration pattern

Big object

Apex

Branching strategy

Bulk API

Business function attribute

Business logic context

Calling mechanism

Cardinality

Center of excellence (COE)

Chatter free

Chatter licenses

external users

free user

only licenses

Child implicit sharing

Cloud service provider (CSP)

Code-driven development

Commercial off-the-shelf (COTS)

Community sharing, external users

external organization-wide defaults

external role hierarchy

share group

sharing sets

Complex data migration

Concurrent Versions System (CVS)

Confidentiality

Continuous Integration and Continuous Deployment (CI/CD) Strategy

environment hub

packages

Salesforce CLI

Salesforce DX

scratch org

Cordova-based hybrid apps

Criteria-based sharing (CBS) rules

Cross-site scripting (XSS) prevention

Customer and partner community licenses

Customer community plus

Customer Identity and Access Management (CIAM) solution

Custom indexes

Custom metadata

Custom objects

Data access

Data architecture

Data archiving

Data backup

Database statistics

Data cleaning

Data encryption and security option

Data extraction

Data governance committee

Data integration

Data lifecycle management

backup and archiving approach

data archiving

data backup

data migration

SeeData migration

Data loading

Data manipulation operations

Data migration

complex

data loading

data manipulation operations

ETL

extraction and cleaning process

process

tools

transformation and verification

Data model

Data model artifact

large data volumes

object relationship

objects, store and manage data

object types

opportunity and order management application

organization-wide sharing default settings

ownership of records

record types

Data modeling

cardinality

considerations

relationship

revisiting cardinality

techniques and considerations

storage considerations

top-down consideration, bottom-up requirements

choice and compromise

normalized

performance

Data object model

Data skews

Data transformation

Data verification process

Data virtualization integration pattern

Data Virtualization integration pattern

Decentralized multi-org strategy

Decision tree

Declarative development options

Denormalized data model

Deployment methods

Development lifecycle management

Device flow

DevOps

archetypes

benefits

investment in software tools

traditional software development approach

DevOps vs. DevSecOps

Division management

Divisions

Dominant interaction context

Encryption methods

Enterprise mobile environment

Enterprise Mobility Management (EMM)

Enterprise Service Bus (ESB)

Enterprise WSDL

Environment hub

Error handling and recovery

ESB tool

ETL (Extract-Transform-Load)

ETL middleware tools

ETL tool

Experience cloud licenses

Explicit grants

Extensible Markup Language (XML) file

External Apps licenses

External Identity licenses

External lookup relationship

External objects

External organization-wide defaults

External role hierarchy

Extract-Transform-Load (ETL)

Feature licenses

Field audit trail

Field history tracking

Field-level visibility

Fire and Forget integration pattern

Flat data model

Foreign key (FK)

Full sharing model

FUSIAOLA analysis

assumptions

authentication

features

business logic context

data context

interaction context

user stories

format

integrations

licenses

objects

systems

user

business function attribute

information role attribute

internal vs. external attribute

role hierarchy index attribute

FUSIAOLA artifact

Governance and monitoring

center of excellence (COE)

data governance committee

steering committee

Grant access, hierarchies

Granting method

Graphical User Interface (GUI)

Group membership grant

Group membership object

Hierarchical lookup

Hierarchical relationship

High-performing mobile applications

High-Volume Portal (HVP)

HTML5 app development

Hub-and-spoke integration

Hybrid application

Hybrid methodology

IaaS-based solution development

Idempotent integration method

Identity and access management (IAM) architecture

access

authentication

authorization

SeeAuthorization

logouts and redirects

provisioning

session management

single sign-on

SeeSingle sign-on

two-factor authentication

user account management

user deprovisioning

Identity and access management lifecycle

access

authentication

authorization

deprovisioning

logouts and redirects

provisioning

session management

single sign-on

stages, flight experience

user account management

Identity provider (IDP)–initiated SAML SSO flow

Implicit grant

Implicit sharing

Independent Multi-org Strategy

Independent Software Vendor (ISV)

Indirect lookup relationship

Informatica

Information processors

Information role attribute

Infrastructure as a service (IaaS) model

Infrastructure layer

Infrastructure-level security

Inherited grant

Integration broker

Integration capabilities

Integration external service options

Integration levels

Integration options

Integration patterns

approach categories

batch data sync

calling mechanism

data virtualization

error handling and recovery

fire and forget

idempotent design considerations

remote call-in

request and reply

in Salesforce

security consideration

source, target, and direction

state management

timing

UI update

uses cases, and justification

Integrations

Integration strategy

API protocol types

design requirements

layers

levels

middleware

SeeMiddleware

on-premise application, and cloud-based business applications

scalable architecture

use cases

Integration tools

Integrity

Interaction context

Internet of Things (IoT)

architecture patterns

implementation

Salesforce connection

Intrusion detection system (IDS)

J, K

Jitterbit

JWT bearer flow

Large data volume (LDV)

data skew

object size

record ownership

record relationships

resolving

Licenses

feature licenses

org-level licenses

permission set licenses

platform vs. CRM licenses

security

user

SeeUser licenses

Lifecycle management artifacts

Lightning component layer

Lightning page component

Lightning pages

Lightning platform

Lightning platform technology stack

apex code runtime engine layer

identity and access management

infrastructure layer

metadata and shared services layer

Lightning web components (LWC)

Limitations

Logout

Lookup

Lookup relationship

Lookup skews

Manual sharing

Many-to-many relationships

Marketing cloud connect

Master-Child Multi-org Strategy

Master data management (MDM)

Master-detail relationships

Message-Oriented Middleware (MOM)

Metadata

Metadata-driven framework

Middleware

ESB components

ETL tools

options with uses cases

point-to-point integration model

Mix and match integration

Mobile app features

application design considerations

desktop features

mobile page layout and lightning support

UI navigation changes

voice commands

Mobile application design

data security

deployment

development costs

development skills

device features, access

factors

performance factors

battery drain and power consumption requirements

data plan usage

errors, bugs, and updates

information capture process and times

memory usage required

server-side response time

startup time and task load times

speed to market

user experience

Mobile Application Management (MAM)

Mobile applications

Mobile architecture

device features

devices

lifecycle of information

Mobile Content Management MCM)

Mobile data and device considerations

Mobile data management

Mobile development

Salesforce mobile SDK

Mobile development

center

Cordova-based hybrid apps

HTML5 and JavaScript mobile apps

native apps

react native

Mobile Device Management (MDM)

Mobile devices

application development

Mobile domain

Mobile features

access to applications and data

application access (authentication and authorization)

application use

mobile security

Mobile management solutions

Mobile usage

MuleSoft

Multi-org strategy

Multi-tenant architecture

Native app development

Native applications

OAuth 2.0 authorization framework

Object-level access

Object relationship

external lookup relationship

hierarchical relationship

indirect lookup relationship

lookup relationship

many-to-many relationships

master-detail relationship

Object size

Off-platform solution

On-premise solution development

OpenID Connect framework

Order of execution

Organization-wide default (OWD)

Organization-wide sharing default settings

Org-based development” (OBD) approach

Org-based development vs. source-driven development

Org-level licenses

Org strategy considerations

Owner field

Ownership-based record-level visibility and sharing capabilities

Ownership-based sharing architecture

Ownership-based sharing (OBS) rules

Ownership of records

Ownership skew

PaaS-based solution development

Packages

Parent implicit sharing

Partner community

Partner WSDL

Permission set

Permission set groups

Permission set licenses

Personal groups

Phishing and Malware

Platform as a service (PaaS)

Platform encryption

Platform-level security

Platform security

application-level security

data encryption and security option

external user experiences and salesforce portals

infrastructure-level security

Salesforce shield

SeeShield, Salesforce

standard audit and event monitoring tools

field history tracking

monitor configuration and setup changes

transaction monitoring and policies

user login monitoring

Point-to-point integration model

Potential optimal solutions

Process integration

Programmatic options, application

Provisioning methods

Public group considerations

Public read-only

Public read/write

Quantitative descriptions

React Native app development

Record access calculations

Record-level access

Record locking

Record ownership

Record relationships

Record types

Recovery/archive

Redirects

Refresh token flow

Regulatory compliance and adherence

Release management

Remote Call-In integration pattern

Request and Reply integration pattern

REST API

Role hierarchy

Role hierarchy artifact

Role hierarchy index attribute

SaaS-based solution development

Salesforce

capabilities

cloud solutions

companies

licenses

SeeLicenses

Salesforce App, limitations

Salesforce CLI

Salesforce community licenses

Salesforce DX

Salesforce integration domain

Salesforce licenses

Salesforce lightning platform technology stack

Salesforce Mobile SDK

Salesforce organization strategy

Salesforce platform licenses

Salesforce roles and responsibilities

SAML assertion flow

SAML bearer assertion flow

Sandbox management

Sandbox types

Scratch org

Security architecture

attributes and features

availability

confidentiality

integrity

platform-level security

platform security

SeePlatform security

potential optimal solutions

sharing

SeeSharing architecture

Security Assertion Markup Language (SAML)

Security features

Security-focused framework

Security health check

Security infrastructure

Security levels

Security protocols

Security strategy, pillars

Service provider (SP)–initiated SAML SSO flow

Session types

Share group

Sharing architecture

criteria-based sharing rule

division management

manual sharing

OWDs

ownership-based sharing rule

permission set

potential optimal solutions

profiles

programmatic sharing

record ownership

role hierarchy

teams

territory management

Sharing performance

Sharing rule object

Sharing rules

Sharing sets

Shield, Salesforce

event monitoring

field audit trail

platform encryption

Single logout (SLO)

Single-org vs. multi-org strategy

Single sign-on (SSO)

authentication flows

identity provider (IDP)–initiated SAML

methods

Security Assertion Markup Language (SAML)

service provider (SP)–initiated SAML flow

Skinny tables

SOAP API

Software as a service (SaaS)

Software development kit (SDK)

Solution development options

Source Code Versioning Management (SCVM) tool

Source code versioning tools

Source-driven development (SDD) approach

SSO/OAuth artifact

Standard objects

Steering committee

Streaming API

Subversion (SVN)

Synchronous communication

System-initiated logout

System landscape

System landscape artifact

AppExchange products

integration strategy

interact with salesforce

salesforce community licenses

Salesforce licenses

salesforce organization strategy

User authentication/authorization tools

Team Foundation Server (TFS)

Technology solutions, building

IaaS

on-premise solution

options

PaaS

SaaS

Territory management

Testing strategy

Testing types

Tokenization

Traditional software development approach

Transaction security

Transport Layer Security (TLS)

Two-factor authentication (2FA)

UI Update integration pattern

Unified Endpoint Management (UEM)

Unlocked package

Usage-based entitlements

Usage-based licensing

User account management

User-agent flow

User attribute chart

User authorization tools

User deprovisioning

User-initiated logout

User licenses

chatter

SeeChatter licenses

customer and partner community licenses

external apps licenses

external identity licenses

platform licenses

Salesforce licenses

User login monitoring

Virtual and mobile security

Virtual integration

Visibility

Visual SourceSafe (VSS)

W, X, Y, Z

Waterfall methodology

Web application

Web server flow

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for Back Matter

Create new playlist

Sign In

Sign Up

Table of Contents for
Back Matter