Tempora incidunt ut labore et dolore magnam aliquam
quaerat voluptatem enim ad minima veniam quis.

See All
  • Import Content

    Content Document :

    It Represents a document that has been uploaded to a library in Salesforce CRM Content or Salesforce Files. The maximum number of documents that can be published is 30,000,000. This object record you don’t have to create. It gets created when you create ContentVersion which is the child of ContentDocument.

    Content Version:

    Represents a specific version of a document in Salesforce CRM Content or Salesforce Files. In other words, this object stores document information similar to Attachment.

    Import ContentDocument & ContentVersions

    Prepare the CSV file to insert to the ContentVersion object

    • Create a CSV file with the below fields..
      Title – (Required) file name
      VersionData – (Required) complete path to the file you’re uploading from your local machine or drive
      Description – (Optional) link description or file
      PathOnClient – (Required) complete path to the file you’re uploading
      FirstPublishLocationId – (Optional) if you are only relating the File to a single record in Salesforce, populate this with the related record’s Id. This automatically creates a ContentDocumentLink to associate the file to the related record to effectively skip the ‘Prepare a CSV and perform an insert to the ContentDocumentLink object to associate Files to records’ steps below

    Notes :

      • Setting FirstPublishLocationId is only applicable on insert of new files and the field does not accept updates
      • The Sharetype of the created ContentDocumentLink to the related record is Visible by Default

    • Open data loader and login
    • Select Insert and select Show all Salesforce objects
    • Select ContentVersion
    • Browse to your CSV file
    • Click Create or Edit a Map then select Auto-Match fields to columns
    • Click OK | Next | Finish

    Create a CSV and perform an insert to the ContentDocumentLinkobject

    • You can use Data Loader for exporting data from the ‘ContentVersion’ object to get ‘ContentDocumentId’ for your newly created Files
      • Note : If you specified FirstPublishLocationId on File insert, the following steps are only necessary to associate the newly created Files to additional records in Salesforce
    • Create a CSV file with the following columns:
      • LinkedEntityID – (Required) ID of the related record that the file is associated with (Accounts or Opportunities)
      • ShareType – (Required) the permission granted to user. For valid values, see the ‘Description’ details for the field in the ContentDocumentLink | SOAP API Developer Guide
      • ContentDocumentID – (Required) ContentDocumentID from the exported ContentVersion file (starts with ‘069’)
      • Visibility – (Optional) Specifies whether this file is available to all users, internal users, or shared user. Refer to the field’s ‘Description’ details in the guide linked above
    • Now Open Data Loader and click on Insert
    • Select the Show all Salesforce objects
    • Select ContentDocumentLink
    • Browse to your CSV file
    • Click Create or Edit a Map then select Auto-Match fields to columns
    • Click OK | Next | Finish

    Some important Points :

      • While inserting the ContentVersion, create a new custom field to store the legacy content version Id and Content Document Id
      • Now, after inserting the ContentVersion export the data with the new fields that you created
      • While preparing the file for Content Document Link you can use VLOOKUP to get the New Content Document Id based on the Legacy Content Document Id

  • Flow

    What is a Flow in Salesforce?

    Flow is an application inside the Salesforce that automates a business process by collecting data and performing operations in your org or an external system. Flow can fetch, delete, update and create records on multiple objects.

    Flow Builder is the declarative interface used to build individual flows. Flow Builder can be used to build code-like logic without using a programming language.

    Types of Flow:

    Screen Flow

    Requires user interaction because it includes screens, local actions, steps, choices,or dynamic choices. Screen flows don’t support Pause elements.

    Autolaunched Flow with No Flow Trigger

    Doesn’t require user interaction. This flow type doesn’t support screens, local actions, choices, or choice sets.

    Autolaunched Flow with a Schedule Trigger

    Runs only from a schedule. This flow type doesn’t support user interaction, screens,local actions, choices, or choice sets.

    Autolaunched Flow with a Record Trigger

    Makes before-save updates to the new or changed record that launches the flow. Only these elements are supported: Assignment, Decision, Get Records, and Loop.

    User Provisioning Flow

    Provisions users for third-party services. For example, use this flow type to customize the user provisioning configuration for a connected app to link Salesforce users with their Google Apps accounts.

    Field Service Mobile Flow

    Requires user interaction because it has one or more screens.

    Field Service Embedded Flow

    Requires user interaction because it has one or more screens.

    Contact Request Flow

    Requires user interaction because it has one or more screens.

    Checkout Flow

    Used in Lightning B2B Commerce to create a checkout for your store. Requires user interaction because it has one or more screens.

    Below is an example of a schedule-triggered flow, pulled from a well-known Salesforce group:

    When or Why should flow be used?

    We need to know what automation is needed. In most cases, the type of automation is determined by evaluating where the data for the processes originates from and where it needs to go. Consider whether what you need to accomplish is best handled by a flow, workflow field update, or a process.

    • The workflow field update can write data to the same record that invoked the workflow rule, or to the master record of a master-detail relationship on the record that invoked the rule. Workflow rules are not able to create, edit, or delete records.
    • Flows are able to create, edit, and delete any record passed into the flow. Records do not have to be related in order to pass data in a flow. Flows can also be scheduled to run on a set interval with a collection of records.
    • Processes, created in the Process Builder, can write data to the same record that invoked the process, or to records related by either lookup or master-detail relationships. Processes can also create records, but they cannot delete them.

    How to create a flow in Salesforce?

    To create the flow, follow these steps:

    Go to Setup -> Quick Find Box -> Search for “Flows” -> Click on Flows -> Then Click New Flow

    It will open below screen.

    You can create any of the four flows. Here I am creating Autolaunched Flow which will send an email to the selected users when a lead is created. For that I am creating a flow:

    First, I’ll get the record from any of the object using any source of the flow, for that first we need to create a new resource of data type record:

    Then you need to go to the elements tab:

    Then run the flow:

    And the mail will be sent to the Lead Owner.

    Flows vs. Apex

    • Apex code requires a developer and Sandbox to deploy, meaning it can only really be built in organizations using a Professional or above edition of Salesforce. Flows can be built in all editions, as a Sandbox is not required for deployment.
    • Apex is not available in Essentials, and some Apex features are limited in Professional. Organizations with Enterprise and above have no Apex limitations, but flow features are not limited based on the edition.
    • Apex code requires constant development and discipline to maintain. Flows require less work to keep up-to-date.
    • Flows can be built by admins, while Apex code is typically built by developers only.
    • Apex code is considered a tool of last resort. Flows are simpler and should be used before Apex code.
    • If the logic is too complex, Apex code should be used. There is unlimited potential with Apex; flow capabilities are catching up, but they are still inferior to Apex.
    • Renewal generation, OLI creation, and other pieces of automation that were traditionally built as Apex code can now be built as flows, preserving code space for projects that require Apex.

    Apex code should be used in the following scenarios:

    • You’re dealing with complex Salesforce automation that requires multiple steps and actions where a flow will become cumbersome.
    • You need custom-built integrations with other systems (such as a connection to a SQL database that requires bi-directional syncs).
    • ERP integrations are involved.

    Flows vs. Processes

    • Processes are more user-friendly as far setup and management goes. Setting up a flow takes more time and is significantly more complex.
    • Flows allow you to add screens where users can enter data. Processes do not have this capability.
    • Flows can be invoked, started by users, triggered by a record change, or scheduled to run on their own at a custom time and frequency. A process, however, runs automatically (either immediately or scheduled) when criteria is met. It can also be invoked by another process created in the Process Builder.
    • Both flows and process can include scheduled actions.
    • Flows can be paused by users, but processes run when the criteria is met and cannot be paused.
    • Flows and processes both contribute to CPU limits and other automation limits in Salesforce.
    • Process actions are executed in the order in which they appear in the process definition, but flows can have different and more complex orders of operations.
    • Flows can be built to cycle through multiple unrelated and related objects. Processes, however, are limited to the base object (opportunities, for example) and related objects (accounts).
    • The following actions are only available for processes:
    • Quip actions
    • Send survey invitation
    • Invoke a flow
    • Flows can be designed to run either before or after a record has been saved to the database, but processes can only trigger after a record has been saved.
    • Flows can be designed to trigger upon creation, update, or deletion of a record. Processes can trigger only for creation or updates to a record.

    Here are a few real-life examples of where a process makes more sense than a flow:

    • You need to automatically submit an opportunity for approval when the value in the Amount field is greater than $200,000.
    • When an account is deactivated, you want to deactivate all the associated contacts.
    • After creating a new user or internal contact, you want to create a case for background verification.
    • You need to invoke custom approval logic that is written in Apex code.

    Flows vs. Workflow Rules

    • Flows are available in all Salesforce editions, including Essentials. Workflow rules (WFRs) are not available in Essentials or Professional editions.
    • WFRs are not actively being updated by Salesforce (but you can still use them for the time being). Flows are constantly being updated with new features and capabilities in each Salesforce release.
    • There are limitations with how many WFRs can be active at once, but they typically do not contribute to CPU limits unless the WFR triggers a process or flow through one of its updates (such as a field update).
    • Both flows and WFRs can have scheduled actions, but WFRs are limited to 1000 triggers per hour.
    • WFRs can only make one decision, but you can call other flows and Apex code with a flow.
    • WFRs are limited to just a few actions: creating a task record, sending an email, updating a field, or sending an outbound message. Flows can do all of these actions and many more.

    This is a use case where a WFR makes more sense than a Flow.

    • You want simple field updates, such as outbound emails or sending email alerts when high priority cases are created.

    How to launch a Salesforce Screen Flow from a button?

    First, go to Setup > Object Manager and locate the object you want to add the button to. That’s the Opportunity object in our case. On the left side of the screen, select “Buttons, Links and Actions” and then click “New Action”.

    The New Action screen looks like this:

    Change the Action Type [1] picklist to Flow. The next field will change to a picklist of available Screen Flows [2]. If you don’t see your Flow in this list, go back and check that a) it’s a Screen Flow, not an Autolaunched Flow and b) that you set it to active in the Flow Builder.

    Select your Flow.

    Enter a Label and Name, then click Save. Note that the label is what the text the button will show in the UI so keep it fairly short.

    Go to Page Layouts in the left nav and click into the page layout you’re using for this record type:

    In the layout controls, select “Mobile & Lightning Actions”. You should see your new action listed there. Drag it into the “Salesforce Mobile and Lightning Experience Actions” section. (If your “Salesforce Mobile and Lightning Experience Actions” section doesn’t look like the above, you may need to click the little wrench icon to allow you to modify it.) Click Save.

    Click it!

  • integrate Salesforce with Google AdWords

    Introduction to Connect Salesforce to Google Ads :

    • Salesforce and Google Ads are two tools that are a staple of any marketer’s technology stack. 
    • Google Ads provides the world’s largest advertising platform, being able to reach anyone with an internet connection, and Salesforce is the world’s most popular CRM system to track your prospects and customers.
    • These two companies have created best in breed solutions, but if you are using both, you will know how hard it is to integrate the systems to produce the analytics you need. 
    • Without connecting the dots between your marketing and CRM data, you cannot fully optimize your campaigns. Let’s look into why this is important

    Why Connect Salesforce to Google Ads?

    • If you are using Salesforce & Google Ads, you will most likely be generating a portion of your leads through advertisements on Google.
    • This will flow through to your website where a customer will fill in a form, which, if properly integrated, should appear in your Leads object in Salesforce.
    • If you have this kind of setup, it’s already pretty slick, and you can effortlessly get customer inquiries for your product or service. 
    • But how do you understand which campaigns are the top performers? Which campaigns are bringing the most customers, and therefore where should you be spending your money? How do you see your ROI from Marketing spend?
    • These answers are impossible to answer without connecting your Salesforce Lead & Opportunity data, with Google Ads.

    Auto-Tagging :

    • Auto-tagging is a required feature, which when used with Google Ads conversion tracking, allows you to see how effectively your ad clicks lead to valuable customer activity, such as website purchases, phone calls, app downloads, and more.
    • Auto-tagging is turned off by default. To turn it on, follow the steps below.
    • Sign in to your Google Ads account.
    • In the left page menu, click Settings > Account Settings > Auto-tagging
    • Check the box “Tag the URL that people click through from my ad” and Save

    Steps to Integrate Salesforce to Google Ads Account:

    Step 1: Configure your Salesforce account

    • Create a custom field with the Name “GCLID”. Length should be 255 characters.
    • The field should be read-only so the users don’t accidentally alter it.
    • Field history tracking for the field “Stage” should be enabled.

  • How to use the Lookup field in Lightning DataTable?

    We all know that Salesforce standard Lightning DataTable is the best table that we can use to display the record and it also does support the in-line editing. There are some limitations of the Standard lightning datatable like we can not have a lookup field, Picklist field or event some file upload for every column. In this blog post, I will show you how you can create a custom data type to show lookup, picklist, or anything that you wanted to have.

    Step1 – Create a new Lightning Web Component

    In this step, we will create a lightning web component which will extend the LightningDatatable like below

    export default class ExtendedDataTable extends LightningDatatable { }

    Extending LightningDatatable will help us to create our own Lightning DataTable Data Type

    Step2 – Create a Custom DataType for Custom Lookup

    Now, as you have created the new component, in the js file of the same component create a custom datatype like below.
    In the above example, I have defined the data type for the picklist and custom lookup.

    Step3 – Create a new html file inside the Same Web Component

    Now, you need to create the .html file inside the same Web Component. here is the sample code which is using a search component which is actually used for custom Lookup
    You can get the complete code for the Search Component from here

    Step4 – Prepare the Custom Lookup Columns for DataTable

    Now, we need to create a new Lighting Web Component which will be using the component which we have created on the top.

    Once you have created the component, you need to prepare the columns for data table like below

    The above code contains the column for custom lookup using our new component & data type that we have created.

    Here is the code for Custom Picklist

    Here is the code for custom file upload

  • Single Sign On(SSO)

    Single sign-on (SSO) lets users access authorized network resources with one login. You validate usernames and passwords against your corporate user database or other client app rather than Salesforce managing separate passwords for each resource.

     There are 2 ways we can implement SSO in

    1) Delegated authentication

    Delegated authentication SSO integrates Salesforce with an authentication method that you choose. You can integrate authentication with your LDAP (Lightweight Directory Access Protocol) server or use a token instead of a password for authentication. You manage delegated authentication at the permission level, not at the org level, giving you more flexibility. With permissions, you can require some to use delegated authentication while others use their Salesforce-managed password.
    Delegated authentication offers the following benefits.

    Uses a stronger form of user authentication, such as integration with a secure identity provider

    Makes your login page private and accessible only behind a corporate firewall

    Differentiates your org from all other companies that use Salesforce to reduce phishing attacks

    2) Federated Authentication

    Federated authentication using Security Assertion Markup Language (SAML) lets you send authentication and authorization data between affiliated but unrelated web services. You can log in to Salesforce from a client app. Salesforce enables federated authentication for your org automatically.

    Configure SSO Across Multiple Salesforce Orgs

    Let your users log in across multiple Salesforce orgs using single sign-on (SSO) credentials. With SSO, you can validate user credentials against a corporate database or other app rather than managing separate passwords for each Salesforce org.

    Enterprises often deploy more than one Salesforce org. Unless you implement SSO, users that access different orgs must reauthenticate with each org. Removing this extra login step makes it more convenient for users and enhances security because it’s easier for users to maintain and use a single, strong password.

    SSO follows a hub-and-spoke architecture. At the center is a centralized authentication hub, the identity provider. The identity provider validates credentials and asserts the user’s identity to the spokes—Salesforce orgs that are the service providers. The org that is the identity provider generates SAML assertions that follow the SAML 2.0 standard for SSO.

    Benefits of SSO

    Implementing SSO brings several advantages to your org.

    • Reduced administrative costs—With SSO, users memorize a single password to access network resources and external apps and Salesforce. When accessing Salesforce from inside the corporate network, users log in seamlessly and aren’t prompted for a username or password. When accessing Salesforce from outside the corporate network, the users’ corporate network login works to log them in. With fewer passwords to manage, system admins receive fewer requests to reset forgotten passwords.
    • Leverage existing investment—Many companies use a central LDAP database to manage user identities. You can delegate Salesforce authentication to this system. Then when users are removed from the LDAP system, they can no longer access Salesforce. Users who leave the company automatically lose access to company data after their departure.
    • Time savings—On average, users take 5–20 seconds to log in to an online app. It can take longer if they mistype their username or password and are prompted to reenter them. With SSO in place, manually logging in to Salesforce is avoided. These saved seconds reduce frustration and add up to increased productivity.
    • Increased user adoption—Due to the convenience of not having to log in, users are more likely to use Salesforce regularly. For example, users can send email messages that contain links to information in Salesforce, such as records and reports. When the recipient of the email message clicks the links, the corresponding Salesforce page opens.
    • Increased security—All password policies that you’ve established for your corporate network are in effect for Salesforce. Sending an authentication credential that’s only valid for a single time also increases security for users who have access to sensitive data.

    Viewing Single Sign-On Login Errors

    If your organization is enabled for Single Sign-On using delegated authentication and has built a Single Sign-On solution, you can view the most recent Single Sign-On login errors for your organization.

    • 1.From Setup, enter Delegated Authentication Error History in the Quick Find box, then select Delegated Authentication Error History.
    • 2.For the twenty-one most recent login errors, you can view the user’s username, login time, and the error.

  • Platform Event

    Introduction to Platform Events in Salesforce :

    • Consider this, a platform event is just like another custom object but this would only be referred by external systems to communicate with Salesforce. 
    • To put this in a scenario when a certain system posts data on a Salesforce endpoint then that data should be fetched and the data in Salesforce should be updated. 
    • Of course, you can use too many lines of code to continuously fetch and retrieve the data from the endpoint or just wait for data to be posted based on which an event shall be triggered and the next processes shall follow. 
    • Now, this is where platform events come into the picture, instead of writing lines and lines of codes and continuously requesting and checking if the data is posted we can just have a platform event trigger notify us and then have your logic do the rest of the heavy lifting.

    What are Platform Events in Salesforce?

    • Platform Event is based on Event-Driven Architecture which enables apps to communicate inside and outside of Salesforce. 
    • Platform events are based on the publish/subscribe model and work directly with a message bus which handles the queue of incoming events and processes listening for them. 
    • This is built in real time integration patterns in the Salesforce Platform which helps to reduce point-to-point integration.

    Here Are The Following Points We Should Remember :

    • Event: An adjustment in the expression that is important in a business procedure. 
    • Event Message/Notification: A message that contains information about the Event. 
    • Event Maker: The distributer of an occasion message over a channel. 
    • Channel: A conductor where an occasion maker sends a message. Event shoppers buy into the channel to get messages. Likewise alluded to as Event transport in Salesforce. 
    • Event Consumer: A supporter of a channel that gets messages from the channel.

    Publishing and subscribing Platform events :

    • Publishing and subscribing to the platform event are more flexible. 
    • You can publish event messages from a app or an external app using Apex or Salesforce APIs and you can subscribe from the Salesforce or external apps or use long polling with cometD as well.

    Define Platform Event :

    Define platform events similar like a custom object, go to setup –> develope –> Platform events –> create new platform events as shown below.

    Publish Platform events

    Publish Using Apex :

    • A trigger processes platform event notification sequentially in the order they’re received and trigger runs in its own process asynchronously and isn’t part of the transaction that published the event. 
    • Salesforce has a special class to publish the platform events EventBus which is having methods publish method. once the event is published you can consume the events from the channel.

    trigger PlatformEventPublish on Account (after insert , after update ) {

        If(trigger.isAfter && trigger.isUpdate){

            List<Employee_On_boarding__e> publishEvents = new List<Employee_On_boarding__e>();

            for(Account a :{

                Employee_On_boarding__e eve = new Employee_On_boarding__e();

                eve.Name__c = a.Name ;

                eve.Phone__c = a.Phone ;

                eve.Salary__c = a.AnnualRevenue ;








    Publish Using Process Builder :

    Publish Events by Flow :

    • Run/Debug Flow:1(platform Event producer) and you will send post in chatter.


    Subscribe for Platform events :

    • We can subscribe to the platform events from the Platform events object trigger which is created. 
    • Here is the sample trigger show how you can handle the subscribed events. create new accounts from the platform event but you can implement your own business logic to update the data.

    trigger OnBoardingTrigger on Employee_On_boarding__e (after insert) {

        List<Account> acc = new List<Account>();

        for(Employee_On_boarding__e oBording{

            acc.add(new Account(Name =oBording.Name__c , Phone =oBording.Phone__c , AnnualRevenue = oBording.Salary__c));


        if(acc.size() >0){

            insert acc ;



    • you can consume the platform events by using this  URI /event/Employee_On_boarding__e and the Complete code is here below

    <apex:page standardStylesheets=”false” showHeader=”false” sidebar=”false”>

        <div id=”content”> 


        <apex:includeScript value=”{!$Resource.cometd}”/>

        <apex:includeScript value=”{!$Resource.jquery}”/>

        <apex:includeScript value=”{!$Resource.json2}”/>

        <apex:includeScript value=”{!$Resource.jquery_cometd}”/>

        <script type=”text/javascript”>


            $(document).ready(function() {


                    url: window.location.protocol+’//’+window.location.hostname+ (null != window.location.port ? (‘:’+window.location.port) : ”) +’/cometd/40.0/’,

                    requestHeaders: { Authorization: ‘OAuth {!$Api.Session_ID}’}



                $.cometd.addListener(‘/meta/handshake’, function(message) {

                    $.cometd.subscribe(‘/event/Employee_On_boarding__e’, function(message) {

                        var div = document.getElementById(‘content’);

                                        div.innerHTML = div.innerHTML + ‘<p>Notification </p><br/>’ +

                            ‘Streaming Message ‘ + JSON.stringify(message) + ‘</p><br>’;








    Advantages of Salesforce Platform Events :

    • Clients can run organizations quicker on an event-driven architecture.
    • Make an entire 360-degree client experience – continuous reconciliation with any business cycle.
    • Event-driven work processes to enlarge information.
    • Can catch and follow up on a great many streaming events.

Post A Comment