DEV Community: Oleksandra Todorenko

Salesforce Flow deactivation using Metadata API

Oleksandra Todorenko — Wed, 31 Jan 2024 20:10:45 +0000

Salesforce Flow is a powerful tool, offering declarative solutions for various business processes within the Salesforce ecosystem. While creating and updating flows is straightforward, deactivating an active flow presents its own set of challenges.

Typically, one might assume that updating the <status> tag in the flow XML file to a value indicating "Inactive" would deactivate the flow.
According to the documentation, there are four possible status values:

Active
Draft—In the UI, this status appears as Inactive.
Obsolete—In the UI, this status appears as Inactive.
InvalidDraft—In the UI, this status appears as Draft.

However, using any of these values in the flow-meta.xml file and deploying it to the org will not deactivate the flow.

Let’s see the resolution of this tricky task of Salesforce Flow deactivation in the following example:

I created a pretty simple flow that just makes a Chatter post on the Account record page when Billing Country is updated.

As you can see, this flow is active.

Retrieving this active flow from the org to the codebase reveals its XML structure. Here's a snippet:

<?xml version="1.0" encoding="UTF-8"?>
<Flow xmlns="http://soap.sforce.com/2006/04/metadata">
   <actionCalls>
       <name>Post_Update_To_Chatter</name>
       <label>Post Update To Chatter</label>
       <locationX>50</locationX>
       <locationY>431</locationY>
       <actionName>chatterPost</actionName>
       <actionType>chatterPost</actionType>
       <flowTransactionModel>CurrentTransaction</flowTransactionModel>
       <inputParameters>
           <name>text</name>
           <value>
               <elementReference>ChatterMessageCountryChanged</elementReference>
           </value>
       </inputParameters>
       <inputParameters>
           <name>subjectNameOrId</name>
           <value>
               <elementReference>$Record.Id</elementReference>
           </value>
       </inputParameters>
       <storeOutputAutomatically>true</storeOutputAutomatically>
   </actionCalls>
   <apiVersion>59.0</apiVersion>
   <decisions>
       <name>CountryWasChanged</name>
       <label>Country Was Changed</label>
       <locationX>182</locationX>
       <locationY>323</locationY>
       <defaultConnectorLabel>Default Outcome</defaultConnectorLabel>
       <rules>
           <name>PostToChatter</name>
           <conditionLogic>and</conditionLogic>
           <conditions>
               <leftValueReference>$Record.BillingCountry</leftValueReference>
               <operator>NotEqualTo</operator>
               <rightValue>
                   <elementReference>$Record__Prior.BillingCountry</elementReference>
               </rightValue>
           </conditions>
           <conditions>
               <leftValueReference>$Record.BillingCountry</leftValueReference>
               <operator>IsNull</operator>
               <rightValue>
                   <booleanValue>false</booleanValue>
               </rightValue>
           </conditions>
           <connector>
               <targetReference>Post_Update_To_Chatter</targetReference>
           </connector>
           <label>Post To Chatter</label>
       </rules>
   </decisions>
   <environments>Default</environments>
   <interviewLabel>Account Country Update Post To Chatter {!$Flow.CurrentDateTime}</interviewLabel>
   <label>Account Country Update Post To Chatter</label>
   <processMetadataValues>
       <name>BuilderType</name>
       <value>
           <stringValue>LightningFlowBuilder</stringValue>
       </value>
   </processMetadataValues>
   <processMetadataValues>
       <name>CanvasMode</name>
       <value>
           <stringValue>AUTO_LAYOUT_CANVAS</stringValue>
       </value>
   </processMetadataValues>
   <processMetadataValues>
       <name>OriginBuilderType</name>
       <value>
           <stringValue>LightningFlowBuilder</stringValue>
       </value>
   </processMetadataValues>
   <processType>AutoLaunchedFlow</processType>
   <start>
       <locationX>56</locationX>
       <locationY>0</locationY>
       <connector>
           <targetReference>CountryWasChanged</targetReference>
       </connector>
       <object>Account</object>
       <recordTriggerType>Update</recordTriggerType>
       <triggerType>RecordAfterSave</triggerType>
   </start>
   <status>Active</status>
   <textTemplates>
       <name>ChatterMessageCountryChanged</name>
       <isViewedAsPlainText>true</isViewedAsPlainText>
       <text>Attention! The Billing Country on this Account was changed from {!$Record__Prior.BillingCountry} to {!$Record.BillingCountry}</text>
   </textTemplates>
</Flow>

Regardless of the status specified in the <status> tag during deployment, the flow remains active.

To resolve this, you need to retrieve the .flowDefinition-meta.xml file associated with the flow. Within this file, set the <activeVersionNumber> to 0.

An example of how these files are structured in my project:

Here's how the file structure appears after retrieval:

<?xml version="1.0" encoding="UTF-8"?>
<FlowDefinition xmlns="http://soap.sforce.com/2006/04/metadata">
   <activeVersionNumber>2</activeVersionNumber>
</FlowDefinition>

And here's the adjustment to deactivate the flow before deployment:

<?xml version="1.0" encoding="UTF-8"?>
<FlowDefinition xmlns="http://soap.sforce.com/2006/04/metadata">
   <activeVersionNumber>0</activeVersionNumber>
</FlowDefinition>

Once deployed, the flow is successfully deactivated.

This simple yet effective approach offers a solution to the challenge of deactivating Salesforce Flows programmatically. Share your insights and alternative methods for flow deactivation in the comments below, and let's enrich our knowledge together!

Mass Profile Update in Salesforce. A Quick Step-by-Step Guide

Oleksandra Todorenko — Thu, 30 Nov 2023 21:50:38 +0000

Managing profiles and permissions efficiently is a must for Salesforce developers to keep accesses up-to-date and prevent data leakage. If in your Salesforce organization most of the permissions are set in profiles, not permission sets, you may face the task of updating many profiles for some specific permission. And the more profiles you need to update, the more time it will take. Mass-updating profiles saves significant time and ensures consistent configurations across multiple profiles. It’s an efficient way to bulkify and optimize your work within the scope of standard Salesforce functionality.
Now, let's dive into the steps:

Navigate to the Profiles Page

Begin by logging into your Salesforce organization and accessing the Setup menu. In the Quick Find box, type "Profiles" and select the "Profiles" option.

Create a Targeted List View

To be able to update several profiles at the same time, we need to create a profile list view.

This view can be filtered based on profile properties, such as displaying only custom profiles. If you are creating a list view only for mass profile updates, I suggest filtering profiles to display only custom ones - only custom profiles can be edited.

Also, add all the fields that you need to mass update. In my example, it will be a field for Opportunity deletion and Contact deletion. Then save this list view.

Select list view and profiles for editing

Select your list view from the dropdown.
Then select all the profiles for which you want to mass update the permission.
Also, you can choose all the profiles by selecting the first checkbox.

Double-Click the Permission to Edit

Double-click on the permission you want to modify. Whether you're editing one or multiple profiles, this action opens a convenient dialog box for quick adjustments.

Modify Permissions in the Dialog Box

Within the dialog box, enable or disable the permission as needed.

Handle Cascading Changes

Pay attention to the cascading changes that may affect other permissions. The dialog box will highlight any affected permissions, ensuring you're aware of the broader impact.

Save Changes

To apply changes across multiple profiles, select "All n selected records" (where n is the number of profiles you've chosen). Complete the process by clicking the "Save" button.

By following this guide, you can seamlessly update permissions across multiple profiles.

Remember, utilizing list views with targeted filters and displayed fields enhances your profile management capabilities, allowing you to complete your tasks faster. Happy optimizing!

8 Tips for Pixel-Perfect Email Templates in Salesforce

Oleksandra Todorenko — Tue, 01 Aug 2023 12:38:01 +0000

Creating Lightning Email Templates in Salesforce is essential for Sales Managers and Marketing professionals to streamline communication and maintain consistent branding. Ensuring that recipients receive emails with the expected style and appearance is crucial for a seamless and professional experience. Let's explore the best practices to achieve this goal and deliver effective email communication to our audience.

Validate in different Mail clients

Once you've prepared a template in Salesforce and tested it in Gmail, take a moment before saving it as the final version. Some mail clients may not support all CSS properties, leading to unexpected appearances for recipients. Notably, the Outlook app for Windows lacks support for numerous HTML elements and CSS properties, such as max-width, border-radius, styles on p, div elements, etc.
Also, there are platforms where you can validate the appearance of your email in different versions, platforms and devices, just by inserting its HTML template. Unfortunately, I found only paid solutions (Litmus, Email on Acid). Please share in the comments if you can recommend other platforms, especially free ones :)

Use Email Template Builder

Salesforce's Email Template Builder allows easy creation of email templates with a drag-and-drop functionality. To enable this feature, users need Access Drag-and-Drop Content Builder permission. Once granted, they can click the 'Edit in Builder' button to get started.

Despite some limitations, the Email Template Builder allows the insertion of HTML code, images, text areas, and columns, making it a handy solution for quick email template building.

Table structure

To ensure your email's appearance aligns with your expectations, it's recommended to structure emails using tables. Although this approach involves more complex code than using div elements, it guarantees compatibility across all mail clients. Make sure to apply all styles at the <td> level, as styles set elsewhere may not be supported in some browsers and mail clients.

Duplicate style properties

Certain CSS properties, like align, vertical-align, width, height, etc., should be defined twice. Include them in the CSS style for most mail clients and separately on the <td> element for mail clients like Outlook.

For example:

<td style="width:150px; height: 100%; vertical-align: middle" width="150" height="100%" valign="middle">

Note that for properties with px values, we write only the number (e.g., width="150"). For percent values, we add a percent sign.

Use only supported properties

Keep in mind that even popular mail clients may have limited or no support for certain HTML or CSS properties. Be cautious when using elements and properties, ensuring they are supported in your recipients' mail clients. You can check each property's support for the most popular email clients on the CanIEmail website.

For example, the border-radius property that creates rounded corners on buttons:

Avoid VML in your templates

While creating adaptive email templates, you might come across VML (Vector Markup Language), a code format used to create graphics and visual elements, which allows adding interactive elements and custom background images to make email campaigns more engaging. However, it's important to note that VML is not supported in Salesforce email templates. If you attempt to use VML, it will be deleted when you save the email template. Therefore, it's best to avoid VML and explore alternative solutions to achieve your desired design and interactivity.

Simplify editing with a developer console

While making style adjustments in Salesforce's email templates, you can switch views by clicking the Source button to see the HTML code.

However, to view applied style changes in real-time, use the built-in browser's Developer Console. Any changes made there will be applied to the email template when saving and won't be overwritten by styles set in the Source tab.

Disable text editing extensions

If you use text editing extensions in your browser, such as Grammarly or QuillBot, be mindful that they may add elements or logos to your email template automatically. In Salesforce these elements can be saved as a part of your email template and your recipients will receive them by mistake. Ensure that the final version of your email template doesn't include any extra symbols, images, or unexpected elements.

Summary

To sum up, Salesforce allows an extensive functionality in using and creating email templates. Just sometimes you need to know its limitations and features to be like a Pro.
Have some valuable insights or nifty tricks for working with Salesforce Email Templates? Drop them in the comments below, and let's exchange our knowledge!

If you've found this article informative and useful, I'd love to connect with you on LinkedIn. Building a network of like-minded Salesforce enthusiasts is always exciting. Feel free to reach out with any questions or feedback about the article. I'm here to engage in a conversation and provide further assistance. Let's connect and continue learning and growing together in the Salesforce community!

Resolving UnitPrice Recalculation for OpportunityLineItem Update

Oleksandra Todorenko — Tue, 06 Jun 2023 07:38:11 +0000

In Salesforce, the Opportunity Product standard object (OpportunityLineItem) serves as the foundation for many functionalities. While custom objects and fields generally exhibit consistent behavior, standard objects can have more complex logic with additional dependencies and limitations.

Recently, I encountered an unusual behavior related to the OpportunityLineItem's UnitPrice field recalculation. This recalculation occurs when a record is updated indirectly, outside of the Salesforce Lightning or Classic record pages. It may happen through updates made via Apex, Automation Tools, or Extensions (such as Salesforce Inspector or similar tools).

The behavior specifically revolves around the Quantity and UnitPrice fields, and how the UnitPrice is recalculated when the Quantity is modified without explicitly querying the UnitPrice field. In this article, I will share my observations of this behavior and provide a workaround to ensure accurate updates while preserving the original UnitPrice value.

Example

Let's examine a scenario to better understand this behavior:

Consider an Opportunity Product record with the following initial data:

Sales Price (API name UnitPrice): 100,000 EUR
Total Price: 100,000 EUR
Quantity: 1

We will perform updates on the Quantity field, setting it to a value of '2', and observe the outcomes in different scenarios.

Update from the Lightning Record Page

In this case, the behavior is as expected. The Quantity is updated to '2', the Sales Price remains unchanged, and the Total Price becomes 200,000 EUR, which is logically consistent.

Update from Apex

Let's update this record using Anonymous Apex with the following code snippet:

OpportunityLineItem oli = [SELECT Id, Quantity FROM OpportunityLineItem WHERE Id = '00k6800000c3THrAAM']; //Id of selected OLi
oli.Quantity = 2;
update oli;

In this scenario, we observe that the Total Price remains the same, but the Sales Price becomes two times smaller, like following the formula Total Price/Quantity.

Why UnitPrice gets recalculated

Upon investigating this unusual behavior, I discovered that these fields are interdependent based on the following formula:
TotalPrice = (UnitPrice * Quantity) * Discount

When only the Quantity field is updated without querying the UnitPrice field, the system recalculates the UnitPrice as TotalPrice divided by (Quantity * Discount).

Workaround

To overcome this unexpected UnitPrice recalculation, I found a workaround that involves explicitly querying the UnitPrice field. By doing so, we can retain the original UnitPrice value while updating the Quantity accurately.

Here's an example implementation, along with a video demonstration:

OpportunityLineItem oli = [SELECT Id, UnitPrice, Quantity FROM OpportunityLineItem WHERE Id = '00k6800000c3THrAAM'];
oli.Quantity = 2;
update oli;

As you can see, even without directly updating the UnitPrice field, just by adding it to the query, we achieve the expected behavior and avoid unnecessary recalculations.

If you have any alternative workarounds in mind or are aware of other action sequences where field recalculation may occur, please feel free to share them in the comments section. Your insights and contributions are greatly appreciated!

Make Salesforce Emailing Effortless: Customize SendEmail Action in 3 Simple Steps

Oleksandra Todorenko — Thu, 13 Apr 2023 08:58:22 +0000

If you want to streamline your email communication with customers and colleagues in Salesforce, you may consider overriding the standard SendEmail action with predefining certain fields, such as To, CC, BCC, subject, body, email template and others. Especially, it would be a great time saver if Salesforce users are still doing it by themselves every time when Email should be sent.

By doing this, we can save time, increase productivity, ensure accuracy, maintain compliance, and personalize communication. A great benefit is this can be done without any coding, making it a simple, quick and accessible solution for Salesforce Admins who want to optimize their workflow.

When and why you should think about overriding

There are several main cases where overriding the standard SendEmail action with a custom action that predefines certain fields can be useful for Salesforce Admins:

Consistency and accuracy: By predefining fields like the recipient, subject, and body, you can ensure that all emails sent from Salesforce are consistent and accurate. This can help to maintain a professional image and avoid errors or misunderstandings.

Efficiency and productivity: Predefining fields in a custom SendEmail action can save time and increase productivity, as users don't have to manually enter all the details each time they send an email. This can be particularly useful for sales teams or customer service representatives who need to send multiple emails per day.

Compliance and governance: In some industries or organizations, there may be strict regulations or policies around email communication. By predefining fields in a custom SendEmail action, you can ensure that all emails sent from Salesforce comply with these regulations and policies.

Customization and personalization: By predefining fields like the email template or the CC recipients, you can customize and personalize your emails to better suit your audience. This can help to build stronger relationships with customers and colleagues.

A step-by-step guide to Override Standard SendEmail Action

Unfortunately, the standard Salesforce SendEmail action is not editable, which means that we cannot set field values exactly as we want in the standard action.
However, we can create a custom action that will replace the standard one and allow us to predefine certain fields. Here are 3 simple steps to achieve it:

Step 1: Create a Custom Action

Go to the Object Manager and select the object for which you want to create the custom SendEmail action. In this example, we'll use the Opportunity object.

Click on the "Buttons, Links, and Actions" tab and then click "New Action". Select "Send Email" as the action type and enter a label and name for your custom action.

Step 2: Set predefined fields

Under Action Details, you can define the predefined fields for your custom SendEmail action.

Example of fields that I created you may see here:

Here is a list of fields that can be predefined, with their API names and short description:

BCC (BccAddress): email addresses that will be BCC'd on the email (hidden from other recipients)
BCC Recipients (BccIds): the User or Lead/Contact who will be BCC'd on the email
CC (CcAddress): the email address that will be CC'd on the email
CC Recipients (CcIds): the User or Lead/Contact who will be CC'd on the email
Email Template (EmailTemplate): the email template that will be used for the email content
External Id (ExternalId): an optional external ID field that can be used for integration purposes
From (ValidatedFromAddress): the email address that the email will appear to be sent from. This must be a verified email address in your organisation.
Html Body (HtmlBody): the HTML version of the email content
In Reply To (InReplyTo): the Message-ID of the email being replied to. This is used to thread email conversations.
Message Id (MessageId): the Message-ID of the email. This is used to thread email conversations.
Primary Who (Who): the primary Lead/Contact/User that the email is being sent to
References (References): the Message-ID of the email being replied to and other Message-IDs in the conversation. This is used to thread email conversations.
Related To (RelatedTo): the record that the email is related to. This is typically used when sending emails related to a specific record in Salesforce.
Subject (Subject): the subject line of the email
Text Body (TextBody): the plain text version of the email content
To (ToAddress): the email address that the email will be sent to
To Recipients (ToIds): the User or Lead/Contact who will receive the email

Step 3: Replace Quick Action on the layout

Once you have defined your CustomEmail action, you need to add it to the Object’s page layout. Go to the page layout editor for the desired object, in my case it’s Opportunity, select the "Mobile & Lightning Actions" section, and drag your custom SendEmail action to the section.

You need also to remove the standard SendEmail action from the section.

It is necessary as then exactly custom SendEmail action will be launched when clicking on the Email activity button. All the others SendEmail actions will be accessible by clicking the arrow from the right side.

Result

And that’s it! The predefined fields you defined in Step 2 should now be populated with the values you specified, allowing you to quickly and easily send an email without having to manually enter all the details.

Let's compare standard and custom SendEmail actions:
Standard:

Custom:

Standard Salesforce SendEmail action cannot be customized, but don't let that limit your ability to streamline your email communication processes. By creating a custom Send Email action and predefining fields, you can save your users time and effort. This is especially useful if you frequently send emails to a specific group of people, or if you want to ensure that certain fields are always filled out correctly.

Whether you're a Salesforce admin or a developer, this customization can be a great way to enhance your organization's productivity and make your users' lives easier.

If you have any questions or comments, please don't hesitate to reach out here or in LinkedIn – I'm always happy to connect with fellow Salesforce enthusiasts!

Subscribing to Salesforce Platform Events in Workbench: A Step-by-Step Guide

Oleksandra Todorenko — Sat, 28 Jan 2023 18:44:31 +0000

Salesforce platform events are a powerful tool for real-time data processing within the Salesforce ecosystem. Using platform events, you can easily transfer data of different types (with customizable fields) using a publish-subscribe model, where a sender (publisher) sends an event and one or more receivers (subscribers) receive the event.
Unlike sObjects, platform events can’t be queried using SOQL or SOSL, that is why we can use Workbench to subscribe to the specific Platform Event and track its validity.

In this article, we’ll discuss how to create platform events, their specifics and will subscribe to one of them using Workbench to see what data is received.

Table of Content

Creating platform event
Publishing platform event
Subscribing to the platform event using Workbench
Demo
Summary
Let's connect!

Creating platform event

To demonstrate how platform events work, let’s create an event that will be published when the Contact record changes (in the trigger) to let subscribers know that the contact has changed his job (Title or Department fields are changed).
To create a platform event, go to Setup -> Platform Events -> New Platform Event.

Here is an example of a created platform event. Please pay attention to the fields - we can add custom fields of different data types (Checkbox, Date, Date/Time, Number, Text, Text Area Long).
In our case, we need the following custom fields: Contact Company (AccountId), ContactId, Contact Name, Department and Job Title. These fields will be filled in the Contact Trigger.

Note: don’t forget to provide the required permissions to the users who will publish and subscribe to the events. It can be done by adding an object assignment to the custom profile or to the permission set that will be assigned to the specific users.

Publishing platform event

Platform events can be published from different places, such as:

Flow
Process Builder
Apex
External apps using API

Today we are going to consider the third option - publishing a platform event from Apex.
As we need to publish an event when the contact record has been updated with the new Title or Department, let’s create an Apex trigger on the Contact object. Below is the code of this trigger with the comments.

trigger ContactTrigger on Contact (before update) {
    // Create a static set to store the Contact Ids that have been modified
    private static Set<Id> contactIds = new Set<Id>();
    // Create a list to store the platform events
    List<ContactJobChange__e> events = new List<ContactJobChange__e>();

    if (Trigger.isBefore && Trigger.isUpdate) {
        // Iterate through the list of updated contacts
        for (Contact c : Trigger.new) {
            // Check if the Contact Id is already in the set
            if (!contactIds.contains(c.Id)) {
                // Check if the Title or Department fields have been modified
                if (c.Title != Trigger.oldMap.get(c.Id).Title ||
                    c.Department != Trigger.oldMap.get(c.Id).Department) {
                    // Add the Contact Id to the set
                    contactIds.add(c.Id);
                    // Create a new platform event
                    ContactJobChange__e event = new ContactJobChange__e();
                    event.ContactId__c = c.Id;
                    event.ContactCompany__c = c.AccountId;
                    event.ContactName__c = c.FirstName + ' ' + c.LastName;
                    event.Department__c = c.Department;
                    event.JobTitle__c = c.Title;
                    // Add the platform event to the list
                    events.add(event);
                }
            }
        }
        EventBus.publish(events);
    }
}

Please note: according to the best practices, it is preferable to keep trigger logic in the separate handler class. This example is simplified for understanding and contains the business logic inside the trigger.

Subscribing to the platform event using Workbench

When the trigger logic is done, we can proceed to the subscription to the platform event.
To do this, go to Workbench and log in using Salesforce.
Navigate to queries -> Streaming Push Topics. Then select the "Generic Subscriptions" tab and in the "Subscription" field enter the name of your platform event in the following format:
/event/EventName__e. If you are using an event with a namespace, the format will be the following: /Namespace__event/EventName__e.
For the ContactJobChange event, I have the following value: /event/ContactJobChange__e.

If everything is set correctly, after filling in all the fields and pressing the "Subscribe" button, you will receive the message that confirms a successful subscription:

Everything is ready to see how our events work!

Demo

Below is a detailed demonstration of how our contact has been updated and event message was received in a real-time:

You may take a look at the received message with the updated JobTitle__c on the following screenshot:

All fields are also filled as expected.

Summary

In this article, we discussed the concept of platform events in Salesforce and how they can be used to track changes in business processes. We also covered how to subscribe to platform events using the Salesforce Workbench tool. We provided step-by-step instructions on how to create a platform event, subscribe to it, and view its data in Workbench. By following these steps, you can easily subscribe to platform events in Workbench, taking full advantage of the real-time data processing capabilities of Salesforce.

Lets connect!

If you found this article informative and useful, I would love to connect with you on LinkedIn. I am always happy to expand my network and connect with individuals who share a passion for Salesforce. Feel free to reach out to me with any questions or feedback regarding the article, I am more than happy to engage in a conversation and provide further assistance. So don't hesitate to connect with me and let's learn and grow together in the Salesforce community!

LWC getRecords wire adapter: how to retrieve records dynamically

Oleksandra Todorenko — Fri, 02 Dec 2022 11:34:18 +0000

In this article, I would like to share use cases, syntax, workarounds and features of using the getRecords wire adapter in the Lightning Web Components (LWC) framework in Salesforce.

Ways to retrieve record data in LWC

Development by using the LWC often includes some kind of operations with records in the database: creating, retrieving, updating, and deleting.

There are different ways to retrieve information about the record by its Id while working with LWC.
The simplest and the most limited is by using Lightning Base Components such as “lightning-record-form” or “lightning-record-view-form”. You can retrieve field labels and values for the specific record id and that’s it. The most customizable way is, as always, calling custom Apex. You can retrieve all the needed record details. However, every call to the backend takes more time than operations on the client-side and Apex methods should be called imperatively.
In case you have ids of records (even of different objects!) and want to retrieve their field values (translated and original ones), record type, or last modified details, I recommend using the @wire getRecord or getRecords adapter.

`getRecord` vs `getRecords` comparison

These two wire adapters are very similar - both of them belong to 'lightning/uiRecordApi', and accept record id(s) and fields to retrieve parameters.
The only thing is that getRecords operates over an array of record ids instead of only one id. For sure, it can accept an array that contains only one id.
Also, getRecords returns a collection of batch result records - each record for each provided id.
If you are unaware of how many record ids should be processed or if you expect more than one id, consider using the getRecords adapter.

Syntax

import { LightningElement, wire } from 'lwc';
import { getRecords } from 'lightning/uiRecordApi';

@wire(getRecords, { records: [ { recordIds: string[], fields: string[] } ] })
propertyOrFunction

@wire(getRecords, { records: [ { recordIds: string[], fields: string[], optionalFields?: string[] } ] })
propertyOrFunction

More details you may find in the official documentation.

Please note: usage of fields or optionalFields parameter is mandatory. The difference is that while using fields and the context user doesn’t have access to this field, an error occurs. If the user hasn’t access to the field from the optionalFields parameter - it doesn’t cause an error, just this field won’t be returned. Think about which approach is more convenient in your case and don’t forget that you can use both parameters at the same time.

How to retrieve records for dynamic record Ids

There are various examples of retrieving record data using getRecords for predefined ids for one or for several different objects. Please take a look at the examples from the Salesforce documentation.

For one object:

import { LightningElement, wire } from 'lwc';
import { getRecords } from 'lightning/uiRecordApi';
import NAME_FIELD from '@salesforce/schema/User.Name';
import EMAIL_FIELD from '@salesforce/schema/User.Email';

export default class GetRecordsExample extends LightningElement {
    @wire(getRecords, {
        records: [
            {
              recordIds: ['005XXXXXXXXXXXXXXX', '005XXXXXXXXXXXXXXX'],
              fields: [NAME_FIELD],
              optionalFields: [EMAIL_FIELD]
            }
        ]
    }) wiredRecords;
}

For multiple objects:

import { LightningElement, wire } from 'lwc';
import { getRecords } from 'lightning/uiRecordApi';
import USER_NAME_FIELD from '@salesforce/schema/User.Name';
import USER_EMAIL_FIELD from '@salesforce/schema/User.Email';
import ACCOUNT_NAME_FIELD from '@salesforce/schema/Account.Name';

export default class GetRecordsExample extends LightningElement {
    @wire(getRecords, {
        records: [
            {
              recordIds: ['005XXXXXXXXXXXXXXX'],
              fields: [USER_NAME_FIELD],
              optionalFields: [USER_EMAIL_FIELD]
            },
            {
              recordIds: ['001XXXXXXXXXXXXXXX'],
              fields: [ACCOUNT_NAME_FIELD]
            },
        ]
    }) wiredRecords;
}

As for now, the main difficulty is the inability (almost) to retrieve records when there are no predefined ids and objects. They are set only statically and there’s no way to write them down dynamically in the array of objects.

In such an unusual case I recommend creating an array parameterObject that will include all record parameters as a single property.
This object can be created in the scope of connectedCallback, renderedCallback, or at the level of the parent component that calls the current one.
The format will look something like this:

this.recordIds.forEach(recordId =>{
   this.parameterObject.push({
       recordIds: [recordId],
       optionalFields: this.fieldsToRetrieve
   })
});

This is the structure that will retrieve records dynamically for different objects when there’s no prepared structure of parameterObject with predefined Ids. Let’s consider an example of using the getRecords adapter when records should be retrieved dynamically.

Example of using `getRecords` for dynamic retrieving data for different objects

Let’s imagine a case when we need to retrieve contact records and the current user’s record and display them in the lightning datatable on Account’s record page.
As getRecords operates over record Ids, let’s create two components: parentComponent and childComponent. Method getContacts on the parent component will retrieve the Ids of contacts related to the current Account. Yes, we could retrieve all the record details at this stage from Apex, but we have this logic just to demonstrate a case when we have only Id and no other record data.

parentComponent.html. Here we transfer contactIds to the child component.

<template>
    <c-child-component record-ids={contactIds}></c-child-component> 
</template>

parentComponent.js

import { LightningElement, wire, api } from 'lwc';
import getContacts from '@salesforce/apex/ContactController.getContactsByAccount';

export default class ParentComponent extends LightningElement {

    @api recordId; //current Account's Id
    contactIds = [];

    @wire(getContacts, {accountId: '$recordId'})
    retrievedContacts({error, data}){
        if(data){
            this.contactIds = data;
        } else if(error){
            console.log('error: ', error);
        }
    }

}

And Apex controller ContactController that retrieves contact Ids:

public with sharing class ContactController {
    @AuraEnabled(cacheable=true)
    public static List<Contact> getContactsByAccount(Id accountId) {
        return [
                SELECT
                    Id
                FROM
                    Contact
                WHERE
                    AccountId = :accountId
        ];
    }
}

The next one is childComponent.html. Here we display all the data in the form of a lightning-datatable Lightning Base Component.

<template>
    <template if:true={dataIsRetrieved}>
        <lightning-datatable
                data={dataToDisplay}
                columns={columnsToDisplay}
                key-field="id"
                hide-checkbox-column="true">
        </lightning-datatable>
    </template>
</template>

And the last but not least part - childComponent.js.

import { LightningElement, wire, api, track } from 'lwc';
import { getRecords } from 'lightning/uiRecordApi';
import CONTACT_NAME_FIELD from '@salesforce/schema/Contact.Name';
import CONTACT_EMAIL_FIELD from '@salesforce/schema/Contact.Email';
import CONTACT_PHONE_FIELD from '@salesforce/schema/Contact.Phone';
import USER_NAME_FIELD from '@salesforce/schema/User.Name';
import USER_EMAIL_FIELD from '@salesforce/schema/User.Email';
import USER_PHONE_FIELD from '@salesforce/schema/User.Phone';

import userId from '@salesforce/user/Id';

export default class ChildComponent extends LightningElement {

    dataIsRetrieved = false;
    contactIds = [];
    parameterObject;
    dataToDisplay = [];
    columnsToDisplay = [
        { label: 'Object', fieldName: 'object'},
        { label: 'Id', fieldName: 'id'},
        { label: 'Name', fieldName: 'name' },
        { label: 'Email', fieldName: 'email', type: 'email'},
        { label: 'Phone', fieldName: 'phone', type: 'phone'},
        { label: 'Last Modified Date', fieldName: 'lastModified', type: 'date'}
    ];

    @api get recordIds(){
        return this.contactIds;
    }
    set recordIds(contacts){
        this.contactIds = contacts;
        this.parameterObject = [];

        if(this.contactIds.length > 0){
            this.contactIds.forEach(contact => {
                this.parameterObject.push({
                    recordIds: [contact.Id],
                    optionalFields: [CONTACT_NAME_FIELD, CONTACT_EMAIL_FIELD, CONTACT_PHONE_FIELD]
                });
            });
            this.parameterObject.push({
                recordIds: [userId],
                optionalFields: [USER_NAME_FIELD,USER_EMAIL_FIELD, USER_PHONE_FIELD]
            });
        }
    }

    @wire(getRecords, { records: '$parameterObject'})
    wiredRecords({ err, data }) {
        if (err) {
            console.log('error: ',err);
        } else if (data) {
            this.dataIsRetrieved = true;
            console.log('getRecords results: ',data.results);
            data.results.forEach(record => {
                this.dataToDisplay.push({
                    name: record.result.fields.Name.value,
                    email: record.result.fields.Email.value,
                    id: record.result.id,
                    phone: record.result.fields.Phone.value,
                    object: record.result.apiName,
                    lastModified: record.result.lastModifiedDate
                });
            });
        }
    }

}

As you may see, getRecords uses ‘$parameterObject’ with all the parameters inside for retrieving records. A dollar sign $ means using a dynamic variable. The method will be called every time when the dynamic variable is updated. However, dynamic update works for getRecord and other methods that accept primitive types as a parameter, not a collection. That is why I recommend using parameterObject for getRecords. This parameterObject is an array that is filled dynamically when ids of contacts are received from the parentComponent. If the number of Ids or retrieved objects may vary, this is the best workaround for dynamic retrieval records using getRecords.

The final result is the following:

Summary

To sum up, getRecords is a very useful solution for some specific cases when record data should be retrieved by Id, especially from different objects - to minimize the amount of SOQL queries and calls to the backend.

If you found this article helpful, I invite you to connect with me on LinkedIn. I am always looking to expand my network and connect with like-minded individuals in the Salesforce area. Additionally, you can also reach out to me for any questions or feedback on the article. I'd be more than happy to engage in a conversation and help out in any way I can. So don’t hesitate to contact me, and let’s connect and learn together!

DEV Community: Oleksandra Todorenko

Salesforce Flow deactivation using Metadata API

Mass Profile Update in Salesforce. A Quick Step-by-Step Guide

Navigate to the Profiles Page

Create a Targeted List View

Select list view and profiles for editing

Double-Click the Permission to Edit

Modify Permissions in the Dialog Box

Handle Cascading Changes

Save Changes

8 Tips for Pixel-Perfect Email Templates in Salesforce

Validate in different Mail clients

Use Email Template Builder

Table structure

Duplicate style properties

Use only supported properties

Avoid VML in your templates

Simplify editing with a developer console

Disable text editing extensions

Summary

Resolving UnitPrice Recalculation for OpportunityLineItem Update

Example

Update from the Lightning Record Page

Update from Apex

Why UnitPrice gets recalculated

Workaround

Make Salesforce Emailing Effortless: Customize SendEmail Action in 3 Simple Steps

When and why you should think about overriding

A step-by-step guide to Override Standard SendEmail Action

Step 1: Create a Custom Action

Step 2: Set predefined fields

Step 3: Replace Quick Action on the layout

Result

Subscribing to Salesforce Platform Events in Workbench: A Step-by-Step Guide

Table of Content

Creating platform event

Publishing platform event

Subscribing to the platform event using Workbench

Demo

Summary

Lets connect!

LWC getRecords wire adapter: how to retrieve records dynamically

Ways to retrieve record data in LWC

getRecord vs getRecords comparison

Syntax

How to retrieve records for dynamic record Ids

Example of using getRecords for dynamic retrieving data for different objects

Summary

`getRecord` vs `getRecords` comparison

Example of using `getRecords` for dynamic retrieving data for different objects