How collections work

Documentation
, , ,
1

How collections work

This guide explains how to design reusable collections for predictable deployments across projects and teams.

Required access: Any customer account with collection access.

When to use collections

Use collections when you repeatedly install similar stacks across different websites or clients.

How to create a collection

  1. Open Collections in your dashboard.
  2. Create a collection name by project, client, or use case.
  3. Add products from listings or product pages.
  4. Save and verify product list is complete.

How to operationalize collections

  1. Use consistent naming (for example: ClientName-Stack-v1).
  2. Keep one “base stack” collection and one “extended stack” collection.
  3. Use collections during bulk deployment workflows.
  4. Review collections monthly and remove obsolete items.

Verification checklist

Confirm:

  • Collection name clearly communicates use case
  • All required products are present
  • Team members can reproduce the same setup
  • Collection aligns with current plan access

What happens after organizing collections

  • Team workflows become faster and more consistent.
  • Bulk actions can be prepared with less manual selection.
  • You can keep maintenance stacks ready for recurring work.

Troubleshooting

If products are missing from a collection workflow, verify current plan access for those products.

Related guides

  • How to bulk download and install products

Exact route paths

  • /dashboard/bookmarks
  • /dashboard/bookmarks/[id]

Expected UI state after each step

  • Step 1: Bookmarks/collections list loads existing collections.
  • Step 2: New collection is visible after creation.
  • Step 3: Added products appear inside selected collection.
  • Step 4: Collection can be reused in install planning workflows.

Screenshot map (step-level)

  1. Collection planning in dashboard context

  2. Workflow graph for reusable stacks

Operational objective

Complete the “How collections work” workflow with predictable outcomes, clear auditability, and repeatable execution quality across team members and projects.

Acceptance criteria (all must pass)

  • The workflow can be completed without missing permissions or blocked route access.
  • All required dashboard routes load successfully for the active account.
  • The expected UI states are visible in the same order as documented.
  • At least one end-to-end validation confirms the process works in practice.
  • Evidence artifacts are captured for support and audit handoff.

Routes that must be reachable during validation:

  • /dashboard/bookmarks
  • /dashboard/bookmarks/[id]

Failure modes and exact remediation

  • Permission failure: Recheck plan/license entitlements and retry after session refresh.
  • Route loads but action is missing: Confirm feature flags/plan gates and selected context (site/license).
  • Action runs but state does not update: Refresh, re-open the relevant page, and verify from history/log view.
  • Partial success in multi-step operations: Retry only failed sub-steps and preserve successful state.
  • Cross-page mismatch: Reconcile with dashboard history and capture timestamps before escalation.
  • Persistent failure after one controlled retry: Open support ticket with full evidence package.

Evidence package for support escalation

Collect all items before escalating:

  • Account email and user role
  • Affected route path and exact action taken
  • Site URL, product/license identifier (if relevant)
  • Timestamps for first failure and latest retry
  • Expected result vs actual result
  • Screenshot set listed below

Screenshot evidence checklist

  • Step 1: Collection planning in dashboard context
  • Step 2: Workflow graph for reusable stacks
  • One screenshot with visible timestamp (system clock/browser tab)
  • One screenshot showing route context or breadcrumb
  • One screenshot showing final persisted result
  • Replace any generic placeholder/demo visuals with real environment captures

FAQ

Can I skip steps if I already know this workflow?

Skip only after all acceptance criteria still pass. If any criterion fails, run the full sequence exactly as documented.

Should I run this in production first?

Use staging first for medium/high-impact changes. Promote to production only after validation evidence is complete.

What if my screen does not match the guide exactly?

UI can vary by plan and feature access. Validate route access, plan gates, and expected state outcomes instead of pixel-perfect layout.

How many retries should I perform before escalation?

Run one controlled retry after checklist validation. If failure persists, escalate with full evidence to avoid hidden side effects.

Who owns this guide operationally?

Customer Success owns this guide and its periodic review cycle.

Guide metadata

  • Difficulty: Beginner
  • Estimated completion time: 10-20 minutes
  • Owner: Customer Success
  • Last reviewed: 2026-03-18