Salesforce Facts by Abhishek

Suppose we have a use case where we need to ensure new leads in the system who are having Rating as 'Hot' are getting contacted within two days of creation date. Now, we can have a report extract or list views with filters to get the leads. But what if we can notify the sales reps right in the record detail page. Yes, we can create an LWC to show a toast message asking the reps to follow up with the leads for next steps. We can also put component visibility on the component so that it is applicable only to the corresponding records. Attached are the screenshots.

We know that flow screen elements labels can be used as expressions i.e. dynamic values. This is very helpful and gives the option to use custom labels to show input labels in the local language of the user. In this example, we have a date input field which we are using to collect the date of birth of the user. For the input field label we are using custom label to show localized text message. Attached are the screenshots.

We know that SOQL on custom metadata and also using the built-in functions like getAll(), getInstance() do not count towards the SOQL query count. But do you know this is not the case while using Get Records in Flow. While using Get Records on Custom Metadata in flow counts towards the 100 SOQL limit and shows error if that limit is reached. So, we need to be very careful while fetching custom metadata in flow. Attached are the screenshots. Note: The above construct is only for demonstration purpose. Please do not use SOQL or Get Records inside loop as it is not a good practice.

Do you know we have two datetime functions: NOW() & TIMENOW(). NOW() returns the specific time including the date and also considering the time zone for the current user whereas TIMENOW() returns only time value and that also in GMT. For more details, please check: https://developer.salesforce.com/docs/atlas.en-us.formula_date_time_tipsheet.meta/formula_date_time_tipsheet/formula_using_date_datetime.htm Attached is an example screenshot.  

We know that if we have a record-triggered flow and it runs on record is created or edited and on before save, then we can add the condition Id ISNULL TRUE in the entry criteria to simulate the ISNEW() condition check. But do you know in case of after save flow i.e. on action and related records option, you can add a condition to check ISCHANGED() on any of the audit fields i.e. CreatedById, CreatedDate, LastModifiedDate, LastModifiedById to check for the created scenario. Credits: My project team

We know that we can use trigger.new or trigger.old directly in SOQL when we are filtering based on recordId field. For example like below: List<Account> accountList = [SELECT Name FROM Account WHERE Id IN :trigger.new]; Do you know you can use the same in other similar scenarios as well. This is quite efficient as it does not require a collection to store the Id and also avoids the iteration. In this example, we need to find out the contact record details which are associated to accounts. Attached are the screenshots.    

Do you know there is a USING SCOPE clause in SOQL which utilizes some filterscopes to return records accordingly. For example, To see the recently viewed Account records we can use MRU as filterscope like this: SELECT ID,Name FROM Account USING SCOPE MRU Similary, To see My Accounts we can use MINE as filterscope like this: SELECT ID,Name FROM Account USING SCOPE MINE For more details, please check  https://developer.salesforce.com/docs/atlas.en-us.236.0.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_using_scope.htm

Let's see what are the possible contexts on how we can launch a screen flow or autolaunched flow. So there are 3 options available: 1) User or System Context-Depends on How Flow is launched 2) System Context with Sharing-Enforces Record-Level Access 3) System Context Without Sharing-Access All Data Now, suppose we have a main flow and a subflow with the context set for each of them. In this example, we have a main flow which is invoking an auto-launched flow which is fetching the account records. In the main flow, finally we are showing the count of fetched records.                                                Main flow  Sub flow Let's see what are the possible scenarios. When the main flow context is  System Context Without Sharing-Access All Data and subflow context is  User or System Context-Depends on How Flow is launched, then the auto-launched flow takes the context of main flow and can access all the records. When the main flow context is System Context Without Sharing

Suppose we have a use case in LWC where we have two datatables. Now, whenever a row is selected from datatable1 it should get added to datatable2 and at the same time should get removed from datatable1. We can implement this by using some JS logic on onrowselection event. Attached are the screenshots. Code Snippets: Output:

Do you know translation works perfectly for picklist choice set in screen flow. Suppose, you have set the translated values for a picklist field values using the translation workbench. The translated values would appear based on the language of the logged in user. In this example, we have set the translation for few of the values of the Type picklist in Account in German language using translation workbench and used these values as part of picklist choice set in screen flow. Attached are the screenshots.

Not able to see the Products related list on Opportunity record page? Check whether the user has access to Pricebook object. Do you know you need at least Read access to Pricebook object in order to add Opportunity Products.

We should not use audit fields of the current record in lookup filter criteria. Since, the audit fields are populated once the record is created, using them in lookup filters will cause issues during creation of the record. As the record is not created yet, the filter won't be able to fetch any data. In this example, we want to put a filter that the users can select the account records which are created by them i.e. the created by Id of account and contact record would be same. Although this filter would work for existing records, it won't get any data during creation of a new contact. Attached is the screenshot.

Suppose we have a use case where we need to restrict the records in the lookup for a particular profile. However, for rest of the users there should not be any restriction. Now, if we only include the condition for that particular profile then the search would get impacted for the other users as well. Therefore, we need to include the opposite filter as well. In this example, we want that the users of the John & Team profile will get access to only those account records which are owned by them. However, there should not be any filter for other users. Hence, we have added the opposite filter as well and customized the filter. Attached is the screenshot.

It is a good practice to not use hardcoded Ids anywhere in Salesforce. But in case we have some use case where we need to use hardcoded Ids in validation rule, then we need to be careful.  If we are specifying the 18 char Id, then we need to use CASESAFEID function in order to make the comparison at the same level. However, it is not required if we are specifying 15 char Id. Attached is the screenshot.