Business decisions taken by Salesforce users are often made based on data coming from other systems (e.g. data submitted by customers through the company website). To facilitate these decisions Salesforce teams have to configure additional custom fields and plug them into data pipelines. This is a tedious process that might be frustrating, not only for developers, who have to maintain myriads of custom fields but also for the end-users, who have to wait weeks until a new field with the desired data appears in their layout. Recently I have realized that there are two types of entity attributes in our Salesforce organization: those that trigger automatic events (e.g. email dispatch) and those that are observed by human eyes only. The latter attributes do not have to be BROUGHT into Salesforce, it is enough if they are only SHOWN there. That is why in Billie we have developed a generic Lightning Web Component, named “Database periscope”, which is placed on an Account/Contact/Opportunity object and which shows data directly from the backend database to the end-user. When a record is opened in Salesforce by a user, this component issues an asynchronous call-out with the data request, receives JSON with all the available attributes and presents them in a grid. This component saved us many hours of development and gave internal stakeholders access to data in real-time. In my presentation, I would like to explain step-by-step how a similar solution can be built and discuss its advantages and limitations.

1. Database periscope:
An alternative to custom fields
by Igor Chtivelband

2. #CD22
B.Sc. in Information Systems Engineering
Double M.Sc. in Software Engineering
VP Data & Salesforce

3. #CD22
I wish I had a dollar for every time I heard this
Hey Igor, engineering team X recently
released a new feature, so customer’s
attribute Y is now available in the prod
database.
Can we have it in Salesforce as well?

4. #CD22
* Assuming that your company’s pockets are not deep enough for Salesforce Connect, etc.
We all know what usually* happens next …
A diligent Salesforce
Admin creates a new
custom field
Same diligent
Salesforce Admin
adds this field to
object’s layout
An angry Data
Engineer adjusts
the reverse ETL
pipeline, which
pushes data to
Salesforce

5. #CD22
But what if the desired attribute doesn’t actually
have to reside in Salesforce?
Maybe it is enough just to show it there!

6. #CD22
Simplified Architecture Diagram

7. #CD22
1. Expose database via REST API endpoint
1. Develop a data service class (Apex)
1. Build a custom Lightning Web Component
Steps in building such solution

8. #CD22
Main alternatives
Expose database via REST API endpoint
Some DBs provide such
functionality out of the box
Middleware tool Custom development

9. #CD22
Three musketeers can help us
Develop a data service class (Apex)
Named Credential
for storing API
credentials and
whitelisting the callout
endpoint
Custom Metadata for
managing database
queries
HttpRequest Apex class

10. #CD22
Build a custom Lightning Web Component
Input Output
- Name of the object field with the
unique identifier (e.g. UUID__c)
- Master Label of the Custom Metadata
with the query
Grid with the results of the query

11. #CD22
Demo

12. #CD22
- No field level security
- Not possible to trigger actions, based on the fields values
- No reports/dashboards
- High dependency on the database schema
However there are some issues…

13. Thank you! #CD22