WOW JUST WOW! The Salesforce Winter 23 release has a ton of very useful features that I’m very excited to start using. For example:
- Write Clear and Intentional Apex Assertions
- Identify Which Sandboxes Get a Preview of the Next Salesforce Release
- Filter Your Stream of Change Events (Generally Available)
- Use Record-Triggered Flows to Update Related Records
- Use In and Not In Operators to Find Related Records
- Filter Your Picklists By Record Type in Flow Screens
- Select Multiple Records from a Table in a Flow Screen (Beta)
- Set Up Server-to-Server Integrations with the OAuth 2.0 Client Credentials Flow
Below are the features that I’m excited to see and some remarks on them. See the Salesforce Winter 23 Release Notes for all the info.
Deliver to Your Customers with Custom Address Fields (Generally Available)
Improve address data accuracy and your users’ experience with Custom Address Fields. For example, add a Warehouse Address field to a standard or custom object. Your users can enter a custom address, or they can use the Google lookup to search for an address. Then you can access each address that’s stored in a custom address field, either as a structured compound data type or as individual address
components. This feature, now generally available, includes some changes since the last release.Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
Why: There are several changes in this release. Custom address fields are now supported for dynamic forms for Flows. If the end user’s personal language is a fully supported or end-user language in Salesforce, the labels for the components of a custom address now appear in that language. You can add a state in the State and Country picklist with a name and code that match the name and code of an
existing state in another country. And the documentation now clarifies expected behavior for address fields around marking fields as required and load times.
The beta process uncovered some new limitations. Custom address fields aren’t supported for Lead Conversion, Approval Process, or the address component of Flows. And Salesforce hasn’t validated custom address fields in Community Profile or Data Export.How: Before you enable custom address fields, review Custom Address Fields Requirements and Limitations. Custom address fields use the State and Country picklists. By default, all countries, territories, and their states and provinces are visible to users. To specify the available picklist values in Salesforce, configure State and Country/Territory Picklists before you enable custom address fields.
Custom Address fields can be really useful under the right circumstances because there are a many limitations and it requires state and country picklists. Review and see if they’re a good fit. Over time, I expect Salesforce to expand on this feature so it’ll be more flexible and applicable.
Filter Custom Report Types by Salesforce Fields (Beta)
Streamline report creation by finding custom report types that include specific standard or custom Salesforce fields. You can filter report types by up to 20 fields to ensure that the report contains the fields you need. For example, find the right report type to show which accounts bought which products by filtering on Account Name, Opportunity Name, and Product Model Number.
Where: This change applies to Lightning Experience in Group, Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions. This feature is a Beta Service. Customers may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at Agreements and Terms.
How: To enable this feature, contact Salesforce Support.
To see this in action, create a report. In the Create Report window, click Filter. Search for one or more standard or custom Salesforce fields. Fields included via lookup or part of composite fields (such as geolocation or address) aren’t available as filter options.
A nice report management feature that’ll help report builders be more productive.
Enhance More Object Record Pages With Dynamic Forms
You can make your account, including person account, contact, and opportunity record pages more robust by configuring them with Dynamic Forms.
Where: This change applies to Lightning Experience in Group, Professional, Enterprise, Performance, Unlimited, and Developer editions.
How: In the Lightning App Builder, open an account, including person account, contact, or opportunity record page. Click the new Fields tab, and place fields anywhere on the page. Or automate the process by migrating your Record Detail component to use Dynamic Forms with the click of a button.
Dynamic Forms for standard objects! This will help streamline many pages! However, it doesn’t look like it supports Cases though.
Do More with Dynamic Related List Filters
Now when you filter dynamic related lists in the Lightning App Builder, you can select multiple filter values for picklist fields. For example, on the Contact record page, filter a dynamic related list to show all cases with a priority of Medium or High. Previously, you could filter by only one picklist value.
Where: This change applies to Lightning Experience in Group, Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions.
A nice enhancement that lets one filer related lists further by using multiple picklist values.
Bulk Manage Picklist Values (Beta)
Save time managing your picklists. You can now delete, activate, deactivate, or replace multiple custom picklist field values at once. Previously, you modified them one at a time. This feature is available in production and in sandbox orgs.
Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
Note: This feature is a Beta Service. Customer may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at Agreements and Terms.
How: Opt in to Advanced Picklist Values Management (beta) from the Picklist Settings page. Then navigate to the custom field definition page. The Values and Inactive Values sections show a checkbox next to each picklist value. You can select multiple values and use one of the new buttons: Delete Selected, Deactivate Selected, Replace Selected, or Activate Selected. This feature is available only for
custom picklists with predefined values.
This helps with picklist management when bulk editing is needed.
Set Field-Level Security for a Field on Permission Sets Instead of Profiles During Field Creation (Beta)
Now when you create a field on an object, you can follow best practices and set field-level security for a field on permission sets instead of profiles. And rather than manually granting access to a field in each permission set, you can set field-level security on permission sets during field creation. This feature is also available when you set field-level security on a field or change the field type on a field.
Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
Note: This feature is a Beta Service. Customer may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at Agreements and Terms.
How: Enable Field-Level Security for Permission Sets During Field Creation (beta) in User Management Settings. Then create an object, set field-level security on a field, or change the field type on a field. When you can assign field-level security, a list of permission sets appears instead of profiles. The list includes permission sets that have Create, Read, Edit, or Delete access on the field’s object. If no permission sets have that access on the field’s object, the list contains all the permission sets. If you must assign field-level security to profiles, turn off Field-Level Security for Permission Sets During Field Creation (beta) in User Management Settings. View Field Accessibility isn’t currently updated by this feature.
A handy toggle that lets one field-level permissions to be easier managed on each field based on whether your org uses profiles or permission sets.
Create Overlays with the New Modal Component
Use modals to interrupt a user’s workflow and draw attention to an important message. A modal, which displays the message on top of the current app window, requires a user to interact with it to regain control over the app.
Where: This feature is available for Lightning Experience in all editions.
How: To create a modal component, import LightningModal from lightning/modal in your JavaScript file. Then, create a component class that extends LightningModal.
/* c/myModal.js */
import { api } from ‘lwc’;
import LightningModal from ‘lightning/modal’;
export default class MyModal extends LightningModal {
handleOkay() {
this.close(‘okay’);
}
}
This component doesn’t use a lightning-modal tag. Instead, the modal’s HTML template uses helper lightning-modal-* components to make the modal’s header, footer, and body. The lightning-modal-body component is required, and the others are optional.
<template>
<lightning-modal-header label=”My Modal Heading”></lightning-modal-header>
<lightning-modal-body>This is the modal’s contents</lightning-modal-body>
<lightning-modal-footer>
<lightning-button label=”OK” onclick={handleOk}></lightning-button>
</lightning-modal-footer>
</template
I’ve always created my own reusable custom modals using the blueprint markup on lightningdesignsystem.com. This new component looks promising so one should look at using it first before rolling their own going forward.
Synchronize Component Data Without a Page Refresh by Using RefreshView API (Pilot)
Whether user-driven or app-invoked, the ability to synchronize data without reloading an entire page is a key user experience requirement. The new lightning/refresh module and RefreshView API provide a standard way to refresh component data in LWC and Aura. Previously, LWC lacked a data refresh API, and Aura only supported the legacy force:refreshView, which doesn’t meet the requirements of modern web development. RefreshView API’s detailed control of refresh scope lets developers create refined user
experiences while maintaining backward compatibility.
Where: This change applies to Lightning Experience in Enterprise, Unlimited, and Developer editions. Contact your Salesforce representative to request to join the RefreshView API pilot.
Note: This feature is not generally available and is being piloted with certain Customers subject to additional terms and conditions. It is not part of your purchased Services. This feature is subject to change, may be discontinued with no notice at any time in SFDC’s sole discretion, and SFDC may never make this feature generally available. Make your purchase decisions only on the basis of generally available products and features. This feature is made available on an AS IS basis and use of this feature is at your sole risk.
How: RefreshView API updates the data for a specific hierarchy of components, known as a view, without reloading an entire page. This refresh ensures complete synchronization with data externally sourced by components in that view. RefreshView API can refresh data for Salesforce platform containers and custom components.
Hopefully this becomes GA and will let developers refresh the components on a page much more easily than today. There are hacks to do this but it’s non-trivial and a PITA.
Use DataWeave in Apex to Enable Data Transformation to Different Formats (Developer Preview)
DataWeave in Apex is now in Developer Preview. This feature enhances native Apex data transformation support by integrating Mulesoft’s DataWeave library into the Apex runtime. It makes data transformation easier to code, more scalable, and efficient. With this feature, Apex developers can focus more on solving business problems and less on addressing the specifics of file formats.
Note: Feature is available as a developer preview. Feature isn’t generally available unless or until Salesforce announces its general availability in documentation or in press releases or public statements. All commands, parameters, and other features are subject to change or deprecation at any time, with or without notice. Don’t implement functionality developed with these commands or tools in a production environment. You can provide feedback and suggestions for the DataWeave in Apex feature in the Trailblazer Community.Where: This feature is available in scratch orgs where the DataWeaveInApex feature is enabled, in both Lightning Experience and
Salesforce Classic experience. The Developer Preview of DataWeave in Apex doesn’t support packaging.
How: You can create DataWeave scripts as metadata and invoke them directly from Apex. Similar to Apex, DataWeave scripts are run within Salesforce application servers, enforcing the same heap and CPU limits on the executing code.
This example shows the transformation of an input CSV file into Contact SObjects.// CSV data for Contacts
String inputCsv = ‘first_name,last_name,email\nCodey,”The Bear”,codey@salesforce.com’; DataWeave.Script dwscript = DataWeave.Script.createScript(‘csvToContacts’);
DataWeave.Result dwresult = dwscript.execute(new Map{‘records’ => inputCsv});
List results = (List)dwresult.getValue();
Assert.areEqual(1, results.size());
Contact codeyContact = results[0];
Assert.areEqual(‘Codey’,codeyContact.FirstName);
Assert.areEqual(‘The Bear’,codeyContact.LastName);
The CSV data is transformed to objects using the DataWeave script csvToContacts.dwl.
%dw 2.0
input records application/csv
output application/apex
—
records map(record) -> {
FirstName: record.first_name,
LastName: record.last_name,
Email: record.email
} as Object {class: “Contact”}
This will make life a lot easier, especially with CSV parsing as the example shows. I do wonder about datetime value parsing and other tricky data types though so this will have to be explored further. I also wonder if one has to have Mulesoft for this feature. It doesn’t seem to be required but isn’t stated either.
Secure Even More Apex Code with User Mode Database Operations (Beta)
Run more database operations in user mode with the enhanced user-mode support. The new Database methods support an accessLevel parameter so that you can run the operations in user mode instead of in the default system mode.
Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.
Note: This feature is a Beta Service. Customer may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at Agreements and Terms. Salesforce doesn’t guarantee general availability of this feature within any particular time frame or at all, and we can discontinue it at any time. It’s offered as is and isn’t supported, and Salesforce has no liability for any harm or damage arising out of or in connection with it. You can provide feedback and suggestions for the feature in the Trailblazer Community.
Why: Apex code runs in system mode by default, which means that it runs with substantially elevated permissions over the user running the code. To enhance the security context of Apex, you can specify user mode access for database operations. Field-level security (FLS) and object permissions of the running user are respected in user mode, unlike in system mode. User mode always applies sharing rules; in system mode they’re controlled by the class sharing keywords.
How: We introduced the user mode feature in the Summer ’22 release with an initial set of overloaded System.Database methods that perform DML and query operations. We added these new methods in this release.
• Database.getQueryLocator methods
• Database DML methods (deleteAsync, deleteImmeidate, insertAsync, insertImmediate, updateAsync,
and updateImmediate)
One now has even more security options when doing DML in Apex. This will help even further with managed package security reviews too!
Write Clear and Intentional Apex Assertions
Improve the readability of your Apex code by using the assert methods in the new System.Assert class that fit the exact conditions that you’re checking for. We still support the existing System class assert methods. But we also recommend that you start using the new ones soon and that you update your existing code to use them.
Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.
Why: Apex provides three assert methods. System.assert(), System.assertEquals(), and
System.assertNotEquals(). While adequate for many use cases, these methods can result in ambiguous or verbose error messages. For example, this Apex code checks for a null value.
System.assertEquals(null, ‘null’);
The resulting exception is correct, but ambiguous between literal nulls and null strings.
System.AssertException: Assertion Failed: Expected: null, Actual: null
The new System.Assert class provides methods that handle all types of logical assertions and comparisons. When you use an assert method intended for a specific condition, the clarity of your Apex code improves. And if the assertion results in an exception, it’s easier to read and understand.
How: Choose a method in the new System.Assert class that best fits the condition. For example, to assert whether two values are equal, use the Assert.areEqual() method, which is equivalent to the existing System.assertEquals():
String sub = ‘abcde’.substring(2);
Assert.areEqual(‘cde’, sub);
Here’s an example of checking for null values.
String myString = null;
Assert.isNull(myString, ‘String should be null’);
This example checks that exceptions are thrown from a method you’re testing and that they’re of the expected type.
try {
methodUnderTest();
Assert.fail(‘Exception failure is always an option’);
} catch (Exception ex) {
Assert.isInstanceOfType(ex, DmlException.class);
Every developer should start using once available! It’ll make the code’s intent easier and shorter! I especially like the Assert.fail and Assert.isNull
Transfer Package Ownership to a Different Dev Hub (Beta)
Transfer the ownership of an unlocked or second-generation managed package from one Dev Hub org to another. A transfer can occurinternally between two Dev Hub orgs that you own, or you can transfer a package externally to another Salesforce customer, Salesforce Partner, or ISV. This change provides a way to sell an unlocked or second-generation managed package.
Where: This change applies to unlocked and second-generation managed packages.
Note: This feature is a Beta Service. Customer may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at Agreements and Terms.
How: To initiate a package transfer, log a case with Salesforce Partner Support. Because this is a complex procedure, Salesforce performs the package transfer process for you.
A niche, but helpful feature that lets one easily sell their package as needed.
Identify Which Sandboxes Get a Preview of the Next Salesforce Release
View which sandboxes get upgraded early (preview), and which sandboxes are scheduled to be upgraded with production orgs (non-preview) during major Salesforce releases. Preview sandboxes provide early access to new features, so you can test your configurations before the production upgrade. Preview sandboxes are upgraded approximately 6 weeks in advance of production orgs during every
major release.
Where: This change applies to sandboxes of Professional, Enterprise, Performance, Unlimited, and Database.com editions.
Why: For non-preview sandboxes, you don’t see new features until they’re generally available.
How: From Setup, enter Sandboxes in the Quick Find box, then select Sandboxes.
This was always a PITA in the past. I’m very glad one can easily see from the typical sandboxes page in the production org which ones will be upgraded during the preview window and plan accordingly!
Filter Your Stream of Change Events (Generally Available)
Receive only the change events that you’re interested in instead of all record changes for an entity. Use a filter expression in a channel member, and specify the record and ChangeEventHeader fields and values to filter change events on. Only the matched change events are delivered to your client. With fewer events delivered, you make more efficient use of your event delivery allocation.
Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions. If you use Government Cloud and your org was created before January 14, 2022, contact Salesforce to enable this feature. Government Cloud orgs created on or after January 14, 2022 have this feature enabled. This feature is available in all other clouds.
How: With the Customize Application permission, you can configure stream filtering using Tooling API or Metadata API. To create a channel, use PlatformEventChannel. To add a filter expression for a change event, use PlatformEventChannelMember.
For instance, to receive change events only for accounts whose industry is Agriculture and number of employees is over 1,000, specify this filter expression in the PlatformEventChannelMember.FilterExpression field for AccountChangeEvent.
Industry=’Agriculture’ AND NumberOfEmployees>1000
The fields that you select in the filter expression are automatically added as enriched fields. As a result, change events contain the non-empty selected fields, even when they’re unchanged, and the events can be filtered. In the example filter expression, the Industry and NumberOfEmployees fields are added to the received changed events in the filtered channel if they have a non-empty value.
Note:
• This feature supports CometD and Pub/Sub API subscribers. It doesn’t support Apex triggers.
• All field types supported for enriched fields are supported in filter expressions.
This feature was offered last release in pilot. In this generally available release, we made these enhancements.
• You can filter on most ChangeEventHeader fields in the filter expression. Array fields in ChangeEventHeader aren’t supported.
• You can rename fields without breaking filter expressions with old field names. Field names used in the filter expression map to the
correct fields.
Note: If a filter expression was created before Winter ’23, renamed fields work only after you update the filter expression and
save the channel member again.
• If a Salesforce org has a namespace, you can use the namespace prefix in the filter expression.
• If a filter expression was created before an org had a namespace and the filter expression didn’t contain the namespace prefix in the
field names, the filter expression is automatically updated with the namespace prefix and continues to work.
• You can package a filter expression in PlatformEventChannelMember.
• When filter expressions are evaluated, field-level security is ignored. Filter expressions are evaluated on all fields included even if the
subscriber doesn’t have access to the fields. Events delivered in the filtered stream include only the fields that the subscriber has
access to and exclude the fields the subscriber doesn’t have access to.
• Validation is tighter with custom field type changes now blocked when the field is referenced in a filter expression.
• Fields used in a filter expression are case-insensitive.
• Text queries in a filter expression are case-insensitive, except for custom fields marked as case-sensitive.
This is huge! Change Data Capture (CDP) is becoming more and more used and the ability to filter the records to only relevant changes is a huge enhancement, especially given the limits one has on them. It’s a bummer one can’t do it on Apex Triggers though.
Monitor Your Daily Event Delivery Usage with REST API
Monitor your event publishing and delivery usage easily in Setup for high-volume platform events and change events. The event publishing usage applies to all publishing methods for high-volume platform events. The event delivery usage counts against the default allocation for only to CometD, Pub/Sub API, and the empApi Lightning component.
Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.
How: From Setup, in the Quick Find box, enter Platform Events, and then select Platform Events.
A nice-to-have to see how one’s Event Delivery Usage is in the UI.
Cut and Paste Flow Elements
Change the order of flow elements in auto-layout faster by using cut and paste. Previously, to move an element on the canvas, you copied and pasted the element then deleted the original element, and then you updated the API name of the pasted element.
Where: This change applies to Lightning Experience and Salesforce Classic in Essentials, Professional, Enterprise, Unlimited, and Developer editions.
How: To cut an element, click the element and select Cut Element (1). To paste the element that you cut, hover over where you want to paste, and then click (2).
A very helpful enhancement when building flows!
Use Record-Triggered Flows to Update Related Records
Now you can use record-triggered flows to update any records related to the triggering record.
Where: This change applies to Lightning Experience and Salesforce Classic in Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions.
How: Use the Update Records element and select Update records related to the objectName record that triggered the flow. Then, select the related records you want to update. You can also set filters to update only certain related records. If you don’t specify a filter, all related records are updated.
Another very useful enhancement when you want to update a record’s child records when that record is updated!
Use In and Not In Operators to Find Related Records
With the new In and Not In operators, a flow accesses a collection of primitive values to get related records without using the Loop element. The flow uses fewer SOQL queries and DML statements, and performs faster. The new operators support accessing collections of type Text, Number, Date, Date/Time, Currency, and Boolean. The operators are available in the Get Records, Update Records, and Delete Records elements.
Where: This change applies to Lightning Experience and Salesforce Classic in Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions.
Why: To ensure your flows don’t exceed governor limits, use the In operator. For example, a flow gets all related contacts if their role equals Decision Maker and if their related accounts have a shipping state in California. With the new In operator, the flow executes the Get Records element only three times. That’s three SOQL queries no matter how many contacts the flow finds.Because the In and Not In operators don’t support accessing values on record collections in this release, the flow assigns the account IDs to a text collection, caAccountIds. The Get Records element gets all related account contact roles if their account IDs are in caAccountIds and if their Role equals Decision Maker.
Previously, the Loop element iterated over a collection of values to get related records. Each time the flow got a related record via the Loop element, the flow used one SOQL query. If the flow got over 100 records, the flow failed because it exceeded the governor limit of 100 SOQL queries per transaction. If you debugged the flow, the debug details showed over 100 executions of the Loop and Get Records elements.
Here’s some more examples of using the new operators:
• Get a list of related account contact roles if their account IDs aren’t in the caAccountIds example.
• Update a collection of contacts based on an opportunity’s roles when an opportunity is Closed – Won.
• Get a list of accounts in a list of countries to display in a data table.
• Get a list of records using the Record ID Collection output of the newly enhanced Lookup screen component.
• Get a list of products from a custom action that outputs a collection of IDs from an external system.
How: Add one of these flow elements: Get Records, Update Records, or Delete Records. Configure the element filters to use the In or Not In operators.
This is HUGE! I’ve been waiting for this for almost a decade! Being able to use 1 Get Records to grab all records with a given set of Ids is something I’ve been lusting after for many years. One had to resort to Invocable Apex to do this. Now if only one could do sub-selects in a Get-Records, then that would be even better!
Launch Screen Flows with Lightning Web Components
Embed a screen flow from any Lightning Web Component with the new lightning-flow component. Developers can supercharge their flows by customizing finish behavior, setting custom styling, or launching flows from their Lightning Web Components. And they can offload complex input collection and branching logic to Flow, saving time and money.
Where: This change applies to Lightning Experience in Essentials, Professional, Enterprise, Unlimited, and Developer editions.
How: This example shows an LWC component with the Survey_customers flow API name.<template>
<lightning-flow flow-api-name=’Survey_customers’>
</lightning-flow>
</template>
One doesn’t have to use an Aura component for this any more! Now LWCs are at parity with Aura!
Filter Your Picklists By Record Type in Flow Screens
Now you only see relevant picklist values when using Dynamic Forms for Flow. Previously, all the picklist values for a field appeared, regardless of whether a record type was provided, and could show irrelevant values.
Where: This change applies to Lightning Experience and Salesforce Classic in Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions.
How: To filter picklist values by record type, set the record type ID for the record variable before using the picklist in a Screen element. At runtime, the picklist values are filtered by that record type. To continue to show all picklist values for your field use a picklist choice set instead. Or, for the record resource you’re using, don’t set the record type ID.
It’s about time! This has always been a thorn and one can’t easily determine the picklist values for a given record type in Apex either. There are various work arounds but they all suck. This will be very helpful to all flow builders!
Select Multiple Records from a Table in a Flow Screen (Beta)
Leverage the new Data Table (beta) flow screen component to display a list of records on a flow screen. You can set the table to read only, or enable your users to select one or more records and use their selections later in the flow. And users can change the width of table columns and wrap or truncate overflowing text.
Where: This change applies to Lightning Experience and Salesforce Classic in Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions.
How: Add the Data Table (beta) component to your screen flow and configure the fields
I can’t tell you how many times I’ve had to create custom components for this or use some third-party component. The data table component seems very helpful for this!
Set Up Server-to-Server Integrations with the OAuth 2.0 Client Credentials Flow
To directly share information between Salesforce and a third-party app, set up the OAuth 2.0 client credentials flow. With this flow, the third party exchanges its client credentials defined in the connected app—its consumer key and consumer secret—for an access token. Because there’s no explicit user interaction in the client credentials flow, it’s useful for scenarios such as running automated reports. We also recommend using this flow as a more secure alternative for the OAuth 2.0 username-password flow.
Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
This is really useful. One can easily get an API access token by using just the client id and client secret. The setup designates the running user so one doesn’t have to provide the username, password, and security token in the authentication request! This means that the client doesn’t have to store the user credentials and doesn’t need to know them either. The tradeoff is that this is potentially less secure. If this meets your security requirements, it’ll make setup much easier. For more information, see this help page.