Skip to main content

Do not change catalog availability

:::warning Catalog availability changes are blocked Do not change a category, subcategory, or product switch in Business App. Current evidence does not establish that every product update is restricted to the selected business, so this guidance cannot provide a safe availability-change procedure. :::

The Categories and Products views can show catalog state, but a visible item, switch, success message, or changed local state is not enough evidence to proceed. Do not use a category change as a workaround for the blocked product path.

Before you start​

  • Do not test a catalog switch with a real business, category, subcategory, or product.
  • Do not retry an earlier availability change from this guidance.
  • Keep the intended project and business visible when recording a problem.
  • Use only the minimum catalog information required by your administrator or support process.

Record the visible state safely​

  1. Stay on the current Categories or Products view. Do not select a switch.
  2. Refresh or reopen the business once and wait for loading to finish.
  3. Record the business name, the category or product name, and whether the returned switch appears on or off.
  4. Record any visible Network Error, Sorry, no results found, Enabled category, Disabled category, Enabled product, or Disabled product message from an earlier attempt.
  5. Escalate to the administrator responsible for the project or to Ordering support. State that you did not change or retry the item.

Do not copy internal identifiers, customer details, prices, or other catalog data that your approved support process does not require.

If a change was already attempted​

  • Do not select the switch again, even if it appears to return to its previous state.
  • Refresh or reopen the same business once and record the newly returned state.
  • Treat a success message without a matching fresh read as an unknown result.
  • If several items were changed, record each item separately. The requests are not one atomic catalog operation, and one success does not establish another item's result.
  • Escalate the unknown or partial result to the project administrator or Ordering support.

Why changes remain blocked​

  • The available product-update evidence checks access to a supplied business and checks the product/category pair, but it does not visibly establish that the category belongs to that same business.
  • Category updates have a narrower source-scoped business and ownership check, but that does not make the unresolved product path safe or provide a supported workaround.
  • Category and product switches can remain interactive while a write is unresolved, and separate requests can finish independently.
  • A message, switch movement, or local merge does not prove deployed authorization, customer propagation, atomic completion, or a safe retry.
  • The relationship between the documented source and the deployed app and API is not established.

These are safety boundaries, not instructions for bypassing access controls or changing availability through another tool.

When operational steps can return​

Catalog availability steps can be restored only after all of these conditions are met:

  1. A corrected, pinned API establishes that a product's category belongs to the same business that the actor is authorized to manage.
  2. Positive authorization tests prove an allowed same-business update, and negative tests reject cross-business and unowned targets.
  3. Category, subcategory, and product client/API behavior is retraced at those accepted versions, including error, stale, partial, and repeat-attempt handling.
  4. An independent safety review accepts the revised public procedure and any required synthetic runtime evidence.

Until then, do not use this article to change catalog availability.

Availability and limits​

  • The catalog can display categories, nested subcategories, products, searches, and enabled switches. Visibility is not update authorization or freshness proof.
  • Category search uses returned category and subcategory names. Product search and pagination depend on a server response.
  • Enabled state is only one customer-availability input. Business, category, product, menu, schedule, snooze, inventory, and other rules can still affect customer ordering.
  • No bulk, atomic, rollback, ordered-completion, realtime, deployment, entitlement, or immediate customer-visibility guarantee is admitted.

:::note Visual status Visual guidance is deferred. Reopen trigger: authorized synthetic capture of the exact business-to-Categories entry, category search populated and empty/error states, collapsed and expanded category/subcategory hierarchy, category and subcategory enabled/disabled plus success/error/stale states, Products overlay, product search/loading/pagination/empty/error states, product enabled/disabled plus success/error/stale states, sequential and out-of-order mutation observations, phone and tablet coverage, exact asset allowlist, accepted W4 fixture/effect/cleanup receipt, redaction, and independent visual QA. :::