Yno Tenant Syncer is built for organizations that operate more than one Commerce7 store and need a single place to align catalog, inventory, and customer profiles across those stores. Merchants configure each store independently (what to sync and how), while the service coordinates webhook-driven updates, scheduled reconciliation, and optional rules for pushing catalog and stock to peer stores—always within the permissions you grant at install.
How it works with Commerce7
Install & link: When a store installs the app, your install callback registers that tenant. Merchants complete setup in the companion experience (welcome, organization signup or join, install key for the organization, then per-store configuration). The install response can include a manage URL so admins land in the right context after install.
Embedded admin: The app is designed to run in the Commerce7 admin context, using the platform’s account user payload so signed-in Commerce7 users map to the correct organization and store roles (organization admin vs single-store manager).
API & webhooks: The service uses Commerce7’s REST APIs to read and update products, variants, inventory, and (per your customer spec) customers, subject to the scopes you enable. Webhooks keep the service current on product lifecycle events, orders (where needed for linking or downstream logic), and collection updates so collection-scoped catalogs stay accurate when membership changes.
Gated ingestion:No catalog or customer pipeline runs for a store until that store’s per-tenant configuration is finished (for example: product scope, primary inventory pool, and customer sync toggle). That prevents half-configured stores from writing data.
Scheduled jobs: A protected scheduled sync walks the catalog on a cadence you control, reconciling what webhooks might miss and supporting large catalogs with checkpointed runs so work can continue across multiple job cycles.
Key benefits
1. Multi-store catalog and inventory under one operating model
Per-tenant product scope: Each store can sync the full catalog or only products in selected collections, so tasting-room-only SKUs, bundles, or experimental lines do not pollute sibling stores.
Cross-tenant SKU alignment: Products and variants are tied together with sync groups and explicit mappings when the same item uses different SKUs on different stores.
Source-of-truth rules for merchandising: Where enabled, a designated master store drives product copy and merchandising to mapped followers; where not, last-write-wins using Commerce7 update timestamps keeps conflicts predictable.
Inventory that matches reality: Ongoing inventory updates can follow a dedicated inventory-focused path. Initial alignment can seed follower stores from the master when a group is first linked. Optional cross-store propagation can push origin-tenant catalog changes to peer stores under your policy (with controls so peer web merchandising stays intentional).
Inventory location awareness: Per-store rules for all locations vs selected inventory locations so stock snapshots reflect how each site actually fulfills.
2. Customer sync that respects real-world data quality
No forced “winning” customer record: The plan explicitly avoids a single automatic source of truth for people—one store’s profile may be more accurate than another’s regardless of timestamps.
Human-in-the-loop deduplication: Suspected duplicates within a store or across stores are flagged to a client-scoped dedupe queue; merchants resolve merges or “not a duplicate”—no blind auto-merge from fuzzy matching alone. Tunable heuristics (for example shared normalized phone, similar name + phone, or shared email where policy allows) only surface candidates.
Profile-only sync: Only names, addresses, emails, and phone numbers are in scope—not orders, carts, payment tokens, or unrelated CRM payloads unless you later extend policy.
Clear provenance on the Commerce7 customer record: Standard tag patterns indicate that a profile was synced from another named store and a club-specific variant when club status is known—tags are created idempotently per store so retries do not duplicate definitions.
Per-tenant on/off: Each store has a simple sync customers toggle for the first release; product rules and customer rules stay independent.
Optional audience filters (when customer sync is on): Restrict who enters the pipeline with club members only, lifetime value greater than zero, or both (AND)—so clubs-heavy or high-intent cohorts can be targeted without ingesting the entire directory.
3. Operational confidence: progress, email, and safe throughput
Role-aware dashboards and progress: Organization admins see all stores and org-wide progress; store managers see a scoped view—aligned to how multi-site teams actually work.
Completion notifications: When the first full reconciliation pass finishes for configured scope (including customer sync when enabled), installers can receive summary emails (including dedupe counts when applicable) so nobody is left guessing whether onboarding finished.
Rate-limit aware design: Large catalogs are handled with checkpointing, queued work, and bounded webhook fan-out (for example caps on collection-driven product walks) so bursts of Commerce7 activity do not overwhelm a single HTTP request.
What the app can do
Organization model: One install key for the whole organization; multiple stores can install under the same client; different team members can perform installs.
Product ingestion: Pulls product graphs from the API, respects collection filters and ingest policy flags, and applies webhook create/update/delete handling with the same gates as scheduled sync.
Collection maintenance:Collection update webhooks trigger re-evaluation of membership so products entering or leaving a scoped collection are picked up without waiting for the next full run (within configured limits).
Orders (where required): Order webhooks support flows that depend on order events or customer linkage without turning the product into a full order-replay system (daily product sync remains the primary reconciliation path for catalog scale).
Cross-tenant inventory reset model: Where propagation is enabled, peer primary inventory pools can be driven to mirror absolute quantities from the origin mapping, using the platform’s inventory transaction patterns documented in your sync design—not silent guesswork from order deltas.
Security-conscious webhooks: Optional Basic authentication on the webhook endpoint so only Commerce7 (with your configured credentials) triggers server paths.
Audit-friendly provenance (product side): Planned support for stamping custom text fields on products when the API allows it safely; otherwise provenance remains in the service’s own records—core sync is never blocked waiting on a stamp.
Yno Tenant Syncer turns many Commerce7 storefronts into one coordinated program: each store keeps its own scope and rules, while the service keeps products, stock, and customer profiles consistent with policies you control—including dedupe review so guest data stays trustworthy as you scale.
