Integration
Salsify supplier onboarding and recipient readiness
Salsify onboarding breaks less on generic mapping and more on recipient readiness. The hard part is getting supplier data into the exact state a recipient can share, validate, and publish without creating blocked or publication-pending products.
That means the launch page has to be about recipient-required fields, publication states, logistics hierarchy, and regulatory completeness. It should read like an operator guide for SupplierXM workflows, not a generic PXM integration page.
What teams are really solving here
The useful question is not whether Rastro can map a spreadsheet into Salsify. It is whether a supplier file can be turned into a shareable, publishable recipient payload on the first pass.
Products look complete in a supplier spreadsheet but still fail recipient-required fields once the SupplierXM schema is applied.
Teams can populate core attributes and still end up with blocked or publication-pending products because the publication channel is not ready.
Logistics hierarchy and pack structure data are often missing from supplier files even when product copy is present.
Regulatory fields vary by category, so the same onboarding flow can pass for hardware and fail for food, chemical, or cosmetic products.
Supported inputs, with destination-specific handling
These are the source types we actively turn into Salsify PXM / SupplierXMworkflows. Each one has a different failure profile, so the useful part is how the data gets normalized before it reaches the destination.
Excel spreadsheets
Source pathSupplier reality
Suppliers usually start with an Excel import template or their own workbook with flattened packaging and logistics columns.
What Rastro does
Rastro maps those columns to the recipient schema, normalizes values, and flags anything that would create blocked products.
Destination constraint
The important constraint is not file format. It is whether the row satisfies the recipient-specific required-field and publication-state logic.
GDSN feeds
Source pathSupplier reality
GDSN data often covers trade-item basics but still misses recipient-specific payload details that Salsify expects downstream.
What Rastro does
Rastro reconciles the GDSN feed against the recipient schema before upload and calls out gaps that will break sharing or publication.
Destination constraint
A GDSN record can be structurally valid and still be unusable for a given recipient without extra logistics or compliance fields.
PDF spec sheets
Source pathSupplier reality
PDF catalogs and spec sheets usually hold product copy and dimensions, but not recipient-ready hierarchy, logistics, or regulatory coverage.
What Rastro does
Rastro extracts product facts from the PDF, then maps them into the recipient model and highlights what still has to be sourced elsewhere.
Destination constraint
PDF ingestion is only useful if the extracted data can be translated into the specific fields that control product sharing and publication.
Manufacturer URLs
Source pathSupplier reality
Manufacturer sites are good for descriptions, imagery, and some specs, but rarely expose the exact recipient template or publishing state logic.
What Rastro does
Rastro scrapes the usable content, maps it into Salsify properties, and leaves a clean list of the recipient fields still missing.
Destination constraint
Destination readiness depends on recipient schema fit, not on whether the source page had rich content.
Recipient templates
Source pathSupplier reality
Retailer or recipient templates define the target shape, but suppliers still send values in the wrong format or with free-text enumerations.
What Rastro does
Rastro validates template fit before upload and resolves value-list mismatches that would otherwise become blocked products.
Destination constraint
Recipient templates are only helpful if the uploaded data already conforms to the closed lists, packaging hierarchy, and publication settings behind them.
Workflow stages that matter
We do not treat these destinations as generic import targets. Each stage below reflects the point where products usually stall for this specific platform.
Admit Excel, GDSN, PDF, and recipient-template inputs, but treat source acceptance as the easy part. The real gate is whether the source can be reconciled with the active recipient schema.
Map supplier columns into Salsify properties and recipient-required fields, with special attention to packaging levels, logistics hierarchy, and recipient-specific field names.
Run blocker logic before upload. This is where required-field gaps, regulatory omissions, and closed-list mismatches turn into blocked products instead of clean shares.
Check whether products are actually shareable and publication-ready, including recipient activation, publication state, and any remaining pending conditions.
What a first passing batch looks like
These are the signals we expect before calling a handoff safe enough to launch. They are meant to reflect what good operational output looks like on this destination, not a generic import success message.
The recipient schema is fully covered, including packaging, logistics, and the publication-state prerequisites that control sharing.
Closed-list fields and recipient-specific enumerations have been resolved so products do not get blocked on avoidable value mismatches.
Regulated categories have the compliance and labeling fields needed for the actual recipient, not just generic product facts.
The file can create shareable products on the first pass instead of producing blocked or publication-pending records that need another cleanup cycle.
Failure taxonomy we use on this destination
These are the recurring blocker patterns we classify before data is handed off. They map to the exact operational problems teams spend time fixing in Salsify.
Recipient required field missing
The product is missing one or more fields the active SupplierXM recipient requires before the item can be shared or published. This is the most common reason apparently complete products still block.
Blocked product
The current payload would create a blocked product in Salsify because required content, state transitions, or sharing prerequisites are not satisfied.
Publication pending
The item can exist in Salsify but is still waiting on publication-state requirements before it can be shared cleanly to the intended destination or recipient.
Publication channel inactive
The target recipient or publication channel is not active or not configured for the product, so otherwise valid content still cannot move forward.
Logistics hierarchy missing
Item, case, or pallet relationships are incomplete or absent. Supplier content may look usable, but the recipient payload is still structurally incomplete without the packaging hierarchy.
Regulatory data incomplete
Category-specific regulatory fields are missing or incomplete, which blocks sharing for regulated products even when general product content looks complete.
GDSN record incomplete for recipient
The GDSN item may be structurally valid, but it does not provide the full recipient-specific payload needed for Salsify onboarding and publication.
Breakpoints we diagnose before data hits Salsify
These are the concrete breakpoints that usually stop import, workflow progression, or publication. The point is to surface the exact thing that needs fixing, not to hand-wave about readiness.
Blocked Product Fix List
Returns the exact rows, missing recipient-required fields, and pack-structure gaps that keep products blocked or publication-pending in SupplierXM.
Open toolRecipient Payload Triage
Separates rows that are safe to share from rows that still need hierarchy, publication-state, or recipient-required field repairs.
Open toolHierarchy and Publication Blockers
Focuses on the missing case links, GTINs, and product states that leave SupplierXM items stuck before retailer sharing.
Open toolPublic tools are live for the sharpest failures
We publish self-serve tools only when they are useful on their own. Broader or more customer-specific diagnostics for Salsify PXM / SupplierXMstill run as part of assisted onboarding when the failure mode depends on private schemas, workflow config, or recipient rules.
Send a supplier file to run these checksOperator FAQ
The questions below are the practical ones catalog teams usually ask before they put a real supplier batch through this destination.
What usually blocks Salsify onboarding after a supplier file already looks mapped?
Recipient-required fields, inactive publication settings, and missing logistics hierarchy are the usual blockers. The mapping can look clean while the shareable payload is still incomplete for SupplierXM.
Why is a valid GDSN record still not enough for Salsify?
Because the recipient payload usually expects fields beyond the core GDSN structure. Packaging hierarchy, compliance details, and recipient-specific publishing requirements still have to be satisfied.
What does Rastro do before a supplier file reaches Salsify?
We reconcile the source against the active recipient schema, normalize closed-list values, and classify which rows will become blocked, publication-pending, or safe to share immediately.
What should this page prove before it is worth indexing?
It should help an operator understand whether a real supplier file can become a shareable, publishable recipient payload on the first pass. That is the standard we are using here.
Salsify attribute type coverage
All 11 attribute types supported, including localizable and scopable variants
Salsify attribute type coverage
All 11 attribute types supported, including localizable and scopable variants
stringrich_textnumberbooleandateenumeratedenumerated_multidigital_assetlinkhtmlcalculatedSee it on your own catalog
We'll deploy a demo portal with your PIM schema and map one real supplier file so you can see the output.