#New Releases39 人正在讨论

Hi Vikrant, autocomplete="off" isn't supported directly by lightning-input-field because it doesn't expose the underlying <input> element's autocomplete attribute. 

If you need to control autocomplete, you can use lightning-input instead of lightning-input-field and set: 

<lightning-input
    type="text"
    autocomplete="off"
    name="myField">
</lightning-input>

If you need to keep lightning-record-edit-form and lightning-input-field, you generally can't reliably disable the browser's autocomplete through the component attribute. 

If you can share which field you're trying to disable autocomplete for and what browser you're testing in, I can suggest a more specific workaround. 

Hi Ferry, this could be related to regional latency or temporary performance issues with the Salesforce Help site.  

Since you're seeing 10+ second load times consistently from Sydney, it would be useful to compare the behavior across different networks/browsers and check whether other users in the same region are experiencing it.  

If the issue is still occurring consistently, I'd recommend opening a Salesforce Support case with the affected URLs, timestamps, browser/network details, and ideally a HAR file. That will give Salesforce more information to investigate the regional performance issue. 

Hi Nisha, this can happen if there is an issue with the Classic Email Template folder page or if the required permissions aren't available.  

Please check that you have the “Manage Public Classic Email Templates” permission (or the appropriate email template management permissions) and that you have access to the Classic Email Templates folder functionality.  

Also try refreshing the page or accessing Setup → Classic Email Templates → Create New Folder again from a fresh Salesforce session.  

If the same error persists after verifying the permissions, I recommend creating a Salesforce Support case and providing the URL and exact error message, since the error itself suggests Salesforce Support investigate the page request 

Hi Jo-Ann, this may be related to a change in how the Reports tab Recent Records list is populated rather than a change to the reports themselves. 

I'd first check whether the affected users are seeing the same behavior in Lightning Experience and whether the reports they previously opened appear under Recent Records when accessed directly. 

If this started suddenly across multiple users and you can reproduce it consistently, could you share the Salesforce release/org version and a screenshot of the Reports dropdown? That would help determine whether it's an expected release change or a Salesforce issue. 

If everything was working previously and the behavior continues after checking the above, it may be worth creating a Salesforce Support case so they can verify whether there's a known issue affecting the Recent Records list. 

Hi Paul, I haven't seen a lot of reports around this specific Summer '22 change, but the update to IsStopped could affect automation that relies on the entitlement/milestone stopping when a case exits the entitlement process.  

If you're seeing unexpected behavior, could you share a bit more detail about the scenario—especially the Entitlement/Milestone configuration, how the Case exits the entitlement, and what behavior you're seeing after the Summer '22 update? That would make it easier to determine whether it's expected behavior or a regression.  

If you can reproduce it consistently in a sandbox, comparing the behavior before and after enabling the release update would also be useful. 

Hi Kashan, the PHP version is controlled by your hosting provider/server, not by the website URL itself. 

If your hosting control panel provides a PHP Version / MultiPHP Manager / Select PHP Version option, you can switch the site to the required version there. If PHP 7 isn't available, you'll need to contact  

your hosting provider and ask whether they can enable it for your account.

One important point: PHP 7 is no longer supported, so if the website or its code requires PHP 7, it's worth checking whether it can be updated to a supported PHP 8.x version instead. 

If you can share the hosting provider (cPanel, GoDaddy, Hostinger, etc.) and the exact PHP error, we can suggest the specific steps. 

Hi Sara, “encoded” here means Salesforce is URL-encoding certain parts of the SAML URLs/parameters before sending them as part of the SSO request. 

For example, characters such as ?, &, =, spaces, etc. can be represented in an encoded form so they’re interpreted correctly as part of the URL rather than as separators or special characters. 

For SP-initiated SSO, the change applies to the Identity Provider URL and ACS URL. Salesforce also encodes the Single Logout Endpoint and Relay State for SLO configurations. 

For most Salesforce configurations, there shouldn't be anything you need to change. The main concern is if the external IdP or SAML application has custom logic that expects the URLs in their previous, unencoded form. Salesforce recommends testing existing SAML integrations before enabling the update because third-party integrations can be affected. 

So, if your SSO integration is working normally after enabling the update, there shouldn't be any action required. 

Hi, the GA4 connector is different from the older Google Analytics/GA 360 connector, so you shouldn’t expect the same predefined objects such as Traffic or Global Access to appear. 

The GA4 connector uses the Google Analytics Data API and exposes virtual objects based on the dimensions and metrics available through that API. Salesforce also notes that you select the objects and configure their PropertyID, StartDate, and EndDate through the connection's Advanced Object Properties. 

So rather than looking for the old GA 360 object names, I’d recommend checking the available GA4 virtual objects and choosing the dimensions/metrics that correspond to the data you need. Salesforce also recommends using Google's Dimensions & Metrics Explorer or Query Explorer to verify that the desired combinations are supported.

If you can share which fields/data from the old Traffic and Global Access objects you need, we can identify the closest GA4 dimensions and metrics. 

Hi Alex, with the Winter ’24 LWR checkout changes, the custom component needs to be placed within the new Checkout Section and follow the interfaces supported by that checkout architecture. 

The CheckoutSavable behavior isn't something you implement by importing an interface into the LWC. The checkout framework invokes the supported public methods on the component when it participates in the checkout flow. 

I'd first verify that the component is using the current Commerce checkout component contract for the Winter ’24/LWR layout, because the older checkoutMode, reportValidity(), and checkoutSave() example may not apply to the new Accordion/Checkout Section architecture. 

If you're already following the current documentation and those methods still aren't being invoked, could you share the component configuration in Experience Builder and the exact Commerce/LWR version? That would help determine whether this is a configuration issue or a regression with the new checkout layout.