Knowledge check Shooting List & SKU Lifecycle
12 questions in pool · live exam draws 5
I03
Q1 multiple-choice · import-patterns What are the three canonical patterns for importing shooting lists into PhotoRobot?
Source: I03 textbook §2 (The 3 canonical import patterns).
Explanation: PhotoRobot supports three import patterns: (A) CSV upload (manual / scheduled, low volume, no API), (B) per-item API push (event-driven, moderate volume), © bulk API push (high volume, batch refresh). Pick based on volume + reliability needs.
Q2 scenario · deduplication · weight 2 Your integration receives the same SKU from upstream three times: SKU-12345, SKU-12345 (with whitespace), and sku-12345. Your integration just forwards each to PhotoRobot as-is.
Source: I03 textbook §3 (Deduplication — your responsibility, not PhotoRobot’s).
Explanation: PhotoRobot accepts SKUs as you provide them — SKU-12345 and sku-12345 look different and create two items. Canonicalization (trim + case-fold + strip non-alphanumeric + normalize separators) BEFORE sending, combined with a mapping table (canonical SKU ↔ PhotoRobot item ID) for lookup-before-create, eliminates duplicates.
Q3 multiple-choice · external-id What’s the role of the external_id field when creating a PhotoRobot item?
Source: I03 textbook §5 (External ID is the bridge).
Explanation: external_id stores the upstream system’s primary key on the PhotoRobot item. When PhotoRobot fires item.published, your webhook handler reads external_id from the event payload and uses it to update the correct ERP record. Without external_id, you can’t round-trip status — ERP team won’t know which SKUs have photos.
Q4 scenario · bulk-partial-failure · weight 2 You sent a bulk import of 500 items. PhotoRobot responds with HTTP 200 , total 500, succeeded 487, failed 13.
Source: I03 textbook §8 (Batch import — handling partial failures).
Explanation: Partial success is normal in bulk imports. Handler must parse per-item results, record success, retry retriable errors individually, surface non-retriable errors (validation) to human review. “All or nothing” rollback breaks 487 successes for the sake of 13 failures.
Q5 multiple-choice · on-conflict PhotoRobot’s bulk import on_conflict parameter has three options. Which means “overwrite existing item’s metadata”?
Source: I03 textbook §3 (Dedup at the PhotoRobot side).
Explanation: on_conflict: update overwrites the existing item if the SKU matches. Combined with idempotent integration code, re-imports converge to a stable state. error (default for strict imports) fails the row. skip silently ignores duplicates.
Q6 scenario · hard-delete · weight 2 Your customer’s ERP marks a SKU as “discontinued”. Your integration receives the lifecycle event.
Source: I03 textbook §4 (Archived (soft delete) + Deleted (hard delete)).
Explanation: “Discontinued” upstream = archived on PhotoRobot, not hard-deleted. Historical photos remain visible (e.g., for past order references, support tickets). Hard deletes destroy assets permanently and should ONLY happen with explicit operator authorization. Most integrations should never hard-delete automatically.
Q7 multiple-choice · reconciliation-poll A reconciliation poll runs alongside webhooks because:
Source: I03 textbook §6 (The reconciliation poll).
Explanation: Webhooks are best-effort; reconciliation guarantees eventual consistency. Even with healthy webhook delivery, things drift — handler returned 200 but DB write failed, item was modified directly in CAPP without firing a webhook, etc. Nightly reconciliation catches these silent drifts. Production integrations run both — webhooks for fast path, reconciliation for safety net.
Q8 multiple-choice · orphan-handling During reconciliation, you find a PhotoRobot item that’s not in your mapping table . What’s the right action?
Source: I03 textbook §6 (The reconciliation poll) + §10 (Common failure modes — “Item appeared in PhotoRobot that we never imported”).
Explanation: Orphans = items in PhotoRobot without a mapping in your DB . Almost always cause: operator added directly in CAPP, bypassing your integration. Right response: flag for human review . Humans decide whether to backfill the mapping (legitimate operator action) or remove the item (mistake). Auto-deleting destroys potentially valid work; ignoring leaves a permanent gap.
Q9 scenario · import-pattern-choice · weight 2 Customer has a Shopify storefront with 3000 active SKUs, on average 50 new SKUs per week. Their ERP fires a webhook whenever a new SKU is created.
Source: I03 textbook §2 (Recommendation) + §9 (Scheduling cadence).
Explanation: Hybrid is the textbook recommendation: bulk for initial seed (3000 items in 6 batches of 500 = fast, rate-limit-friendly), per-item for ongoing event-driven sync (real-time, atomic per item), reconciliation poll for safety net. Daily CSV is lazy and loses real-time freshness. Per-item for 3000 takes longer than bulk. Nightly full re-import is wasteful.
Q10 multiple-choice · project-structuring Which project structuring pattern is the safest default for a customer who doesn’t have a strong opinion?
Source: I03 textbook §7 (Project structure — how to organize items in PhotoRobot).
Explanation: Pattern 2 (one project per category) is the safest default. Stable long-term structure, items accumulate without lifecycle management, doesn’t require project archival every season. Pattern 1 (per campaign) requires lifecycle management as campaigns end. Pattern 3 (per brand) only fits multi-brand customers. “One project for everything” doesn’t scale past ~hundreds of items.
Q11 true-false · dedup-canonical-id Canonicalizing the SKU identifier is sufficient to prevent semantic duplicates (e.g., RED-TSHIRT-M and TSHIRT-RED-MEDIUM being treated as the same product).
Source: I03 textbook §3 (What dedup doesn’t fix).
Explanation: False. Canonicalization handles identifier dedup (whitespace, case, separators on the same SKU string). Semantic duplicates — same physical product, different SKU strings — require source-data cleanup at the customer’s ERP team . Your integration can flag suspected dupes (similar names, identical barcodes) but shouldn’t auto-merge. The customer’s ERP owner decides whether two SKUs represent the same product.
Q12 multiple-choice · csv-failure-mode The customer keeps “the same CSV export from ERP” and uploads it to PhotoRobot every Friday. Two months in, you discover duplicate items everywhere. Most likely cause?
Source: I03 textbook §3 (Deduplication — your responsibility) + §10 (Common failure modes).
Explanation: CSV imports without dedup logic create duplicates whenever upstream renames / reformats. SKU RedShirt-M becomes RED-SHIRT-M after ERP cleanup → PhotoRobot now has both. Fix: canonicalization rule applied to every row + on_conflict: update or pre-import dedup against mapping table . CSV imports are not magically deduplicated by PhotoRobot.
Ready to commit? You can review and change your answers before submitting. Once submitted, this attempt is final and we'll show you your score, correct answers, and explanations.
Submit final answers
