{"title":"Package v21.8 to v21.12 - 28 August 2026","slug":"package-v21-12","url":"https://support.storeconnect.com/articles/package-v21-12","url_markdown":"https://support.storeconnect.com/articles/package-v21-12.md","subtitle":null,"summary":"Package releases v21.8 to v21.12 add AI agent access to a store from the StoreConnect Console, a Content Changes review area with a storefront preview link, the Audit Log, a fraud review queue on orders, automatic handling of duplicate account and contact sync errors, and a rebuilt New Theme Asset form. They also fix an install failure that made v21.7 to v21.10 uninstallable.","type":"Release_Notes","video_url":"","keywords":"v21, release notes, package, AI agent, MCP, agent access, API token, API scopes, content changes, preview URL, audit log, risk review, fraud review queue, duplicate accounts, sync errors, theme asset, points, change events","last_modified":"2026-09-15T02:32:04+0000","body_markdown":"These package releases bring the Salesforce side of two significant platform features. AI agents can now be connected to a store from the StoreConnect Console, with per-user access tokens and scoped permissions, and everything an agent stages is reviewed and approved as a content change before it reaches the live site. The Audit Log arrives as a new object with its own tab, list views, and per-store retention settings, alongside a fraud review queue on orders. Sync also gets a substantial upgrade: duplicate account and contact errors can now heal themselves, repolls run around a third faster, and a layout problem that made v21.7 to v21.10 impossible to install is fixed.\n\n## Breaking changes and cautions\n\n:::warning\n**Package versions v21.7.0 to v21.10.0 cannot be installed**\n\nEvery package version from v21.7.0 through v21.10.0 fails to install or upgrade with the error `Layout(Query__c-SC Query Layout): In field: excludeButtons, no such standard action: SmartFillEnrich`. The **SC Query Layout** hid a Salesforce button that only exists in orgs where an optional Salesforce enrichment feature is switched on, so in every other org the layout was rejected and the install stopped before anything was applied.\n\nUpgrade directly to **v21.11.0 or later**. Do not attempt an install or upgrade to v21.7.0, v21.8.0, v21.9.0, or v21.10.0. Versions up to v21.6.0 predate the layout and are unaffected. [PKG-9526]\n:::\n\n:::warning\n**Sync errors caused by duplicate rules are no longer retried automatically**\n\nBefore this release, a change event blocked by a Salesforce duplicate rule sat in the sync error list until someone fixed it, while the automatic retry schedule kept picking it up and failing it again. These errors are now marked permanent and left out of automatic retry, because a retry cannot succeed while the duplicate rule still matches. This is one part of the new duplicate handling described under Enhancements, which can resolve these errors for you once you turn it on.\n\nIf you leave the new handling off, resolve the underlying duplicate, then retry the record manually from the [sync error tool](how-to-find-and-resolve-sync-errors). If you have monitoring that expected these errors to clear on their own, update it to treat them as needing attention. [PKG-9204]\n:::\n\n:::warning\n**Audit Log defaults to Standard and starts recording on install**\n\nThe new **Audit Log** object ships with an org-wide default level of `Standard`. On a connected org, three event types are recorded from the Salesforce side straight away: a contact's email address changing, an invitation being sent, and a password reset being requested. The website tier that generates the remaining events is not part of the v21 website line, so those begin accumulating as soon as your website is upgraded to a release that emits them.\n\nBefore that upgrade, review the three new fields on the **Store** record: **Audit Log Level** (`Off`, `Essential`, `Standard`, `Verbose`), **Audit Log Categories** (blank records every category), and **Audit Log Retention (Days)**. Console users also need the new **StoreConnect Audit Viewer** permission set assigned before they can see any audit records. [PKG-8966]\n:::\n\n## Enhancements\n\n**Manage AI agent access from the Console**\n\nAgent access is managed from a new **Agents** menu in the [StoreConnect Console](about-the-storeconnect-console) header, with two entries.\n\n**Manage agent access** is for administrators. It lists everyone who holds a content changes **Store User Role**, along with anyone who already has access or a token, and lets you enable or disable agent access per person, set an optional expiry date, and reset a token. Each row shows how many stores the person can reach, and opening that count shows each store with the role level and whether it came from a direct store role, a store group, or an all-stores role. A store filter narrows the list to one store. Enabling access for someone else also needs the Salesforce **Manage Internal Users** permission; without it the Console refuses and names the permission.\n\n**Connect an agent** is for the person using the agent. It shows their own access state, the stores they can reach, the connection address, and their personal token to copy, with step-by-step instructions for Claude Code, Claude on web and desktop, and any other client that speaks MCP over HTTP.\n\nBehind the scenes, three new fields on the Salesforce **User** record hold this: **API Token**, **API Token Active**, and **API Token Expires At**. You do not need to add them to a page layout, because the Console covers every action. Disabling access clears the stored token, and so does deactivating the Salesforce user. Enabling again issues a new token, so re-enabling a person means handing them a fresh token rather than restoring the old one. [PKG-9340]\n\n**Choose exactly what an agent is allowed to do**\n\nA new **API Scopes** field on the **Store Role** record sets what a person holding that role can do through the website API, with reads and writes granted separately and anything not selected denied. The available scopes cover content, catalog, themes, store settings, carts, checkout, contacts, accounts, payment methods, subscriptions, site extraction, publishing staged changes, and publishing your own changes.\n\nOn upgrade, any existing editor-level content changes role with no scopes set receives a default bundle: content, catalog, and themes read and write, publish staged changes, store read, and site extraction read. Roles that already have scopes, and approver-level roles, are left as they are. A new install seeds **Content Editor** and **Content Approver** roles with the same bundle. [PKG-9340]\n\n**Review and approve staged changes in the Console**\n\nThe Console gains a **Content changes** area for working through changes an agent or editor has staged, with a list of outstanding changes and a detailed view of what each one touches. The Console home page now shows a dashboard matched to the viewer's role, so an administrator, approver, content manager, order manager, or theme manager each land on the work relevant to them. [PKG-9340]\n\n**One-click storefront preview on a content change**\n\n**Content Change** records gain a **Preview URL** field that opens the staged edits on the storefront, so an approver can see the change in context before approving it. A companion **Origin Store** field records which store the change was authored against, and the preview link uses that store's own domain. Changes with no origin store fall back to the org-wide `Site_Base_URL` setting, and the link renders blank rather than pointing at a placeholder domain when neither is set. [PKG-9340]\n\n**Publishing a content change needs a second person, unless the role allows self-publishing**\n\nOnly someone holding an approver-level **Store User Role** for content changes can publish a content change, and by default that person cannot also be the change's author, so a second person is needed. The **Publish Own Changes** API scope lifts the author restriction for a role, letting one person stage and publish their own changes. It is granted to no role out of the box, and the package upgrade does not add it to existing roles. Every content change carries a **User**, so the author check applies whether the change was staged by an agent, through the API, or by hand.\n\nBoth checks are made against the change's **Origin Store**, so a role scoped to one store satisfies them for that store's changes. A change with no origin store needs a role that covers all stores.\n\nTo set up a reviewer, assign the new **StoreConnect Content Change Approver** permission set. It lets the reviewer edit a **Content Change**, including its **Status**, and gives read-only access to the records a change stages, so they can judge a change without edit rights on the underlying records. It does not let them create or delete content changes. Publishing still needs the approver-level **Store User Role** as well, so assign both to anyone who publishes. [PKG-9340]\n\n**Many more record types can be staged as a content change**\n\nThe staged draft-to-publish pipeline now covers products, prices, product variants, product images, product categories and product-to-category memberships, category nesting, article categories and article-to-category links, theme variables, and theme assets, alongside the pages, articles, content blocks, menus, menu items, media, themes, theme templates, and store records it already handled. Records are applied parents-first, so a new product and the new category it belongs to can be staged together in a single change. [PKG-9340]\n\n**Custom templates for content blocks**\n\nThe **Content Template** picklist on **Content Block** gains three values: `featured_category_products` and `video`, which were already shipped as storefront block templates but missing from the list, and `custom`. Selecting `custom` tells the storefront to render the theme snippet named in the new **Custom Template** field, as `blocks/\u003ckey\u003e`, which is how agent-authored and hand-built section templates are stored. [PKG-9340]\n\n**Audit Log**\n\nA new **Audit Log** object records security-relevant activity across your store, with its own tab, an entry in the StoreConnect Console, and a read-only record page. Twenty-one event types ship in the catalog, covering sign in, sign out, failed logins, signup, password changes and resets, invitations, email changes, payment attempts, successes and failures, POS register logins and shift start and end, and fraud screening decisions. Sign out is recorded at `INFO` severity, so the default `Standard` level does not capture it. Set the level to `Verbose` if you need sign-out events.\n\nEach record captures who acted, what happened, the outcome, severity, and a sub-second timestamp, and links back to the related account, contact, store, order, cart, payment, register, register shift, or outlet. The **IP Address** and **User Agent** fields exist for website-sourced events, so they stay blank on the events Salesforce records itself.\n\nThree ready-made list views cover recent security events, failed logins, and failed payments, and **Audit Logs** related lists appear on Account, Contact, Store, Order, Cart, Payment, Register, and Outlet. The object is append-only. The sync user can create records but not edit or delete them. Read access is granted through the new **StoreConnect Audit Viewer** permission set, which the **StoreConnect Administrator** permission set does not include.\n\nRetention is set per event type, from 90 days for sign-ins to about seven years for payment and risk screening events, and a scheduled purge removes records once it has elapsed. On the **Store** record, **Audit Log Level** replaces the org-wide default for that store, whether that means recording more or recording less, **Audit Log Categories** records every category when left blank, and **Audit Log Retention (Days)** can only extend retention, never shorten it. [PKG-8966]\n\n**Fraud review queue on orders**\n\nOrders gain a **Risk Review** field with three values, `Pending Review`, `Released`, and `Rejected`, for holding an order that fraud screening has flagged. The storefront sets `Pending Review` only on a website release that runs risk screening, which is not part of the v21 website line, so the queue stays empty until your website is upgraded. You can set the field by hand in the meantime. A new **Fraud Review Queue** list view on Order shows everything sitting at `Pending Review` with the order number, risk review state, status, customer email, store, total, and submitted date. Set an order to `Released` to fulfill it normally, or `Rejected` before canceling or refunding it. [PKG-8966]\n\n**Duplicate account and contact sync errors can now heal themselves**\n\nWhen a Salesforce duplicate rule blocks a record from your store, the failed change event now records exactly which rule fired, how many records matched, and which ones, so you can see the cause without reproducing the error. Four new org-wide `Setup_Configuration__c` records control what happens next, and all four are off by default:\n\n- `sc_sync_duplicate_resolution` set to `attach_quarantined` claims the incoming store record onto the best matching Salesforce account or contact, which is the automated version of the manual remedy in [Resolve duplicate account sync errors](resolve-duplicate-account-sync-errors). A matched record that already belongs to another store record stays failed and asks for a manual merge.\n- `sc_sync_duplicate_min_confidence` sets a minimum match confidence from 0 to 100 before a match is claimed. Set a floor before turning attachment on, because 0 accepts unscored matches.\n- `sc_sync_duplicate_allow_save` saves through duplicate rules whose action is Alert rather than Block, restoring the rule's own \"save anyway\" behavior for machine-driven saves. This applies org-wide to every synced object. Rules whose action is Block still reject the record, and those failures are still captured and, if attachment is on, resolved by it.\n- `sc_sync_duplicate_rule_mirroring` publishes your active Account matching rules to the store as a store variable. The website release that reads it is not part of the v21 website line, so on v21.0.15 the storefront keeps its built-in matching and this setting has no visible effect yet.\n\nPerson accounts are not yet supported by any of these options. [PKG-9204, PKG-9456]\n\n**Rebuilt New Theme Asset form**\n\nThe **New Theme Asset** form is rebuilt on the current Lightning interface, with a drag-and-drop box, a card showing the chosen file's name and size, and Save, Save \u0026 New, and Cancel. The most useful change is that the file now uploads when you save rather than the moment you pick it, so abandoning the form no longer leaves stranded files in cloud storage. Opening the form from a specific theme's related list pre-fills and locks the **Theme**, and Save \u0026 New keeps the theme selected so you can add several [theme assets](theme-assets) in a row. Files over 5 GB are rejected immediately. The **Theme Asset** record page now uses a cleaner single-column layout. [PKG-9235]\n\n**Faster syncing**\n\nA full repoll of a large object is around a third faster: 100,000 accounts now take about nine minutes instead of fourteen. Archiving of processed change events also moves from a scheduled batch job to per-event background jobs, so archiving starts sooner and events are no longer left stranded when a new one arrives while a batch is mid-run. A nightly sweep still runs as a backstop. [PKG-9576, SGM-9530]\n\n**Points total on an order line**\n\n**Order Product** records gain a **Total Points Amount** field holding the points used to buy the whole line rather than a per-unit figure, so a points discount that does not divide evenly across the quantity stays exact. The field is read-only for the StoreConnect Administrator and Order Manager permission sets. [PKG-9559]\n\n## Deprecated fields\n\nNo fields are removed or deprecated in these releases.\n\n## Fixed bugs\n\n**Installs and upgrades failed outright on the Query page layout**\n\nA single stale line on the **SC Query Layout** hid a Salesforce button that does not exist in most orgs, and Salesforce rejected the whole layout, which stopped the install before anything else was applied. The reference is removed, and every other layout in the package was checked for the same problem. Nothing changes on the Query record page for customers, because the button was never there to begin with. [PKG-9526]\n\n**Unhandled exception emails when a new store connects**\n\nConnecting a new store sent Salesforce administrators an unhandled-exception alert reading \"Failed to process batch: Attempt to de-reference a null object\". The store asks Salesforce to refresh every kind of record it keeps in sync, and a few names on that list have no Salesforce equivalent, so the lookup returned nothing and the background job crashed. Nothing was ever lost, but the alerts landed in the customer's own exception inbox and looked exactly like a real sync failure. Names that do not exist in the org are now skipped before a job is started. [PKG-8706]\n\n**Cascading deletes failed with a \"more than 10 chunks\" error**\n\nDeleting a record that cascades to several related record types, such as an order and its order items, could fail with `System.TypeException: Cannot have more than 10 chunks in a single operation`, with as few as eleven records involved. Salesforce starts a new chunk each time the record type changes in a delete, and allows only ten. Deletes are now grouped by record type before being sent, so this limit is no longer reached. [SYS-9403]\n\n**Attaching a duplicate contact could break the customer's login**\n\nWhen the new attachment option claimed an incoming store record onto an existing Salesforce contact, the round trip back to the store overwrote store-side details the Salesforce record had never held, including the store the contact belongs to and their username. The customer could no longer sign in immediately after an otherwise successful automatic fix. The claim now copies those details from the failed record onto the matched record, filling only fields that are blank, so existing Salesforce data is never overwritten. [PKG-9456]"}