Update Records Using ISO State and Country Codes
Standardize and simplify updating address records with two new fields that store the ISO code for country or territory and state or province. Improve data quality and accuracy using this new support for ISO codes, and reduce the risk of errors and inconsistencies that can occur when using names. Previously, the Address component stored only the name associated with the user’s selection. With this new support for ISO codes, you can update the country or territory and state or province fields on records with ISO codes instead of names.
This feature can be used for new or existing screen flows. Here are the steps to create a new flow.
- In Setup, on the State and Country/Territory Picklists page, ensure that Enable Picklists for Address Fields is enabled.
- In Flow Builder, create a screen flow.
- Add a Screen element to the flow.
- Include an Address component in the Screen element. Optionally, specify a default value in the Country Code and State or Province Code fields.
- Save and run the flow.
- Later in the flow, use the StateCode and CountryCode values to update or create records.
This change applies to Lightning Experience and Salesforce Classic in Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions. It’s not supported in Classic runtime for flows.
Use the Data Model Gallery on the Salesforce Architects’ Site
Architects can use the Salesforce Data Model Gallery to understand the functional structure of Salesforce data and create more efficient and effective Salesforce solutions.
An entity relationship diagram (ERD), also known as a data model, is a graphic representation of an information system that conveys the functional structure of data. In Salesforce ERDs, entities typically map to an object in the Salesforce database. Data models housed on the Salesforce Developers’ website are being updated and moved to the Salesforce Architect’s site. Design better data models and workflows by understanding how different objects in Salesforce are related. Bookmark the Salesforce Data Model Gallery to access the latest data model diagrams.
Get Started with Bitbucket Cloud
Change sets are a traditional Salesforce method for deploying changes, but Salesforce is moving toward more modern DevOps practices. The Salesforce DevOps Center provides an improved experience around change and release management for development teams. Salesforce now offers a much-requested integration for teams who use Bitbucket. Although we’ve built a framework for DevOps Center to eventually integrate with multiple third-party source control systems, we now support Bitbucket Cloud in beta and GitHub.com.
Each DevOps Center project needs its own repository for storing project changes. The repository stores project work files, such as code, text, and images. You can set up DevOps Center to use a Bitbucket source control repository. Currently, we support Bitbucket Cloud.
Salesforce is also transforming the UI by moving DevOps Center functionality to Lightning Experience. This will give you more control and flexibility in customizing how things look and work. During this transition period, some tasks for setting up and configuring Bitbucket will be done in Lightning Experience, and some will still be done in the DevOps Center app. Menu options and buttons help you smoothly transition between the two.
Deprecated sfdx source/mdapi/org commands have been removed. Salesforce is standardizing the sf
command syntax and structure to reduce complexity. Transition from the deprecated sfdx
commands to the new sf
commands. Salesforce is moving toward a source control-centric approach following DevOps best practices.
Enable Messaging for In-App and Web API in Scratch Orgs
Deliver a highly customized mobile app or website messaging experience for your agents and customers using the Messaging for In-App and Web (MIAW) API to programmatically manage conversations. Developers can now develop and configure MIAW solutions within scratch orgs.
Create conversations that store messaging sessions, generate access tokens, and send messages and files. You can also configure server-sent events to provide more information related to the conversation.
Solution engineers and developers can work in scratch orgs via Salesforce Developer Experience (SFDX). SFDX is a set of tools designed to improve the traditional developer’s experience building on the platform. Set up the MIAW feature with a custom client deployment and then configure via the MIAW API. MIAW can be enabled via the Metadata API and the Salesforce CLI.
This update applies to Enterprise and Unlimited editions with the Messaging In-App and Web and Digital Engagement add-ons.
Create an External Client App from App Manager
When creating a connected app in App Manager, you can now choose to create an external client app instead. These apps offer a more secure way to connect third-party applications with your Salesforce data. Designed for second-generation (2GP) packaging, source-driven development, and scratch org compatibility, external client apps are easier to manage and distribute. They maintain a clean separation between proprietary developer settings and customizable admin-defined policies, and will eventually support the majority of connected app use cases.
When you click New Connected App in App Manager, a window opens with options to either continue creating a connected app or open the External Client App Manager and create an external client app.
This change applies to Lightning Experience and Salesforce Classic (not available in all orgs) in Group, Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions.
Customize User Experience and Functionality for Authentication Providers
Deliver different user experiences with a single authentication provider by using a URL parameter allowlist. This feature enhances the flexibility of single sign-on (SSO) flows, since you can add a custom URL parameter to an authentication provider URL. Use a single authorization provider and a parameter instead of requiring the configuration of multiple authentication providers.
For example, imagine that you host a site on Experience Cloud. Users go to your Experience Cloud site, select their language preference, and are redirected to your login page, where you display an option to log in with Google. Previously, the only way to specify the display language for that user was to configure a different authentication provider for each language and statically specify the user's locale. Now, you can configure just one authentication provider and add a locale parameter to your authentication provider allowlist. When the user chooses their language, Salesforce forwards the parameter value to the authentication provider URL so that it can then be passed to Google. This approach eliminates the need to manage multiple authentication providers and enhances user experience by dynamically adapting to user preferences.
Use the URL Parameter Allowlist for Authentication Providers
Select your metadata development tool of choice, such as Salesforce CLI, to create an AuthProvParamFwdAllowlist metadata type that stores the URL parameter you want to add. Each instance of AuthProvParamFwdAllowlist stores one allowlisted parameter. If your SSO flow passes any allowlisted parameters to Salesforce, Salesforce automatically forwards the parameters to your authentication provider's client configuration URLs. This new ability to forward parameters means you can pass important information to Authentication Providers in multiple instances using a single configuration. This eliminates the need for redundant configurations to cover multiple scenarios.
This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.
Be an Early Adopter of a Headless Identity Draft Standard
Stay current with industry developments for Open Authorization (OAuth) 2.0 and Salesforce headless identity. Headless identity helps you separate back-end authentication processes from front-end identity experiences. With headless identity, you can embed identity features and extend Salesforce APIs and data into any app built on any platform.
Headless Identity Flows Now Conform to the OAuth 2.0 Standard
Headless identity relies on APIs to handle authentication tasks such as login, registration, and password resets. Salesforce headless identity flows now conform to Open Authorization (OAuth) 2.0, which is a standard designed to allow a website or application to access resources hosted by other web apps on behalf of a user.
When Salesforce first released Headless Identity APIs, there was no proposed standard for headless app authorization, so Salesforce provided proprietary flows built on top of OAuth. Now you can set up headless username-password login, passwordless login, and registration flows that conform to the OAuth 2.0 for First-Party Applications draft standard. When finalized, this will become a widely accepted standard and all of your Headless Identity Flows will be compatible with the broader industry.
This change applies to Lightning Experience and Salesforce Classic (not available in all orgs) in Enterprise, Unlimited, and Developer editions.
Process Platform Events at Scale with Parallel Subscriptions for Apex Triggers
To speed up platform event processing in an Apex trigger, use parallel subscriptions to process events simultaneously instead of in a single stream. By processing events simultaneously rather than sequentially, you can significantly speed up the handling of high volumes of events. Parallel subscriptions are available for custom high-volume platform events but not standard events or change events.
How your system distributes events to parallel subscriptions depends on the partition key that you specify—the standard EventUuid
field or a platform event custom field. You can specify up to 10 parallel subscriptions, also referred to as partitions.
This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.
Ingest Company Data into Data Cloud with ZoomInfo Connector
Streamline your organization’s marketing efforts by ingesting the latest business intelligence from ZoomInfo directly into Salesforce.
With current, detailed research, teams can focus on sales and marketing instead of data collection. ZoomInfo uses AI and machine learning to gather and verify business information, such as company revenue, employee count, ownership structure, market activity, and growth information.
Use the ZoomInfo connector in your Data Cloud setup to access the most up-to-date ZoomInfo data. The integration helps reduce manual entry time and errors. With the Salesforce ZoomInfo connector, teams have access to research data on customers and prospects, including verified email addresses, direct-dial phone numbers, detailed job responsibilities, tech stacks, and more.
In Data Cloud Setup, under Connectors, create a connection using the new ZoomInfo connector. Then in Data Streams, select the connection as your source.
Transfer Your Private Snowflake Data to CRM Analytics from AWS VPC
Gain insights into your private Snowflake data in CRM Analytics. Create a remote connection using the new Snowflake Private Connector to sync data from Snowflake running on AWS to Data Manager in CRM Analytics. Using the AWS VPC interface endpoints provides secure connectivity to Snowflake internal stages. And it ensures that data transfer from Snowflake takes place on the AWS internal network and doesn’t use the public internet. Now you can analyze and interpret your Snowflake data using the powerful analytics tools in CRM Analytics to make data-driven decisions and gain deeper insights into your business operations.
This change applies to Salesforce Data Pipelines in Lightning Experience. Salesforce Data Pipelines is available for an extra cost in Enterprise, Performance, and Unlimited editions.
Prerequisites
- Requires Salesforce Private Connect.
- You must configure your Snowflake for Private Link. Learn how to do this by reviewing the Snowflake guide, AWS PrivateLink and Snowflake.
From Setup, in the Quick Find box, enter Private
, and select Private Connect. Create an outbound connection, and then on the Named Credentials page, create external credentials and named credentials. In Data Manager, create a connection for the Snowflake Private Connector.
Register More API Specifications with Support for YAML
Developers can now use YAML or JSON to register API specifications, providing more options and flexibility to define and manage APIs. YAML is often favored for its human-readable format, making it easier to write and understand, especially for complex configurations. Previously, you could register only JSON-formatted specifications. Developers can still rely on JSON for data exchange when creating or deploying APIs, but may choose YAML’s readability and structure if preferred. YAML has a size limit of 3 MB. Choose between JSON or YAML formatting to register External Services-compliant OpenAPI 2.0 or 3.0 specifications.
This change applies to Lightning Experience in Enterprise, Performance, Unlimited, and Developer editions.
Improve Data Transmission Speed and Security with TLS 1.3
The TLS protocol provides security for data sent over the internet through encryption, authentication, and data integrity verification. It provides stronger encryption methods and a more efficient handshake (authentication), which means faster and more secure connections. Coordinate with the owner of the receiving endpoint (the server Salesforce is calling) to enable TLS 1.3.
With version 1.3 of Transport Layer Security (TLS), you can improve your data transmission speed and security. To help you adopt the latest standard, Salesforce now supports TLS 1.3 for outbound HTTPS callouts from the Salesforce Platform.
Implementation of TLS 1.3 includes:
- Test the change in a sandbox environment before updating your production environment.
- Enable TLS 1.3: Work with the receiving endpoint owner to enable TLS 1.3.
- Disable TLS 1.2: Optionally, after the callout successfully uses TLS 1.3, work with the owner to disable TLS 1.2 on the receiving endpoint.
TLS 1.3 uses stronger encryption methods than 1.2, and the simplified handshake process in 1.3 reduces the time needed to establish secure connections.
This change applies to all Salesforce interfaces: Lightning Experience, Salesforce Classic (though not available in all orgs), and all versions of the mobile app. This change has no impact on existing callouts that require TLS 1.2.
Great job, you’re up to date on the latest integration enhancements. You learned about Platform Event parallel subscriptions for Apex triggers, using the ZoomInfo connector, and how to transfer your Snowflake data to CRM Analytics securely. You can choose YAML to register API specifications and improve data transmission speed and security with Transport Layer Security (TLS) 1.3. In the next unit, explore what’s new in access control for the Salesforce Platform.
Get a Summary of a User’s Permissions and Access
Make it easier to manage permissions and troubleshoot access settings with a consolidated view of a user’s key details. The User Access Summary lets you see which permissions, public groups, or queues a user is assigned. You can now see this information directly from the user’s detail page, saving you time and effort. There’s no need to run queries or look through each profile, permission set, public group, or queue when troubleshooting or managing access.
To access this feature, from Setup, enter Users
in the Quick Find box and then select Users. Select a user, and then click View Summary.
This change applies to Lightning Experience and Salesforce Classic (not available in all orgs) in all editions.
View How Object Access Is Granted in Object Manager
Use a new summary view of object permissions when troubleshooting, completing reviews, or determining how to grant user access. Use the read-only Object Access Summary in Object Manager to view permission sets, permission set groups, and profiles that grant access to an object. Establish the level of access, such as read, create, or edit. To view the Object Access Summary, go to Setup, then Object Manager, and then select an object. In the sidebar, click Object Access.
This change applies to Lightning Experience in all editions.
Automate and Migrate User Access with User Access Policies
With user access policies, you can define aggregated access for your users in a single operation. This feature is now generally available and includes enhancements. For example, you can now create 200 active policies, up from 20, and set the order in which active policies are run.
User access policies help you streamline user setup. Instead of assigning individual features to users one at a time, create policies that assign multiple features all in one go. Automate your policies to run throughout the user management lifecycle, for example:
- Set up new users.
- Grant or remove access after role changes.
- Migrate users to a new access setup in bulk.
Automate your users’ assignments to permission sets, package licenses, public groups, and other access features based on the criteria that you set. Create policies that automatically grant or remove access. Easily migrate large sets of users to a new access setup in a single operation.
- To enable this feature: From Setup, in the Quick Find box, enter
User Management Settings
, then select User Management Settings. Turn on User Access Policies. - To create or manage your user access policies, in the Quick Find box, enter
User Access Policies
, and then select User Access Policies.
This change applies to Lightning Experience and Salesforce Classic (not available in all orgs) in Enterprise and Unlimited editions.
Comments
Post a Comment