Information on each Winter '27 patch release for the Communications, Media, and Energy & Utilities managed package. Periodically, we add patch releases for Winter '27. Check back here for information.
For package download links, see Communications, Media, and Energy & Utilities Patch Links.
For Omnistudio patch notes, see Omnistudio Releases.
If you’re looking for installation links for previous versions, contact Salesforce Customer Support for help.
CME 264.9.900.661
This patch contains security fixes to Communications, Media, and Energy & Utilities (CME), Contract Lifecycle Management, and Omnistudio to ensure features work correctly.
CME 264.8.900.660
This patch contains fixes to Communications, Media, and Energy & Utilities (CME), and Industries CPQ to ensure features work correctly.
| Product Area | Issue | Description |
|---|---|---|
| Industries CPQ | When Enhanced Caching is enabled, the CompilePCP process uses a bookmark to track its position between chunks. The bookmark is saved under names like PriceListEntry or Promotion, but read back under the name PCP — a name that is never written. So every chunk after the first resets to page one, re-fetches the same records, and never caches new PCP records, leaving standalonePCPcachekeys empty or incomplete. The fix is to align the read and write sides on the same key name, so the bookmark is found correctly and each chunk resumes from where the previous one ended. | The fix is to change the read site in compileStandalonePCPEnhanced to look up PriceListEntry instead of PCP, which ensures the bookmark saved at the end of one chunk is found at the start of the next, so pagination advances correctly and all PCP records are fully cached. |
| Industries CPQ | When parallel pricing workers run simultaneously, they can generate cache entries with
the same natural identity — derived from Type__c,
CacheKey__c, OverflowSequence__c, and
ConfigurationSnapshotId__c. When the upsert runs, duplicate identities
compete to update the same row, causing Salesforce to throw UNABLE_TO_LOCK_ROW or
DUPLICATE_VALUE errors that exhaust retries and fail the compile job. To avoid
this, workers are currently forced to run sequentially, which eliminates the contention but
significantly slows the overall compile time.
|
The fix is to restore parallel execution and resolve duplicates in a cleanup step after all workers finish. Since duplicate rows always carry the same compiled response for the same natural identity, workers can write freely in parallel without coordination. Once all workers complete, a final job groups rows by UniqueIdentifier__c, retains one canonical row per group, and deletes the rest. This restores parallel throughput while guaranteeing a single canonical row per natural identity in the final cache. |
CME 264.7.900.659
This patch contains fixes to Communications, Media, and Energy & Utilities (CME), Industries CPQ, and Energy & Utilities to ensure features work correctly.
| Product Area | Issue | Description |
|---|---|---|
| Energy & Utilities - Self-Serve Portal | When the Self-Serve Portal created a customer community user and assigned a permission set, it didn't verify that the request was for a customer community user. Also, the EnergySelfServiceGuestUser permission set gave guest users read access to fields that store credentials and personal information, and some queries didn't consistently use bind variables. | The Self-Serve Portal now creates a customer community user and assigns the permission set only when the user's profile is a Customer Community profile with a Customer Community license. The EnergySelfServiceGuestUser permission set no longer gives guest users read access to credential and personal information fields. Queries in the Self-Serve Portal now use bind variables to help prevent SOQL injection. |
| Industries CPQ | Bulk Disconnect fails silently on MACD orders when the underlying product's Selling End Date and End Date are in the past. The product effectivity check, which determines whether a product is sellable, is applied before the Disconnect operation runs. As a result, expired products are filtered out and never reach the disconnect step, causing the working cart to render a blank page and the Bulk Disconnect to fail without any error message. This prevents customers from disconnecting already-provisioned assets once the product's selling window has closed, which is a legitimate business operation. The only available workaround is to temporarily clear or forward-date the Selling End Date on the affected products, run the Bulk Disconnect, and then restore the original dates, an approach that is operationally painful, not scalable, and risks pricing and catalog drift. | Decouple the product sellability check from Disconnect and Bulk Disconnect flows so that it applies only to ADD and New Sale actions. The working cart must load all in-scope assets for disconnection even when the underlying product's Selling End Date and End Date are in the past, and the operation must complete end-to-end with proper success or failure feedback. The existing sellability check for ADD flows, the Selling End Date and End Date sync behavior on Product2, and all non-expired product flows remain unchanged. Public documentation must be updated to clarify the Selling End Date and End Date relationship and the permitted behavior for Disconnect on expired products. |
| Industries CPQ | When a product that carries a promotion attribute override is migrated between orgs through a VBT DataPack import, the attribute metadata override can arrive empty in the target org, leaving CompiledAttributeOverride__c. AttributeMetadataChanges__c blank so the CAO record exists but has no effect. The root cause is that the override delta is calculated as the difference between the product’s baseline attribute metadata and the override’s metadata. During the import, the product is recompiled in a way that folds the override’s own values back into the product baseline, so when the delta is computed, the two sides match and the difference comes out empty. | Product recompilation during DataPack import now rebuilds the baseline from base attribute assignments only, excluding override values, so the baseline stays clean and the override delta is computed and populated correctly. The fix also re-establishes the link between the override definition and its compiled override record, so the compiled override record is no longer left dangling after import. The change is delivered behind a Core gate (com.salesforce.industries.cpq.updateProductJsonOnDatapack) that is off by default; existing behavior is unchanged until the gate is registered and opened in Core, at which point DataPack imports populate the field correctly with no manual steps required. |
| Industries CPQ | A user with Read-only access to Product2 and no Edit permission on AttributeAssignment__c can successfully save product attribute changes in the Service Console, bypassing object-level CRUD enforcement. The save commits without an insufficient-privilege error, allowing unauthorized updates to Product2 and AttributeAssignment__c records, and unauthorized creation of Product2 templates via the Save Template path. The same user is correctly blocked in the Product Designer with an insufficient-privilege error. The root cause is that the Service Console save path in ProductAttributesDisplayController.saveAttributesV2 performs no explicit CRUD check before executing DML. The only permission gate runs in the constructor, is never invoked for static remote actions, checks the wrong verb, and swallows its exception. As a result, all DML in ProductAttributeService executes without validating object permissions. | Add explicit object-permission checks before all database write operations in ProductAttributeService. Before saving or updating product attributes, the code must verify that the current user has Edit permission on Product2 and AttributeAssignment__c. Before creating a product template, the code must verify that the user has Create permission on both objects. If the user lacks the required permission, the operation must be blocked and return an insufficient-privilege error, consistent with the behavior already enforced in the Product Designer. As an additional layer of defense, field-level security checks must be applied to ensure users cannot write to fields they do not have access to. The same permission checks must also be extended to the delete and upsert operations on the same page, specifically the delete attribute, delete category, and save product configurations actions, to ensure consistent enforcement across all write paths. Finally, add test coverage to confirm that a Read-only user is blocked from saving or creating records, and that a user with the correct permissions can still complete these operations successfully. |