Executive summary
- What changed: The MetaobjectAdminAccess enum no longer treats PRIVATE and PUBLIC_READ as supported values. Both are deprecated with a removal date, and the API has stopped returning them.
- Why it happened: The two values stopped describing real access behaviour. Code that branched on them was reasoning about states the platform can no longer produce, which is a quiet source of permission bugs.
- Who should care: Any team that creates or reads metaobject definitions programmatically, including custom apps, data migration scripts, and content modelling tooling built during a replatform.
What changed
MetaobjectAdminAccess controls who can read and write the entries behind a metaobject definition. The supported set is now three values: MERCHANT_READ, where the merchant has read-only access and no other app has access, MERCHANT_READ_WRITE, where the merchant can read and write and no other app has access, and PUBLIC_READ_WRITE, where the merchant and other apps can both read and write. App-owned metaobjects are a separate case: the owning app always retains full access regardless of the value set here.
Both deprecated values still appear in the schema with a removal date attached. Shopify states no changes are required, which is true for read paths because the API already declines to return either value. The write path is the part worth noting: once the values are removed in 2027-01, a mutation sending one stops being a no-op and becomes a validation error.
Why it matters
On a Shopify Plus build, metaobjects carry the content merchandising depends on: specification sheets, size charts, ingredient panels, store locators, B2B tier descriptors. Those definitions are usually created once during implementation, so the access value sits in code nobody has opened in two years.
That is the profile of a change that is trivial now and expensive later. Acting today costs a grep and a short pull request. Acting after a version bump costs a failed deploy during a release window, usually discovered by a content editor who cannot publish. Treat the removal date as the deadline, not the moment the symptom appears. Teams running a mature Shopify development practice fold these into a standing version-upgrade checklist rather than handling them as incidents.
Role-specific impact
- Marketers: No visible impact. Metaobject entries, their fields, and the storefront output stay exactly as they are. There is nothing to review in the content calendar.
- Developers: Search the codebase for the two literals, including GraphQL documents, fixtures, seed scripts, and anything held in a shared schema package. Replace PRIVATE with MERCHANT_READ_WRITE or MERCHANT_READ depending on whether the merchant should edit entries, and replace PUBLIC_READ with PUBLIC_READ_WRITE only when other apps genuinely need write access.
- Store admins: Nothing to toggle in the admin. If an internal tool or a partner app starts reporting permission errors after a version upgrade, this deprecation is a reasonable first thing to raise with whoever maintains it.
Use-case example
Real-world scenario
A manufacturer running roughly 14,000 SKUs models product specifications as metaobjects, created in bulk by a migration script written during the original Magento cutover. The script sets admin access to PRIVATE on every definition. Nothing has failed, because the script has not run since launch. The team now plans a catalogue expansion and intends to re-run it against the 2027-01 version. Fixing two literals today is a one hour change across roughly 30 lines. Discovering it mid-expansion means a blocked bulk import and a day of unplanned work against a committed launch date.
Implementation checklist
- Grep every repository and shared GraphQL package for PRIVATE and PUBLIC_READ, scoped to metaobject definition mutations so you do not chase unrelated matches.
- For each match, decide the intended behaviour: merchant editing, merchant read-only, or shared app write access.
- Map the value accordingly, to MERCHANT_READ_WRITE, MERCHANT_READ, or PUBLIC_READ_WRITE.
- Run the updated mutations against the 2027-01 release candidate in a development store and confirm they validate.
- Record the change in your API version upgrade notes so the next person reviewing access does not reintroduce the old literals.
- Re-check any partner or internal app that provisions metaobject definitions on your behalf, since the same literals often live outside your own codebase.
FAQ
- Q: Will anything break before the 2027-01 version?
- A: No. Reads already exclude both values and existing definitions keep working. The risk arrives when you pin a version where the enum values no longer exist and a write path still sends one.
- Q: How do we choose a replacement value safely?
- A: Start from who must edit the entries. If only the merchant needs write access, use MERCHANT_READ_WRITE. If the merchant should not change entries, use MERCHANT_READ. Reserve PUBLIC_READ_WRITE for definitions another app is genuinely expected to write to, since it is broader than the old PUBLIC_READ.
Resources
MetaobjectAdminAccess enum reference
Need guidance? Talk to Makro.