> For the complete documentation index, see [llms.txt](https://docs.struct.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.struct.com/fundamental-concepts/supplier-data-onboarding.md). # Supplier data onboarding Supplier data onboarding lets your suppliers fill in product data directly in a branded portal, while you decide what they see, what they are asked for and what needs your review. Describes how suppliers deliver product data to Struct PIM through the Data Onboarding Portal, and how you stay in control of what reaches your live data. Instead of collecting spreadsheets and copying values by hand, you invite your suppliers to a portal carrying your own brand. They see only the products and fields you share with them, and everything they submit passes through the same draft review you already use in Struct PIM. ### Overview Onboarding product data from suppliers usually means many sources, formats and follow-up emails. The Data Onboarding Portal gives you tools to: * Share selected products with each supplier * Ask for exactly the attributes you need, at product, variant group and variant level * Review supplier changes before they reach your live data, or trust selected fields to merge directly * Discuss questions with the supplier next to the product or field they concern * Follow how complete each supplier's data is Suppliers work in their own portal with their own logins. They never sign in to Struct PIM. *** ### Core concepts Supplier data onboarding is built from a few building blocks, all set up under **Settings > Data onboarding**. *** #### Data suppliers A data supplier is an external organisation that delivers product data to you. For each supplier you decide: * Which areas it works in * Which languages and segments it can see and edit * Which of its changes wait for your review * Who from the supplier can sign in to the portal A supplier has no products of its own. Everything it sees comes from the areas assigned to it, so a supplier without an area sees nothing in the portal. *** #### Areas An area is a named part of your catalogue that you share with suppliers, for example "Bedding" or "Kitchen textiles". Many suppliers can share the same area. An area defines: * **Which products are shared**, using a query on products. An area with no product rule shares no products at all. * **Which variant groups and variants are shared** within those products. Leave these empty to share all of them. * **Which submission template applies**, which decides what the suppliers are asked for. A query condition can be fixed, or left open as a value you set per supplier. With a rule like "Brand equals {Brand}", one area can serve every brand supplier: each supplier only sees products of the brand you enter when you assign the area. Suppliers see areas by name, so area names must be unique. *** #### Submission templates and data templates A submission template describes what suppliers are asked for. It holds one data template per product structure, and the data template's name is what suppliers see as the kind of product. For every attribute at every level (product, variant group or variant), a data template states: * **Access**: whether the supplier can edit the value or only read it * **Requirement**: required, recommended or optional * **Review**: whether a submitted value requires review or merges directly * **Unchangeable**: whether the supplier can answer only once A submission template can also have a base template that states what every data template asks for, and category attributes that apply to products and variants in selected categories. *** #### Review policies By default every attribute follows the review setting in its template. For each supplier you can deviate from that: * **Review everything from this supplier** sends all changes to review, whatever the templates say * **Exceptions** set a single attribute to require review or merge directly for this supplier only An exception always wins, then the "review everything" setting, then the template. *** #### Drafts and review When a supplier saves a product, variant group or variant, the changes are stored in a draft named after the supplier. Your live data is not touched. When the supplier submits: * Values that merge directly are written to your live data * All other values are sent to review, and appear in the **Open drafts** dashboard widget Reviewers decide each change: accept it, ask for changes with a note, or reject it. Notes are shared with the supplier, so they know what to fix. *** #### Feedback Feedback threads are conversations between you and a supplier. A thread can be about the supplier in general, a product, or a single field. Users marked as responsible for a supplier are notified when the supplier writes, and you can @-mention colleagues to bring them in. *** #### Completeness Struct PIM calculates how complete each supplier's data is, per product, variant group and variant. Every field the template asks for counts once for each language and segment the supplier was given. Suppliers cannot submit while required values are missing. *** ### How it fits together ![Submission templates are used by areas, and areas are assigned to data suppliers. The supplier Fjord Textiles is assigned the areas Bath and Bedding with Brand set to Lumen Linen, so it sees Lumen Linen bath and bedding products and is asked for the fields in the Textiles template.](https://2141378775-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FuUonpFWM7AJ0xVVXV1tr%2Fuploads%2Fi37pJ89HW3r0IlYBfVt4%2Fdop-concept-relations.png?alt=media) * Submission templates define what you ask for * Areas define which products you ask about * Data suppliers are assigned areas, and get logins to the portal * Suppliers save and submit in the portal, which creates drafts in Struct PIM * Reviewers merge the drafts, and feedback threads handle the questions in between *** ### Why it matters Supplier data onboarding enables you to: * Get product data straight from the source, in the structure you need * Keep control of your live data through review * Cut the spreadsheets and email threads out of supplier onboarding * Give suppliers a professional, branded experience *** ### Related concepts * [Data Model](/fundamental-concepts/data-model.md) * [Data Management](/fundamental-concepts/data-management.md) * [Workflows & Automation](/fundamental-concepts/workflows-and-automation.md) * [Glossary](/glossary/overview.md) *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.struct.com/fundamental-concepts/supplier-data-onboarding.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.