Independent engineering field guide
Build deeper.
Connect better.
The GCG Znode Developer Center. Practical recipes, code patterns, and architecture decisions for teams building complex B2B commerce.
From your next attribute migration to your next platform generation.
Start with a recipe
A field, from database to experience.
Follow one concrete task through the details that make it work.
Find your next answer.
Browse 42 guides and recipes. Every resource includes version guidance and practical implementation details.
42 resources
Where should custom data live in Znode 10?
Choose between entity attributes, Custom Tables, and project-owned relational storage by examining ownership, relationships, and concurrent writes.
Znode 9 to 10: migrate behavior before translating classes
Turn legacy customization code into explicit behaviors, then rebuild and verify one complete journey across the target platform.
Build a Znode 10 Page Builder widget for preview and storefront
Design a small technical-resources widget around one saved contract, then verify editing, rendering, links, and existing content in both applications.
Fix out-of-order cart updates before they corrupt the UI
Keep an older quantity response from erasing a newer validation error, and distinguish UI sequencing from server-side write ordering.
Account switching: preserve the actor and change the buying context
Separate the authenticated person from the account they are shopping for, and authorize each switch using current server-owned relationships.
Reliable ERP order delivery: retries, idempotency, and replay
Separate order acceptance from external delivery, then handle uncertain responses with durable state, stable identity, and controlled reconciliation.
Znode 9 quote edits: invalidate shipping and totals correctly
Model shipping and totals as derived state, then invalidate them in the correct order after quote lines or delivery inputs change.
Customer-specific pricing: choose the source of truth before the cache
Define who owns a price and every dimension that changes it before adding caching or fallback behavior across Znode and an ERP.
Repeatable Znode test data: stable keys, readback, and no-op reruns
Build fixtures that converge on an explicit desired state without duplicating records or overwriting values owned by administrators.
Keep the in-stock filter aligned with inventory updates
Trace inventory from its authoritative source into search and storefront projections so the in-stock filter does not contradict product availability.
Package quantities and order types without inconsistent cart rules
Express package rules as one server-owned decision and apply it consistently when products, quantities, and order types change.
Address recommendations without breaking checkout state
Treat address validation as a suggestion workflow with explicit user choices, stale-response protection, and controlled persistence.
Native account price lists: verify the association and the storefront
Use distinctive fictional prices to follow an account price-list association from configuration into an authenticated product page and cart.
Route store integrations using trusted configuration
Select integration providers from server-owned store configuration and keep caller input from choosing external destinations or handlers.
Why saved content differs between Page Builder and the storefront
Follow a content change through saved configuration, publication, theme resolution, and application caches before changing the component.
Mobile product filters that work with a keyboard
Design mobile filters as a complete interaction, including focus, draft selections, result updates, and a reliable path back to the product list.
Theme overrides without changing another store's behavior
Keep theme-specific rendering and behavior behind explicit boundaries so shared packages do not silently alter unrelated stores.
Show the difference between order acceptance and ERP completion
Give buyers and operators an accurate delivery timeline without exposing integration payloads or implying that commerce acceptance proves ERP completion.
Diagnose a product-listing slowdown before changing caches
Measure the product-listing request as a chain of work, then change the slowest proven stage instead of treating cache changes as a default fix.
Quick order that handles invalid and unavailable products clearly
Treat each uploaded or pasted quick-order row as its own validated outcome, while preserving the buyer's valid work and explaining what needs correction.
Data Exchanges or a legacy ERP touchpoint: choose the right starting point
Start by naming the integration problem, then verify the current supported mechanism in a sandbox before committing to implementation structure.
Connect an external product or artwork workflow without duplicating state
Give every product and artwork fact one owner, exchange stable references and lifecycle events, and make the customer-facing state explicit.
Plan payment initialization across guest and account checkout
Treat payment initialization as a server-controlled state transition, with explicit guest, account, amount, currency, and provider-session boundaries.
Read ERP order history through a bounded account-aware adapter
Use a project-owned order-history contract that derives account scope on the server, enforces bounded paging, and keeps ERP wire details outside the storefront.
Custom Table no-data responses and duplicate keys
Normalize a fixed-table response at one typed boundary, distinguish no data from malformed data, and reject duplicate rows for a key that should be unique.
Recover from a timed-out write without creating duplicates
Treat timeout as an unknown outcome. Reconcile an exact committed result, keep absent readback pending, and escalate ambiguity without issuing another write.
Plan a coordinated Custom API, data, and storefront release
Release a vertical slice in dependency order, with compatible states during rollout and a rehearsed recovery path for API, data, and storefront changes.
Build a Znode 9 upgrade inventory before touching packages
Inventory behavior, ownership, extension seams, dependencies, and acceptance evidence before choosing an upgrade path or changing packages.
Test configurable products and add-ons with real published fixtures
Build a small synthetic catalog fixture whose published product, option, add-on, price, inventory, and storefront behavior can be read back and tested.
Expose useful diagnostics without exposing integration secrets
Provide authenticated, bounded dependency status and correlation evidence while redacting credentials, destinations, payloads, and personal or commercial data.
Create a Store global attribute with a SQL migration in Znode 9
Create a fictional support-label attribute, connect it to an existing Store group and family, and make reruns safe without overwriting an administrator's label or Store values.
Plan a Znode 9 product attribute migration without confusing it with a Store attribute
A product attribute belongs to PIM metadata and a product record. It is not a renamed Store global-attribute migration. Use a read-only schema map first, then build and test a version-pinned migration in a disposable database.
Diagnose a missing Store global attribute through group and family mappings
Trace one Store global attribute through its definition, localized label, group, family, and entity mappings. Keep this diagnostic separate from product PIM metadata.
Separate dropdown options from localized attribute labels
A translated field label, a dropdown option, and a product's chosen value are separate records. Model them separately to prevent incorrect language and option behavior.
Read a Store attribute through a typed adapter
Resolve the current Store context once, read attributes through a small boundary, and parse the expected code into a typed value. Do not spread portal IDs or string lookups through application code.
Render a product attribute safely in a Znode 9 Razor view
Select the value in the view model, handle absence, and let Razor encode untrusted text. Verify the data appears after the declared publication path.
Design a service override and plan its registration
Add behavior behind a narrow interface, register it in the supported composition root, and verify the resolved service. Avoid a broad replacement whose scope is unknown.
Design a bounded Znode 10 Custom API endpoint
Build a small preference read with authenticated server context, ownership-aware caching, bounded output, and an adapter registered through the selected Custom API SDK.
Add a database migration and know when DbUp runs it
Use a migration journal for one-time data changes and a separate repeatable path for programmability. Understand how your runner chooses which scripts execute.
Trace one Znode 9 request from browser to service
Trace a single synthetic request through browser, controller, agent, client, API, and service boundaries. Follow evidence, not class names or assumptions.
Localize widget interface text without confusing it with editor content
Interface text belongs in the application's translation catalog; author-entered widget content belongs in widget configuration. Keep both visible in preview and storefront tests.
Validate a paged API request with bounded filters and server-owned context
Validate a small paging request at runtime, reject unsupported filters, and pass only reconstructed allowed fields to an SDK adapter. The actual API read needs a declared target endpoint.
No resources matched.
Try a broader search or clear your filters.
Original code examples use fictional data and explain the dependencies, version scope, and application boundaries needed to put each pattern to work.
Looking for delivery help? Explore GCG's Znode services. For wider business perspectives, read our Insights.
Independent resources from GCG. Znode is a trademark of its owner. This library complements the official documentation.
Znode 9 to 10: migrate behavior before translating classes
Turn legacy customization code into explicit behaviors, then rebuild and verify one complete journey across the target platform.
Build a Znode 9 upgrade inventory before touching packages
Inventory behavior, ownership, extension seams, dependencies, and acceptance evidence before choosing an upgrade path or changing packages.
Design a service override and plan its registration
Add behavior behind a narrow interface, register it in the supported composition root, and verify the resolved service. Avoid a broad replacement whose scope is unknown.
Trace one Znode 9 request from browser to service
Trace a single synthetic request through browser, controller, agent, client, API, and service boundaries. Follow evidence, not class names or assumptions.