Why this setup is critical

Product setup is your catalog foundation. If product families, attribute groups, and product fields are inconsistent, teams create duplicate data, miss required content, and publish incorrect records to channels.

• Design your structure before bulk imports and partner sharing.
• Treat model/group/field design as source-of-truth architecture, not UI configuration.
• Lock naming conventions early to avoid migration and retraining costs.

Dedicated deep dive guides

Use these standalone guides when you need implementation-level details for each setup layer.

• Product Families (Product Models): /help/product-families
• Attribute Groups: /help/attribute-groups
• Product Fields: /help/product-fields

Organization baseline

Organization settings stores identity metadata used across workspace UI, sharing, and recipient-facing touchpoints.

• Set organization name, website, and description to align internal and external references.
• Upload logo with validated format and size so shared pages and workspace shell render correctly.

Product families (configured as Product Models)

In Stackcess, product families are configured using Product Models. A model should represent one repeatable product architecture with consistent required data and variant logic.

• Create a separate family/model when required fields or variant axes are meaningfully different (example: apparel vs appliances).
• Avoid creating too many families; prefer one model per true structural pattern, not per campaign or season.
• Define whether the family is typically standalone, parent/variant, or mixed before users start creating products.
• Use clear model names tied to operational ownership (example: Footwear Core, Hardgoods Core).
• Validate model coverage with real sample SKUs before broad rollout.

Attribute group design

Attribute groups control how the product editor is segmented. Good grouping improves completion speed, review quality, and onboarding for new users.

• Group by workflow intent: merchandising, compliance, logistics, digital merchandising, channel overrides.
• Keep group names task-oriented so users know where to edit without searching.
• Place high-frequency fields in early groups and low-frequency or specialist fields later.
• Use stable groups across families where possible to reduce context switching for editors.
• Respect locked/system groups (example: basic info, documentation) and design around them instead of duplicating fields.

Product fields (attribute schema) deep guide

Product fields define your data contract. Every field should have a clear owner, validation rule, and publishing purpose.

• Use the narrowest field type that fits the requirement (identifier, measurement, select, media, table, boolean, text).
• Mark fields as required only when missing values should block completion or publishing.
• Apply uniqueness only to true business identifiers (for example global or family-level SKU rules).
• Enable localization only for content that actually changes by locale; avoid localizing technical fields.
• For select-like fields, define controlled value lists and governance for adding new options.
• Write field descriptions and examples so users understand expected format and business meaning.
• Separate canonical source fields from computed or downstream export-only fields.

Scope, localization, and channel rules

Field-level scope settings determine where data can be edited and published. This is essential for multi-market and multi-channel operations.

• Restrict fields to relevant channels/markets/locales when values should differ by endpoint.
• Keep global master data fields scope-agnostic where possible to reduce maintenance.
• Use channel-aware fields for requirements that are truly destination-specific (example: marketplace bullets).
• Test one sample product across at least two market/channel scopes before launch.
• Document fallback behavior for missing scoped values to avoid silent publish failures.

Recommended setup sequence

Follow this sequence to reduce rework and keep data migration risk low.

1. Confirm business outcomes and channel requirements for each product family.
2. Create Product Models (families) and define variant strategy for each.
3. Create Attribute Groups in the intended editor order.
4. Create Product Fields with final type, required/unique rules, and descriptions.
5. Attach fields to groups and validate section flow in product detail screens.
6. Configure market/channel/locale restrictions for scoped fields.
7. Create sample products and run completeness QA with real users.
8. Freeze architecture, then begin import/migration and team training.

Governance after go-live

Post-launch changes to families, groups, and fields should follow change control to prevent catalog regressions.

• Require admin review for field type changes and required-flag changes.
• Version and document schema decisions before changing live models.
• Run impact checks on integrations, exports, and validation workflows before release.
• Prefer additive changes first; deprecate old fields before hard removal.
• Schedule recurring audits for unused fields, duplicate fields, and low-quality values.