This article is for Salesforce admins, implementation partners, and solution consultants who need to keep selected shopping cart lines visible while preventing buyers from editing them through normal storefront interactions.
Use read-only cart items when the business needs to protect specific lines after they are added to the cart. Typical examples include approval-controlled bundles, automatically added service lines, protected products, and derived rows that support pricing or service logic.
What read-only cart items are for
Read-only cart items let the storefront show a cart line without treating it like a normal buyer-controlled line.
Use this behavior when you need to:
- keep auto-added or policy-driven lines visible in the cart
- prevent buyers from changing protected bundle or service rows
- preserve system-managed lines while still showing buyers how totals are built
The locking behavior is controlled by the Read Only field on Shopping_Cart_Item__c.
- Label: Read Only
- API name: Shopping_Cart_Itemc.Read_Onlyc
- Field type: Checkbox
When this field is set to true, the storefront starts treating the line as protected immediately.
How the storefront behaves when a line is locked
When a shopping cart item is marked as read-only, the standard storefront cart keeps the line visible but stops using the normal interactive edit flows for that row.
In the current cart implementation, buyers can no longer use the standard row-level flows for:
- inline quantity changes
- addon-edit flows for the locked parent item
- other interactive update requests that go through the standard storefront cart controllers
The lock is also inherited by generated child rows that are created from the protected parent item. This includes grouped child rows and addon rows created as part of the same cart workflow.
Because storefront customizations can vary, validate any custom row actions separately. If your storefront exposes extra cart actions beyond the standard quantity and addon flows, confirm that those actions also respect your intended lock behavior.
How to set the field through automation or data operations
There is no separate storefront configuration switch for read-only cart items. In practice, teams set the Read Only field directly on Shopping_Cart_Item__c through automation, data operations, or controlled integration logic.
Use one of these setup approaches:
Record-triggered Flow
Use record-triggered Flow when the lock should be applied automatically based on cart-item conditions.
This is the most common option for admin-managed rollout.
Typical pattern:
- Create a record-triggered Flow on Shopping_Cart_Item__c.
- Use an after-save trigger context so the cart item already exists.
- Add entry criteria that identify lines you want to protect.
- Update Read Only to true.
- Activate the Flow and test it with representative cart scenarios.
Use this when the business rule depends on product type, SKU, bundle membership, fee logic, approval state, or another cart-item condition that admins can maintain declaratively.
Data operations
Use data operations when you need to lock existing cart items in bulk.
Examples include:
- seeding carts for demos or testing
- migration or cleanup activities
- controlled back-office maintenance on existing cart records
Common tools include Data Loader, import jobs, and governed admin updates on cart-item records.
Controlled integration or Apex logic
Use controlled integration logic when protected lines are created or maintained by server-side automation.
This is appropriate when:
- a custom add-to-cart process creates a protected line from the start
- an integration needs to maintain a system-managed line after the buyer lock is in place
- partner-built automation governs when protected rows are added, updated, or relocked
For this path, keep the implementation aligned with the published ShoppingCartApi and read-only developer guidance rather than building custom storefront bypass behavior.
Rollout guidance
Before you enable read-only behavior broadly, define which rows should be locked and why.
Good candidates include:
- approval-controlled bundles that buyers should not break apart in the cart
- automatically added service or compliance lines
- protected products whose quantity or options should not be changed after selection
- summary or derived rows that support pricing, fee, or service calculations
Avoid using read-only mode as a substitute for general cart validation. It is best used for clearly governed rows where the business wants visible but restricted behavior.
Controlled programmatic update scenarios
Read-only behavior is intentionally different for buyer-driven storefront actions and for controlled server-side maintenance.
Standard storefront controller flows continue to enforce the lock for interactive buyer actions.
At the same time, supported programmatic update paths can be designed to maintain a read-only line intentionally. This is how integrations or governed automation can still update protected rows without reopening them to normal buyer editing.
For admins and implementation partners, the practical rule is:
- use the Read Only field to lock the buyer experience
- use controlled integration or Apex maintenance only when the business explicitly needs managed updates behind the scenes
- do not treat programmatic maintenance as a general buyer bypass
If your rollout needs that controlled maintenance path, document the ownership clearly between admin automation and developer-owned integration logic.
Validate the buyer experience after rollout
Use this checklist after you enable the field through Flow, data operations, or integration logic:
- Add or identify a cart line that should become read-only.
- Confirm that Read Only is set to true on the related Shopping_Cart_Item__c record.
- Open the storefront cart as a buyer and verify that the line is still visible.
- Verify that the standard quantity control is no longer editable for that row.
- If the row supports addons, verify that the standard addon-edit flow is not available for the locked item.
- If the protected row creates grouped child rows or addon rows, verify that those generated child rows also follow the locked state.
- If you rely on controlled automation or integration updates, verify that those governed updates still work as designed.
- Test any custom cart actions or custom cart-row extensions that your storefront uses, especially if they do not rely on the standard cart controllers.
Troubleshooting
The item is still editable in the storefront
Check whether the Read Only field is actually being set on the final Shopping_Cart_Item__c record and whether another automation later clears or overwrites it.
Also confirm that the buyer is using the standard storefront cart interaction path. Custom cart actions or custom components may need their own read-only handling.
The wrong lines are being locked
Review the Flow criteria, import mapping, or integration logic that sets Read Only. Read-only cart items work best when the rule is narrow and predictable.
Child rows are not behaving as expected
Verify that the parent line is the row receiving the lock and that the child rows are generated from that protected parent. Grouped and addon child rows inherit the state from the parent lock during the cart workflow.
A background process needs to update the locked line
Use a governed API or integration path that is intended for programmatic maintenance of read-only items. Do not try to re-enable normal buyer editing just to let automation complete.
Remove behavior needs special handling
Validate remove behavior in your own storefront implementation, especially if you use custom row actions or custom cart components. Standard read-only rollout should focus first on the supported interactive edit flows that are clearly enforced in the storefront and controller layer.