Monthly Archives

  • 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 Force.com

    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.