CRM Integration of 3rd party applications into Salesforce - Masaryk University Faculty of Informatics - IS MU
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Masaryk University
Faculty of Informatics
Integration of 3rd party
applications into Salesforce
CRM
Master’s Thesis
Jakub Hančin
Brno, Spring 2020
Masaryk University
Faculty of Informatics
Integration of 3rd party
applications into Salesforce
CRM
Master’s Thesis
Jakub Hančin
Brno, Spring 2020
This is where a copy of the official signed thesis assignment and a copy of the Statement of an Author is located in the printed version of the document.
Declaration
Hereby I declare that this paper is my original authorial work, which
I have worked out on my own. All sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed in complete reference to the due source.
Jakub Hančin
Advisor: RNDr. Josef Spurný
i
Acknowledgements
My first great thanks goes to my soon-to-be wife Miriam Kanovská
who was extremely supportive during the creation of this thesis and
who will hopefully not change her mind about marrying me once the
defence of this thesis is over.
A large thanks go to my supervisor Josef Spurný, who was a great
lecturer of mine and who was seemingly the only person in the entire
Faculty of Informatics willing to supervise such a specific thesis as
mine was.
Big thanks goes to my former colleagues at the Enehano company
in Prague who taught me nearly everything you can find in the practi-
cal as well as theoretical part of this thesis.
Great thanks goes to Jiří Mach and Michal Peška, who founded
an extraordinary company and turned out to be the most pleasurable
bosses I have ever had.
Another huge thank you goes to Michal Mach and Milan Bodlák,
my fellow developer colleagues at Enehano who were willing to give
me advice whenever I needed it.
And big thank you goes to Craig Jordan and the LeanTaaS company
who allowed me to use an example fitting a master’s thesis on such a
topic perfectly.
And the one person I cannot forgot is my uncle Miroslav Barus
who had the patience to lecture me during weekends during my first
year at FI and without whom I would probably never become an IT
graduate.
ii
Abstract
CRM platform development as a market is rapidly growing the
already rapidly growing IT industry.
This thesis focuses on the current CRM market leader Salesforce
and with the help of a practical example which demonstrates the
possibilities of this platform.
The practical example is a functional 3rd party integration applica-
tion developed under the wings of the SaaScend company for a client
called LeanTaaS. This example shows how to integrate a JSON data
source into Salesforce on an automatic and periodical basis.
Not only does this thesis summarize the technical difficulties of
performing such a task but it also provides a detailed walkthrough
on the development steps required to take prior to deploying the
developed code to production.
The purpose of this thesis is to help any beginner Salesforce or
Java developers who were given the task to integrate two or multiple
different systems together to get a better grasp of the problem, propose
possible solutions and potentially provide a good starting point on the
analysis front as the principles of building such an integration remain
nearly always the same.
iii
Keywords
Salesforce, CRM, Apex, REST, API, Integration, Org, Schedulable,
Change Set, Production, Sandbox, Multitenancy, SOQL, SOSL, Trail-
head, Dreamforce, Pulling, Pushing, The Welkin Suite, Visual Studio,
Access token, Bearer Token, Http, CRON, Script, Salesforce Developer
console
iv
Contents
Introduction 1
1 CRM platforms introduction 2
1.1 What is a CRM . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 CRM adoption . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 CRM platform market . . . . . . . . . . . . . . . . . . . . 3
1.4 Economic relevance of the CRM market . . . . . . . . . . . 4
1.5 Subscription-based CRM platforms . . . . . . . . . . . . . 5
1.5.1 Salesforce CRM . . . . . . . . . . . . . . . . . . . 5
1.5.2 SAP CRM . . . . . . . . . . . . . . . . . . . . . . 6
1.5.3 Oracle CRM . . . . . . . . . . . . . . . . . . . . . 7
1.5.4 Microsoft Dynamics CRM . . . . . . . . . . . . . 8
1.6 CRM platforms with a free plan . . . . . . . . . . . . . . . 9
1.6.1 HubSpot CRM . . . . . . . . . . . . . . . . . . . 9
1.6.2 Zoho CRM . . . . . . . . . . . . . . . . . . . . . . 10
1.7 CRM platforms comparison . . . . . . . . . . . . . . . . . 11
2 Salesforce CRM 13
2.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Salesforce - community specifics . . . . . . . . . . . . . . . 14
2.2.1 Trailhead - the Salesforce learning platform . . . 14
2.2.2 Dreamforce - the Salesforce yearly conference . 15
2.3 Salesforce - technological specifics . . . . . . . . . . . . . . 16
2.3.1 Multitenancy . . . . . . . . . . . . . . . . . . . . 16
2.3.2 Limits . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.3 Apex - Salesforce programming language . . . . 17
2.3.4 SOQL - Salesforce Object Query Language . . . 18
2.3.5 SOSL - Salesforce Object Search Lanuage . . . . 19
3 Integrations - implementation approaches 20
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Pulling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Requirements . . . . . . . . . . . . . . . . . . . . 21
3.2.2 Advantages . . . . . . . . . . . . . . . . . . . . . 21
3.2.3 Disadvantages . . . . . . . . . . . . . . . . . . . . 21
3.3 Pushing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
v
3.3.1 Requirements . . . . . . . . . . . . . . . . . . . . 22
3.3.2 Advantages . . . . . . . . . . . . . . . . . . . . . 23
3.3.3 Disadvantages . . . . . . . . . . . . . . . . . . . . 23
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Author REST application - case study 25
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2 Project context . . . . . . . . . . . . . . . . . . . . 25
4.1.3 Description of the objective . . . . . . . . . . . . 26
4.1.4 Project - team & pre-project analysis . . . . . . . 26
4.2 Obstacles to overcome . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Data heterogeneity . . . . . . . . . . . . . . . . . 27
4.2.1.1 Solution . . . . . . . . . . . . . . . . . . 27
4.2.2 URL encoding query requirement . . . . . . . . 28
4.2.2.1 Solution . . . . . . . . . . . . . . . . . . 28
4.2.3 Periodicity . . . . . . . . . . . . . . . . . . . . . . 28
4.2.3.1 Solution . . . . . . . . . . . . . . . . . . 28
4.2.4 Authorization . . . . . . . . . . . . . . . . . . . . 29
4.2.4.1 Solution . . . . . . . . . . . . . . . . . . 29
5 Author REST application - pre-development setup 32
5.1 Sandbox - testing environment . . . . . . . . . . . . . . . . 32
5.1.1 Configuration . . . . . . . . . . . . . . . . . . . . 32
5.1.2 Change set - uploading changes from a sandbox
to production . . . . . . . . . . . . . . . . . . . . 33
5.2 Org preparation . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2.1 Custom object creation . . . . . . . . . . . . . . . 34
5.2.2 Custom field creation . . . . . . . . . . . . . . . 35
5.3 Suitable IDE . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.1 Developer console - native Salesforce tool . . . . 37
5.3.2 The Welkin Suite - external IDE based on Visu-
alStudio . . . . . . . . . . . . . . . . . . . . . . . 37
6 Author REST application - implementation 39
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.1 Overview of the functionality . . . . . . . . . . . 39
6.1.2 Restrictions in possible recreation . . . . . . . . 39
vi
6.1.3 Structure of code analysis . . . . . . . . . . . . . 39
6.2 Project structure . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.1 Integration functionality - code hierarchy . . . . 40
6.2.2 Test class - mandatory unit tests . . . . . . . . . 42
6.3 Code Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3.1 Data Retrieval . . . . . . . . . . . . . . . . . . . . 45
6.3.2 Token Retrieval . . . . . . . . . . . . . . . . . . . 46
6.3.3 Http Module . . . . . . . . . . . . . . . . . . . . 47
6.3.4 SObjects Module . . . . . . . . . . . . . . . . . . 48
7 Author REST application - conclusion 50
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.2 Scheduling the Schedulable classes . . . . . . . . . . . . . . 50
7.2.1 Requirements . . . . . . . . . . . . . . . . . . . . 50
7.2.2 CRON expression . . . . . . . . . . . . . . . . . . 50
7.3 Running the job creation script . . . . . . . . . . . . . . . . 51
7.4 Scheduled job maintenance . . . . . . . . . . . . . . . . . . 52
7.5 Implementation conclusion . . . . . . . . . . . . . . . . . . 53
7.6 Project conclusion . . . . . . . . . . . . . . . . . . . . . . . 53
8 Conclusion 54
Bibliography 55
viiList of Tables
viiiList of Figures
2.1 Apex code example - example taken from
wisdomjobs.com 18
4.1 Authorization process modeled by Jakub Hančin in
Signavio modelling software 30
5.1 A screenshot of Deployment settings - sandbox
allowance 33
5.2 A screenshot of Object Manager - creation of Custom
Objects 35
5.3 A screenshot of the Object Manager - custom field
creation 36
5.4 A screenshot of the Developer Console - native
development tool of Salesforce opened in Mozilla
Firefox browser 38
5.5 A screenshot of The Welkin Suite - 3rd party IDE 38
6.1 SaaScend - LeanTaaS DefHC project structure 41
6.2 An example of a mock String constant and the
overriding of a respond() method in a test context. If
the respond() method is called with a specific
endpoint with specific values in the test context, the
body of the response is overwritten with the mockup
String contant. 43
6.3 Class interaction diagram created in Lucidchart by
Jakub Hančin 44
6.4 Data retrieval main method -
performDefinitiveDataPull() 45
6.5 Bearer Token request 46
6.6 Formation of a data request 47
6.7 A snippet of the updateRecords() method. 48
7.1 Script to schedule the integration 51
7.2 Scheduled Jobs interface 52
ixIntroduction
Customer Relationship Management systems or better known by their
abbreviated phrase CRM are considered useful tools used by numer-
ous managers and salespeople across multiple industries.
The purpose of this thesis is to introduce CRM platforms and later
focus on Salesforce, the CRM market leader of 2019 via an author
Salesforce application created for integrating a 3rd party data source
into Salesforce.
In chapter 1 we will introduce CRM platforms and explain their
relevance in terms of user adoption and market share.
We will continue in the chapter 2 with the introduction of Sales-
force, the CRM market leader of 2019 and elaborate on the technical
and community specifics of this platform.
Concluding the theoretical part of the thesis, we will cover potential
implementation approaches of 3rd party integrations in the chapter 3.
In chapter 4 we will introduce the case study of an author integra-
tion which was developed for the LeanTaaS company by Jakub Hančin
in the autumn of 2019.
We will elaborate the introduction by moving to a required pre-
development setup of Salesforce in the chapter 5.
Once the objectives of the LeanTaaS project and the pre-requisities
of Salesforce development are thoroughly explained we will continue
with analysis of the implementation in the chapter 6.
After an explanation of the implementation, we will conclude
the practical part as well as the whole thesis with post-development
requirements of Salesforce and the project conclusion.
11 CRM platforms introduction
1.1 What is a CRM
Customer relationship management (CRM) is the combination of best
practices, strategies and technologies that companies use to manage
and analyze customer interactions and data throughout the customer
lifecycle.
A CRM platform can be described as a central sales hub system
that collects and processes user data. Every user has easy, direct ac-
cess to the real-time client data they need. At the most basic level,
CRM software allows marketers and salespeople to manage and ana-
lyze relationships with the company’s actual and potential customers.
It enables tracking every interaction with the company and collects
information about the customer.
The goal of a CRM platform is to improve customer service rela-
tionships, to assist in customer retention, and to drive sales growth[1].
CRM can also be described as providing the functionality to compa-
nies across the four segments of customer service and support, digital
commerce, marketing, and sales[2].
CRM systems compile customer data throughout various points
of contact with the customer and store them in a unified, easy to work
with manner on a single platform.
1.2 CRM adoption
CRM platforms are becoming more and more popular. As per the
industry estimates, around 91% of companies with over 10 employees
have deployed a customer relationship management system in their
organization according to a research by Grand View Research[3]. CRM
Cloud Survey Report states that the reason for such a large adoption
past a certain company size was a need for automating the tracking
and reporting of sales and business processes in a central system[4].
The same report claims that around 82% of enterprises use cus-
tomer relationship management systems for sales reporting and sales
process automation.
21. CRM platforms introduction
1.3 CRM platform market
The five main vendors of CRM systems when ranking it by the portion
of the CRM market share of 2018 are Salesforce, SAP, Oracle, Adobe
and Microsoft. [2].
These five vendors shared 41.2% of the market in 2018 with only
Salesforce’s and Adobe’s market share growing faster than the market.
While Adobe dominated in the marketing subsegment of CRM
(19% for Adobe and 11.7% for Salesforce), all the other subsegments
of CRM were dominated by Salesforce. Since 2018, Salesforce grew to
19.5% market share having more than a double of it’s second biggest
competitor, SAP (as visible in the included 1.3 graphics).
In 2019, Adobe and Microsoft decided to offer customers a union-
ized product of Adobe Experience Manager and Microsoft Dynamics
365 CRM in order to gain a competitive edge against Salesforce and
boost the sales and marketing capabilities of both companies.
However, there are also a few CRM vendors that offer free CRM so-
lutions and as a result, the market share of these companies is nowhere
near the subscription-based companies. However, multiple of these
smaller players such as Zoho, Hubspot and others form the rest of
CRM market and we will talk in the corresponding section about the
free possibilities as well.
31. CRM platforms introduction
1.4 Economic relevance of the CRM market
In order to understand the importance of the CRM market, it is neces-
sary to mention that business expenses related to CRM systems made
up close to 25% (48.2 bilion dollars) of the entire enterprise software
revenue market in the world in 2018 (193.6 bilion dollars) [5].
According to Grand View Research[3], the global customer rela-
tionship management market size was valued at USD 40.2 billion in
2019 and is expected to expand at a compound annual growth rate
of 14.2% from 2020 to 2027 (see 1.4). It is also important to mention
the return on investment of CRM platforms. According to Nucleus
Research, investing in CRM software pays back from $5.60 to $8.71 on
average for every dollar spent[6].
41. CRM platforms introduction
1.5 Subscription-based CRM platforms
In this section we will introduce various subscription-based CRM plat-
forms and the basic pricing of their offers to give a financial overview
of the cost of a CRM platform.
This section is dedicated to CRM platforms that have no free plan
meaning that choosing such a CRM automatically equals financials
costs with no possibility of an ongoing free use (many CRM platforms
however offer a free 30-day or 14-day trial, but the trial is often too
short to responsibly decide whether to stick with a CRM or not).
1.5.1 Salesforce CRM
Salesforce is a company founded in 1999 by Marc Benioff in San Fran-
cisco that offers a complete CRM solution for mid-size to large compa-
nies with a pricetag that reflects it.
Starting at $25 per user per month with high-end prices of $300 per
user per month makes it one of the most expensive CRM systems on
the market. Salesforce does offer a 30-day trial of Professional edition
or a 3 months long Essentials edition trial.
51. CRM platforms introduction
Edition Per User Per Month Cost
Essentials (up to 5 users) $25
Professional $75
Enterprise $150
Unlimited $300
The details of Salesforce will be discussed further in chapter 2 as
Salesforce is the primary topic of this thesis.
1.5.2 SAP CRM
SAP was founded in 1972 in Germany and currently has more than
420 000 customers all over 180 countries and 101 150 employees world-
wide focusing on different enterprise software solutions[7] with CRM
forming only one of multiple focusing areas.
SAP released its first CRM in November 2000 and since then, SAP
has consolidated its CRM applications under the terms "Customer
Engagement and Commerce" and offers a variety of applications such
as Customer Profile Management via SAP Customer Data Cloud, SAP
Marketing Cloud, SAP Sales Cloud and many others.
SAP CRM starts at $58 per user per month but does not provide
any further information about pricing until requested directly from
SAP.
61. CRM platforms introduction
1.5.3 Oracle CRM
The history of Oracle CRM tracks back to Siebel CRM Systems, a CRM
software company founded in 1993 and acquired by Oracle in 2006.
Oracle offers On Premises solution where the customer is required
to buy or lease infrastructure, including hardware, operating systems
and databases, and install a packaged system in its data center. An ap-
proach like this was very common in the early 00s and was well suited
for companies who needed complete control over the maintenance of
their CRM application.
Oracle also offers a cloud solution via CRM On Demand, Oracles
Sales Cloud or Oracle Engagement Cloud that is paid for by a monthly
subscription (the same principle as the majority of CRM vendors).
Below is the pricing of Oracle Engagement Cloud, one of Oracle’s
cloud tools.
Edition Per User Per Month Cost
Professional $65
Standard $100
Enterprise $200
Industry $300
71. CRM platforms introduction
1.5.4 Microsoft Dynamics CRM
Microsoft Dynamics CRM development started in 2001 when Mi-
crosoft acquired iCommunicate, a 10 employee web based CRM com-
pany. In 2003 Microsoft CRM 1.0 was released aiming at small and
medium sized businesses offering basic contact and email campaign
management.
The current version of Dynamics CRM is a server-client application
that supports extensive web services interfaces. Clients can access the
CRM by using a browser or by a client plug-in.
The product focuses mainly on sales, marketing, and service (help
desk) sectors, but Microsoft has been encouraging its partners to
use the open-source .NET based framework (which was previously
proprietary) to customize the platform into a robust CRM platform.
Below is the pricing of Microsoft Dynamics 365:
Edition Per User Per Month Cost
Sales Professional $65
Sales Enterprise $95
Customer Engagement Plan $115
Microsoft Relationship Sales $130
81. CRM platforms introduction
1.6 CRM platforms with a free plan
While the majority of the CRM market share is formed by companies
that charge a monthly or annual fee for their services, it is important
to also mention vendors that offer free1 CRM systems. However, in
the universe of software market, nothing is entirely free and therefore
we will include information about pricing of these systems as well.
We decided to include the 2 most relevant2 free CRM platforms to
provide an economic alternative for anyone interested in trying the
added value of a CRM platform without the need of any financial
investment.
1.6.1 HubSpot CRM
Hubspot offers a free CRM platform solution that is primarily aimed
at small businesses and offers integration features for Salesforce, MS
Dynamics and others in case the former small business decides to
scale up to a paid solution.
Hubspot was founded in 2006 at MIT and quickly grew into a
company with $15.6 million in revenue in 2010. In 2019, this number
grew to $674.9 million[8] making it one of the most successful CRM
vendors (along with Zoho) offering any means of a free plan.
1. Free in terms of a non existing subscription fee for at least 1 user. The revenue
is made via additional services that are charged extra.
2. The criteria of the most relevant free CRM in the context of this thesis is simple:
We consider relevant any free CRM platform that has more than 1000 user reviews
on the G2 group available here to narrow the list. Only 2 platforms matched such
criteria.
91. CRM platforms introduction
The possibility of having a free CRM platform emerged in 2014
when Hubspot announced the start of Hubspot CRM Free[9] as a re-
action to Salesforce’s aquisition of Pardot, HubSpot’s rival. According
to HubSpot, the CRM will be free to use forever - even if you’re not a
paying HubSpot customer.
However, nothing is entirely free in the software industry and
Hubspot is no expection. Hubspot’s revenue consists of charging cus-
tomers for using the premium features of their software tools and a
small portion of its revenue is generated through consulting services
and the hosting of events.
1.6.2 Zoho CRM
Zoho CRM is an Indian company founded in 1996 that released the
Zoho CMR in 2005. Zoho CRM is only a part of a broader Zoho app
ecosystem formed of tools for email marketing, invoicing or case man-
agement.
Zoho offers a free plan for businesses with less than 10 employees
and maximum of 3 users of the CRM. According to TechRadar, Zoho
is very easy to use, offers automatic lead creation from social media
and provides a lot of integration possibilities. However, a TechRadar
reviewer also claims that the pricing plan for larger companies can
get too expensive for the value provided, the reporting features are
not fully customizable and the customer service is available via email
only.[10]
Zoho is free for up to 3 users and the pricing for more is as follows:
101. CRM platforms introduction
Edition Per User Per Month Cost
Up to 3 users $0
Standard $12
Professional $20
Enterprise $35
Ultimate $100
1.7 CRM platforms comparison
It is very hard to compare various CRM platforms because of the huge
diversity of the CRM market as well as the different functions each
CRM offers. Each CRM platform provides different subset of the CRM
functionality such as Contact Management, Sales Team and Customer
Opportunity Management, Lead Management, various Reports and
Dashboards, Sales Analytics and the list goes on and on.
Some CRM platforms are suited better for large companies that
require a complete solution which is indefinitely scalable and cus-
tomizable and do not mind the large one-time implementation as well
as large running costs. Smaller business may prefer a solution that is
less financially demanding in order to answer the starting question of
whether they will eventually profit from a more costly CRM platform.
The following table contains the market leaders of 2018 mentioned
in 1.3 as well as the 2 free CRM vendors mentioned in section 1.6. The
table simply describes the entry level price to give a brief overview
of the price of CRM platforms ranked by their market percentage of
2019 according to by Datanyze3 [11].
3. Datanyze calculates market percentage by taking the number of websites using
a technology and dividing it by the total number of websites using any technology
in the same category. The number is not equal 1:1 to market share in revenue.
111. CRM platforms introduction
Vendor Market Percentage Entry Level Price
Salesforce CRM 23.72% $25 /user/month
MS Dynamics CRM 4.25% $115/user/month
Zoho CRM 4.22% $0/user/month
SAP CRM 2.28% $58/user/month
Hubspot CRM 0.63% $0/user/month
Oracle CRM 0.20% $75/user/month
The CRM market is a very competitive place that can drastically
change each year.
However, the trends are obvious: on-premises solutions are on
decline and more and more companies prefer cloud solutions. The
security of the cloud solutions is more robust each year and the main-
tenance costs of paying for a cloud solution are nowhere near hosting
a proprietary data center or any other proprietary alternative.
While Microsoft and Adobe tried to take on Salesforce via forming
a union and offering one shared product, Salesforce retains its market
leader position despite the efforts. Hubspot is trying to beat Salesforce
in terms of financial costs to run a CRM but despite the high running
costs of Salesforce, the market share of Salesforce is growing each year.
Salesforce has become the equivalent of what Apple represents in
the market of mobile phones and in the following chapter, we will try
to analyze Salesforce’s technical and community specifics which we
believe helped Salesforce maintain its market leader position.
122 Salesforce CRM
2.1 History
Salesforce as a company was founded in 1999 by Marc Benioff, a for-
mer Oracle vice president in San Francisco[12] with a goal to de-
liver unique sales software through a model known as Software-as-a-
Service (SaaS).
Salesforce launched its product in 2000 and started to build a whole
ecosystem around it to support it.
In 2003, first Dreamforce conference took place (see 2.2.2) that
evolved throughout the years into a massive 5-day event that attracts
attention all over the world.
In 2005, Salesforce launched its AppExchange, an application store
of Salesforce aps where partners could developer their own applica-
tions and Salesforce customers could find whatever they needed.
In 2006, Salesforce introduced its own programming language
Apex (see 2.3.3 for details about Apex) ant its own java-script frame-
work called Visualforce that enlarged the Salesforce ecosystem even
more.
In 2014, a free learning platform called Trailhead (see 2.2.1) was
launched to help anynone learn and build a career in the Salesforce
industry.
132. Salesforce CRM
In 2015, Salesforce invested into redesigning the Visualforce frame-
work that conserved the relatively consistent look of Salesforce for 16
years. The new look was called Lightning experience and its primary
purpose was to unify the look of Salesforce across all devices.
In 2016 Salesforce invested into a development of its own AI called
Salesforce Einstein and enabled to build apps using the Einstein engine
behind it. par After 2015, Salesforce started acquiring various smaller
corporations to make part of the Ohana1 family.
In 2016 alone, Salesforce acquired over 10 companies [12]. In 2018,
Salesforce acquired Mulesoft for $6.5 bilion dollars and in 2019 Sales-
force topped this acquisition record with acquiring Tableau for $15.7
bilion dollars.
In the following two sections, we will describe multiple technical
and non-technical aspects of the Salesforce platform that the author be-
lieves were a huge contribution to Salesforce’s market leader position
of 2019 (see the CRM market graph of 1.3).
2.2 Salesforce - community specifics
In this section, we will look at some of Salesforce’s community specifics
that, to the belief of the author, help Salesforce maintain its market
leader position by supporting the growth of number of people who
are involved in Salesforce’s ecosystem and thus secondarily driving
sales of Salesforce licenses.
2.2.1 Trailhead - the Salesforce learning platform
Trailhead is a series of online tutorials that coach beginner and inter-
mediate developers who need to learn how to code for the Salesforce
platform. Trailhead education, which was launched in 2014, comes
in three levels: trails, modules and units. Lessons are presented in a
specific sequence, so customers have a predefined path to follow and
a "guided, curated" experience, according to Salesforce.
1. In 2004, Salesforce started to brand the platform with Hawaiian references such
as Ohana which means ’family’ in Hawaiian. Salesforce uses the term Ohana to
define the Salesforce community.
142. Salesforce CRM
The learning program is designed to help users by providing a
series of interactive assessments to identify whether learners have
learned the content. Gamification is built into the Trailhead program,
so developers can also earn badges for milestones reached in their
Trailhead education. [13]
Containing more than 700 different modules[14] consisting of
multiple exercises to help to learn all that is about Salesforce, the Trail-
head learning platform became a reliable learning tool for Salesforce
developers when it comes to acquiring new Salesforce skills.
2.2.2 Dreamforce - the Salesforce yearly conference
Another of the community specifics of Salesforce is the organization
of an event called Dreamforce.
Dreamforce started in 2003 as a regular conference of Salesforce
oriented professionals and grew into a global event with 170 000
registered attendees, hosting a Metallica concert in 2018[15].
Dreamforce is an annual four-day event that brings the Salesforce
community together, including both current and potential clients as
well as the companies that help with implementation of Salesforce. It
is also open to anyone else from the public interested in any aspect
of this CRM. That includes Salesforce professionals such as admins
or developers, entrepreneurs on the side of the partners and general
managers of various companies on the side of the clients.
Formerly this paragraph contained information about the upcom-
ing Dreamforce of 2020 and the future of this conference, but when the
first draft of this thesis was being completed, Salesforce announced
that Dreamforce 2020 will not take place live but only online due to
the world-wide pandemic of the coronavirus[16].
While the author of this thesis believes that Salesforce will heavily
invest into Dreamforce 2021 in terms of breaking its own records of
attendance, the immediate future of this event remains unclear for
now (May 2020).
152. Salesforce CRM
2.3 Salesforce - technological specifics
In the following section, we will take a closer look at various technol-
ogy Salesforce takes advantage of. This includes its own programming
language as well as governor limits ensuring the same amount of com-
putational power for everyone.
2.3.1 Multitenancy
Salesforce is a multi-tenant platform meaning that each all of the so-
called ’orgs’ 2 run in the same physical environment and are divided
into respectable virtually stand-alone instances.
These orgs share the physical resources and in order for each of
the tenants3 to have guaranteed storage and CPU, Salesforce enforces
strict limits on these resources.
Multiple tenants share a hidden, common infrastructure, yet utilize
a defined set of highly secure services, with complete privacy from
other tenants. In the same manner as a bank client owns a secure
private account yet shares the bank security benefits as the other
clients, a cloud uses multitenancy technology to share IT resources
among multiple applications and tenants that use the cloud[17].
2.3.2 Limits
Because Apex runs in a multitenant environment, the Apex runtime
engine strictly enforces limits so that runaway Apex code or processes
don’t monopolize shared resources. If some Apex code exceeds a limit,
the associated governor issues a runtime exception that cannot be
handled[18].
Here is a table of few of these limits to provide a hands-on overview
of these limits4 :
2. Org is a specific Salesforce term used for an environment instance that is virtually
separated from others in a same manner as a virtual machine is separated from its
host machine.
3. Tenant in this context is a single client who is leasing the computational power
of Salesforce.
4. The limit in this context is the synchronous limit as opposed to an asynchronous
limit which is less restrictive (but in the context of this thesis redundant for show-
casing the nature of the feature)
162. Salesforce CRM
Description Limit
SOQL queries issued 100
Records retrieved by SOQL queries 50 000
SOSL queries issued 20
DML statements issued 150
Total heap size 6 MB
Max CPU time 10 000 ms
While these limits may appear too severe and restricting, the en-
forcement of these limits guarantees the properties of a true multi-
tenant environment that provides the same CPU power, database
access speed or database storage to each of the tenants.
2.3.3 Apex - Salesforce programming language
It is important to dedicate more space to Apex, the programming
language of Salesforce as the whole practical part of this thesis is
written in this language.
Apex, which is similar to Java in many respects, is a powerful object-
oriented development language developed by the Salesforce.com plat-
form developers can use to centralize procedural logic in their appli-
cation schema.
However, there are certain differences between Apex and Java (see
this manual page for details). The most important ones are:
∙ The language is case-insensitive5 .
∙ The private access modifier is the default, and means that the
method or variable is accessible only within the Apex class in
which it is defined.
∙ Static methods and variables can only be declared in a top-level
class definition, not in an inner class.
∙ An inner class behaves like a static Java inner class, but doesn’t
require the static keyword.
5. Many Salesforce developers including the author of this thesis write Apex code
as case-sensitive to maintain the Java-like feel and readability of the language.
172. Salesforce CRM
Figure 2.1: Apex code example - example taken from wisdomjobs.com
∙ Methods and classes are final by default.
∙ Exception classes must extend either exception or another user-
defined exception and the name of every exception must end
with the word ’exception’.
Apex code can declare program variables and constants, execute
traditional flow control statements (if-else, loops, etc.), perform data
manipulation operations (insert, update, upsert, delete), and transac-
tion control operations (setSavepoint, rollback).
With the addition of a simple keyword, developers can use Apex
to support many unique application requirements. For example, a
developer can expose a method as a custom RESTful or SOAP-based
API call, make it asynchronously schedulable, or configure it to process
a large operation in batches.
Many standard Apex classes and system static methods provide
simple interfaces to underlying system features. As an example, the
system static DML methods such as insert, update, and delete can be
modified by a simple Boolean parameter to indicate the desired bulk
processing option (all or nothing, or partial save).
2.3.4 SOQL - Salesforce Object Query Language
Salesforce developers can use the Salesforce Object Query Language
(SOQL) to construct simple but powerful database queries. Similar
to the SELECT command in the Structured Query Language (SQL),
SOQL allows a developer to specify the source object, a list of fields to
retrieve, and conditions for selecting rows in the source object.
182. Salesforce CRM
For example, the following SOQL query returns the value of the
Id and Name field for all Account records with a Name equal to the
string ’FI MUNI’.
SELECT Id, Name FROM Account WHERE Name = ’FI MUNI’
2.3.5 SOSL - Salesforce Object Search Lanuage
The platform also includes a full-text, multi-lingual search engine that
automatically indexes all text-related fields. Applications can leverage
this pre-integrated search engine using the Salesforce Object Search
Language (SOSL) to perform text searches.
Unlike SOQL, which can only query one object at a time, SOSL en-
ables the developer to search text, email, and phone fields for multiple
objects simultaneously.
For example, the following SOSL statement searches for records in
the Lead and Contact Salesforce objects that contain the string ’Jakub’
in the name field and returns the name and phone number field from
each record found[17].
FIND "Jakub" IN Name Fields RETURNING lead(name, phone), con-
tact(name, phone)
193 Integrations - implementation approaches
Prior to introducing the Salesforce module app that fulfills the purpose
of the data integration, it is necessary to analyze potential approaches
to leave no space for possible doubts about the chosen approach.
3.1 Introduction
Whenever a continuous stream of data travels from one point to an-
other, three main parts are required. The source, the target and the
active component that performs the transfer (this can be either on the
side of the source, the side of the target or completely external).
Because of the high dynamics of how systems evolve and these
evolution require some ongoing maintenance, it is often wiser to keep
the amount of components to a bare minimum. Therefore, if possible,
it is often better to not use external 3rd party components but rather
use either the source or the target as the active component.
For the sake of this thesis, we will use two main terms that are
widely used in the company of the author, pulling and pushing.
Pulling would always mean using the target as the active com-
ponent, in this case Salesforce, and pushing would mean using the
source as the active component. We will talk about the advantages
and disadvantages of both in the upcoming sections.
In general, the approaches are equivalent as they depend solely
on the technical aspects and attributes of the involved technology, but
experience shows that it is crucial to make the right call as the techno-
logical capabilities of target and the source may differ significantly.
We will try to focus on these approaches with regard to Salesforce
and its particular characteristics with regard on obstacles that are often
faced when such an integration gets implemented in the real world.
3.2 Pulling
Pulling is a term used to describe a situation where Salesforce acts as
the active component of the integration meaning that the code runs
203. Integrations - implementation approaches
from within Salesforce and the external server acts solely as a data
source that is accessed by Salesforce’s code.
3.2.1 Requirements
We assume that anyone choosing pulling is familiar with Salesforce,
its programming language Apex (introduced in section 2.3.3) and the
structure and configuration requirements (mentioned later in 5).
The requirements for successful implementation of a pulling ap-
proach are:
∙ Access to the external server (may require credentials and/or
configuration)
∙ API for accessing the data
3.2.2 Advantages
The main advantage of this approach is that when the active compo-
nent is on Salesforce’s side (which will also be the case of the example
shown in chapter 4), the developer can take full advantage of the Java-
like environment (as described in section 5.4) to program a component
able to periodically prompt for new data while respecting various web
protocols thus ensuring maximum security.
Apex tools enable the developer to easily form and send Http
requests, receive Http responses, encode or decode content, schedule
the code to run at a certain period or continually work through a large
amount of data if the amount is too large to process at once.
It is important to note that the mentioned perks are often impos-
sible to recreate in the legacy 3rd party systems that in majority of
cases play the role of the source (the client would like to cease using
the 3rd party system, but that can often prove to be difficult as during
the decades all the historical data got accumulated in this old, legacy
database).
3.2.3 Disadvantages
The obvious disadvantage of ’pulling’ is the large amount of code lo-
cated in Salesforce org that may collide with other Salesforce function-
213. Integrations - implementation approaches
ality (and often does) such as Process Builders, Workflows, Triggers,
etc1 .
The code also requires to pass the 75% code coverage requirement
meaning that in addition to the code development, a developer choos-
ing this approach is also obligated to build Salesforce unit tests for the
code as well.
As if that was not enough, the part responsible for the integration
becomes only a one part of the whole colossal Salesforce system the
client has and as a result of incomplete overview of the system, the
client may eventually put contradictory rules into place (an example:
Never allow a record to be saved without an attribute X but the at-
tribute X is not included in the integration of the 3rd party database)
that may compromise smooth execution of the code.
Another disadvantage (from the point of the view of the client) is
that there is a huge probability that the client is not as familiar with
Salesforce as he is with the 3rd party application (often the application
is developed directly by the client). This is not surprising as if the
client was familiar with Salesforce, he would not require a dedicated
Salesforce developer to help him with such an integration in the first
place.
3.3 Pushing
The term ’pushing’ stands for the opposite of ’pulling’ which in this
context means that Salesforce takes the role of a passive listener and
the external server or 3rd party takes the role of an active component
that forms requests.
3.3.1 Requirements
Even though the pushing alternative has more challenging require-
ments it may be the way to go for anyone who prefers to develop
outside the Salesforce’s ecosystem (after fiddling with the configura-
tion of the Salesforce org first to allow such integration to run).
1. Process Builders and other mentioned tools are easy to set up Salesforce Admin
components that often have the same level of access as the developed code which
may cause severe collisions when such components pose restrictions on database
operations.
223. Integrations - implementation approaches
The requirements for a successful pushing alternative are as fol-
lows[19]:
∙ Create a Salesforce developer account
∙ Set up a Connected App
– Choose App Name - can be anything like ’TestApp1’
– Enable OAuth Settings
– Specify Callback URL - any secure webpage where you
want the data to be sent afterwards
– Choose OAuth Scopes - Access and manage your data
(API)
Once the setup of the App is done, Salesforce will redirect you to
the details of the App from where you can access the Consumer Key
and the Consumer Secret required in the app later when communicat-
ing with Salesforce.
You can also choose to generate an initial Access Token that will
be later used for accessing data or leave the token generation for later.
3.3.2 Advantages
The advantage number one of this approach is the independence from
Salesforce (if that is the objective).
Salesforce acts as a listener that waits for instructions from your
external server and will take no action other than those that you sent
through the Connected App.
You can also easily turn the integration off from your own envi-
ronment by turning off the Connected App or by simply stopping
sending requests to Salesforce.
3.3.3 Disadvantages
The obvious disadvantage is the complex configuration one needs to
complete prior to development as well as the need to fully understand
the data and security flow of the Connected App mechanism.
Salesforce enforces heavy security on any communication coming
through and this may turn out to be too much time consuming to
overcome and therefore not economic to pursue.
233. Integrations - implementation approaches
3.4 Conclusion
It is hard to decide with certainty whether it is more costly to hire
a Salesforce developer to develop the pulling functionality or go for
pushing variant and simply hire a Salesforce consultant to help with
the configuration of the Connected App and do the rest of the devel-
opment externally.
Both approaches lay out specific challenges to overcome as well as
responsibilities to bear in mind and each project or client may require
different approach depending on client’s needs, internal development
team and finances.
As the author of the thesis specializes in Salesforce development
in Apex, we will present a case of a project that took advantage of the
pulling appraoch.
244 Author REST application - case study
4.1 Introduction
In this chapter an author application is about to be introduced that
sums up the theoretical knowledge introduced above into a concrete
piece of code.
4.1.1 Context
Jakub Hančin, the author of this thesis is a professional Salesforce
developer (certified as Platform Developer I) working for a San Fran-
cisco based company called SaaScend which specializes in helping
companies adopt Salesforce as their CRM.
This adoption includes administration as well as development
work is aimed at making Salesforce the primary sales hub o the com-
pany.
The development work often includes the integration of 3rd party
applications of which one was chosen to serve as an example for the
practical part of this thesis.
4.1.2 Project context
In June 2019, LeanTaaS company paid Saascend - a Salesforce consul-
tancy company to provide help with migration to Salesforce which
LeanTaaS recently made a decision to move their agenda to.
The project consisted of multiple objectives such as internal Sales-
force customizations, Hubspot1 integration, Outreach2 implementa-
tion and other custom features.
One of the objectives was to integrate data from the source database
of Definitive into Salesforce. This task was given to the author of this
thesis, Jakub Hančin with the supervision of Craig Jordan, the owner
of SaaScend and seasoned Salesforce admin.
1. HubSpot offers a platform of marketing, sales, customer service, and CRM
software - we could consider it a Salesforce competitor of sorts.
2. Outreach is a sales engagement platform that allegedly ’helps efficiently and
effectively engage prospects to drive more pipeline and close more deals’.
254. Author REST application - case study
4.1.3 Description of the objective
??
The goal of the integration was to provide a company called Lean-
TaaS a solution that would mirror the contents of a database of hospi-
tals and related agenda into Salesforce.
The data was stored in a database managed by a company called
Definitive Healthcare with a publicly shared API (available here) and
thorough documentation on how to access the data.
The data format used on the server side was traditional JSON
and the desired entities to integrate were Hospitals that were to be
synchronized as Account objects in Salesforce and News Items that
would get a new custom object in the Salesforce system.
4.1.4 Project - team & pre-project analysis
While the whole project contained more SaaScend members, the Defini-
tive integration fragment relevant to this thesis consisted of:
∙ Jakub Hančin (SaaScend) - Salesforce developer
∙ Craig Jordan (SaaScend) - project supervisor
∙ Allie Fahner (SaaScend) - project communicator
∙ Joseph Belotti (Definitive) - Definitive engineer
While the whole Definitive integration (in terms of the case study
of this thesis) was written by the author of this thesis himself, the
results were tested, examined and validated by Craig Jordan to provide
feedback. Another member of SaaScend, Allie Fahner helped with the
communication and client facing during the project. Joseph Belotti
from Definitive helped with forming a sample query for the Definitive
server and later John helped with validating specific queries required
for successful continuous data integration on the Definitive Healthcare
side.
The initial analysis showed no unusual obstacles and therefore
the initial educated guess on the amount of hours for the project was
roughly estimated to 60-70 hours of development work.
264. Author REST application - case study
4.2 Obstacles to overcome
As every integration project this one as well was all about anticipating
and overcoming obstacles. Prior to the start of the development, the
client requested an educated guess on the number of hours for the
project. To provide that, an analysis of the obstacles was made.
Those obstacles included mutual inconsistency of data format of
the source and the target, secure authentication & authorization and
various transformations that are sure to be required but remain un-
known upfront.
We will discuss these obstacles in detail and propose a potential
solution that is to be explained in a detailed and more technical manner
in the chapter 6.
4.2.1 Data heterogeneity
It was expected that the source and the target data values will differ
as well as it wass expected that the potential mistakes of storing data
inconsistently will not be carried over from the legacy source database
to the target.
E.g. a datetime field format in the source database may not be
compatible with the datetime format of the target or a value that even
though represents a numeric value may be stored as a String in the
source database while the client wants to store it as a numeric value
on the target side.
4.2.1.1 Solution
The solution to this difference in the structure of the returned data
was simple. Programatically reformat each entry to the desired format
based on the previous analysis of a returned sample data-set.
As the target is Salesforce CRM, this can be easily done via Apex
in the very same manner as this can be done in Java language or per
se in any other programming language adjusted to working with an
array of alphabetical characters or better known as a String class.
274. Author REST application - case study
4.2.2 URL encoding query requirement
For protocol reasons, it was required in order for a query to be valid to
encode the query in URL encoded format that is sometimes referred
to as percent encoding.
The URL encoding is rather simple. URLs can only be sent over
the Internet using the ASCII character-set. Since URLs often contain
characters outside the ASCII set, the URL has to be converted into a
valid ASCII format. URL encoding replaces unsafe ASCII characters
with a "%" followed by two hexadecimal digits[20].
4.2.2.1 Solution
The solution to this obstacle was rather trivial. It was required to write
a simple parsing function (the set of native static Apex classes do
not provide this) that would translate a string of characters into a
URL encoded format thus replacing certain reserved characters with
appropriate symbols.
For the purposes of this integration, two simple character replace-
ments sufficed to get rid of the problem.
∙ Each space character ’ ’ is replaced with ’%20’
∙ Each double quote character ’"’ is replaced with ’%22’.
4.2.3 Periodicity
The client requested to perform daily updates of the Definitive Health-
care database in order to keep the CRM database up to date. More
frequent updates were not necessary as the source database got up-
dated once per day as well.
4.2.3.1 Solution
Salesforce by default offers Apex solutions to provide such functional-
ity, therefore this requirement can be easily met.
284. Author REST application - case study
4.2.4 Authorization
The standard obstacle of integrating multiple systems together is over-
coming authorization. The authorization is always a little different for
each project, but the principles stay the same. Include the credentials,
get authorized and get provided the requested data. In the case of the
LeanTaaS project, the approach was quite simple
(as mentioned at https://api.defhc.com/v4/Documentation):
Query with the credentials via a POST request for an access token
that would authorize the following data requests. The token is used in
all following requests as an authorization element. The token, however,
expires in 86,399 seconds (which equals 23 hours 59 hours 59 minutes).
Once the request containing a valid access token and correctly
formed query was sent, the server returned a JSON document con-
taining the requested data. If the token was invalid or expired, the
server returned an authorization error message.
The flow could be summarized as follows (for more details see
4.1):
1. The client requests the access bearer token from the server
with client credentials.
2. If the credentials are valid, the server returns a valid access
token valid for 24 hours.
3. The client requests data with the access token.
4. If the token is valid and the query is well formed, server returns
the desired data.
4.2.4.1 Solution
Salesforce allows the developer to store essential configuration items
such as access tokens in an object called Static Resource.
However, these objects cannot be created from within the platform
programmatically without the usage of a callout via METADATA API
(these are the restrictions of the platform) [21]. In order to use Static
Resource object for this, one would need to download the METADATA
API package (available here) and include the 2MB of data in the same
folder where your custom code is or go through the downloaded code
294. Author REST application - case study
Figure 4.1: Authorization process modeled by Jakub Hančin in Sig-
navio modelling software
304. Author REST application - case study
and delete everything obsolete which is time consuming and not a
trivial task.
For these reasons, it was decided to not go through with the option
of a Static Resource approach.
Another option to accomplish the same result is to create an in-
stance of an object called Custom Setting. Custom setting is an internal
object used frequently to store custom configuration information. The
object is able to store multiple custom String fields of maximum length
255.
As it was previously tested that the access token is never longer
than 512 characters, the author of this thesis decided to create 3 custom
fields of length 255 in the custom object of the Custom Setting type
(the longest case of an access token would sum up to 255 + 255 + 2).
While it may seem odd to solve such a problem in this manner, the
approach proved to be the most simple one and sufficed to complete
the objective.
315 Author REST application - pre-development
setup
The next step once the theoretical analysis of the problem was done
was the setup of the Salesforce org for development of the integration.
There were multiple configuration actions that were needed to be
done prior to starting of the development itself.
5.1 Sandbox - testing environment
The obstacle number one Salesforce created for proper development
process was the fact that no code can developed on the Production
org (for a definition of an ’org’ see section 2.3.1).
For development and other testing purposes one needs to clone
the Production org into a special development org called Sandbox
(the similarity between the chosen name and a children playground
is not coincidental).
Depending on the license of the client, the sandbox can be of mul-
tiple types [22], the most important differences are as follows:
Storage Data copy
Developer 200MB Metadata only
Developer Pro 1GB Metadata only
Partial Copy 5GB Sample of data + Metadata
Full Copy equal to production All data + Metadata
5.1.1 Configuration
Once the sandbox was created it was required to enable the specific
sandbox to upload its change sets directly to production. This can be
easily done (but it is often forgotten and therefore important to stress
out) from Setup -> Deployment Settings as visible in the screenshot
of 5.1.
325. Author REST application - pre-development setup
Figure 5.1: A screenshot of Deployment settings - sandbox allowance
5.1.2 Change set - uploading changes from a sandbox to
production
Once the functionality is developed in the sandbox and the sandbox is
allowed to make inbound changes, it can get uploaded into production
where the validation process begins.
Once uploaded, the changed functionality has to pass successful
testing (unit tests need to be developed along the core functionality).
In order for the code to be validated, the code needs to have at least
75% code coverage by the unit tests.
Then and only then can be the code deployed to production. Scripts
such as the one written in 7.1 that are part of Anonymous windows
do not count as deployed code.
This approach tries to prevent incomplete or poorly written code
from affecting the production.
335. Author REST application - pre-development setup
5.2 Org preparation
As mentioned in 4.2.4.1, multiple customization of the org where the
development takes places are needed prior to writing the code itself.
This includes the creation of new objects and fields as well as minor
configuration changes.
5.2.1 Custom object creation
When a client desires to map any of the external objects to Salesforce,
the first course of action any seasoned Salesforce developer should
take is to try to map such an object to an already existing Salesforce
object.
In our case, we discovered that the client’s data revolved around
hospitals where Hospitals were the crucial object everything was
involved in.
For such reason, it was decided to map the Hospitals records to
Accounts and create custom Salesforce fields for the fields that are not
present by default (see subsection 5.2.2 on creation of custom fields).
However, for objects that do not have a Salesforce equivalent or
have their Salesforce equivalent already taken by an another external
object, it may be wise to consider creating brand new custom objects
that would store the information.
This can be easily accomplished from Setup -> Object Manager in
Salesforce as visible in the screenshot of 5.2.
As mentioned in the subsection ??, it was decided to map Hospitals
to Accounts (native Salesforce object) and News Items to a brand new
custom object of the same name.
These custom objects have a special namespace suffix ’__c’ differ-
entiating them from native Salesforce objects.
It is for this reason that the brand new custom object was be called
NewsItems__c.
An alternative to that would be News_Items__c but it was decided
to omit spaces in a similar manner as Salesforce does for simplicity
(e.g. CampaignInfluence objects or OpportunityContactRole objects
omit spaces instead of replacing them with an underscore).
345. Author REST application - pre-development setup
Figure 5.2: A screenshot of Object Manager - creation of Custom Ob-
jects
5.2.2 Custom field creation
Once the objects are in place (whether custom or native), it is required
to create (if need be, each project may be different) custom fields
which would be storing the actual values in their respectable data
type.
This is again easily done via Setup -> Object Manager as seen in
the screenshot of 5.3.
Same as for custom objects, custom fields have the ’__c’ suffix mean-
ing that a custom field of HospitalId that was named ’defin_HospitalId’
would in reality be stored as ’defin_HospitalId__c’.
35You can also read
