Skip to main content

​
Overview

With a data request you ask a supplier for the packaging data of their units and components in a structured way. The supplier receives a secure portal link, delivers components and documents directly into the platform, and you track progress in the supplier cockpit. There is exactly one request type — the data request. It can cover whole packaging units, individual components, or both; the supplier delivers components, values, and documents.
Readiness checks sent earlier remain usable: their links still open and can still be answered. New ones are no longer created.

​
Creating and sending a request

You start a request on the packaging unit, on the component, or from the supplier’s row in the cockpit — everywhere via the Request data button, and everywhere the same Request packaging data dialog opens.
1

Open the dialog

Click Request data. The Request packaging data dialog opens.

The Request packaging data dialog with scope, supplier, and message

2

Select or create the supplier

If you start from a unit or component, the already-assigned supplier is pre-selected. If the supplier does not exist yet, create them via + Add a new supplier right in the dialog (name, email, country); on send, they are assigned automatically. If you start from the cockpit row, the supplier is already fixed.
3

Review the scope

The dialog shows both grains: Packaging units in this request and Components in this request. Both lists are pre-selected with this supplier’s full scope — including the unit or component you started from. That way the supplier holds one link covering everything instead of several partial requests. You can narrow the selection.The platform prevents double-asking on its own: components already collected through a selected packaging unit are excluded automatically, and anything already part of an open request is not asked for again.
4

Due date and message (optional)

Set a due date under Requested by (optional) and add context for the supplier under Message to the supplier (optional) (max. 2000 characters).
5

Choose the delivery method and send

Decide how the supplier gets access:
  • Copy link (badge Recommended, the default): the Create link button creates the access, and under Invitation link ready you copy it — you pass it on yourself, e.g. from your own mailbox, which the supplier recognizes. No email is sent.
  • Send email: the Send request button has Polygon One send the email automatically. This requires an email address on the supplier record — without one the option is blocked and the dialog points you to the copy-link option.
If the email cannot be delivered, the request is not lost: the same Invitation link ready view opens, with the note “Share this link with your supplier. It opens their data request directly — no email was sent.” Copy the link and pass it on yourself.
If everything asked for is already complete, nothing is sent. Polygon One then refuses the send before anything is created — no request, no link, no email — and reports: “Nothing sent — all requested data is already complete.”What counts is the completeness state Polygon One tracks: the heavy-metals entry and — for food contact — the PFAS entry. Mass, recycled content, materials and polymer are not scored. So if heavy metals (and PFAS where it applies) are in place for the entire chosen scope, the send is refused even while other fields are still blank. If one target is missing its entry, the request goes out as usual. Widen the scope if you want to ask anyway.In a multi-selection this is decided per supplier: suppliers whose data is complete are skipped, and all the others get their request. The result names how many were skipped — in a request spanning both grains the same supplier is counted there twice.
If your selection spans both grains, the send creates one request per grain — one for the packaging units, one for the components. The supplier sees both in their request dashboard; with the Copy link delivery method they still receive one combined link.

​
Requesting from the cockpit

The Request data row action in the supplier cockpit opens the very same dialog: the supplier is fixed, and both lists are pre-selected with their full scope. So nothing goes out automatically — you can adjust the scope before sending and choose between link and email just as anywhere else. The bulk action works differently: Request data ({count}) sends asynchronously in the background and by email only — there is no copy-link option here. Selected suppliers without an email address are reported in the result as skipped; no request is created for them. Add an email address for those suppliers first — or request from them individually via the row action with a copied link.

​
What the supplier receives

With automatic delivery, the supplier gets an email with the subject “{your company name}: packaging data request (PPWR)”. It contains:
  • who is asking and why (EU Packaging and Packaging Waste Regulation, PPWR),
  • how many units or components are affected,
  • the due date (“Requested by {date}”), if set,
  • the Open the request button with the secure portal link.
The email language follows the supplier’s country (e.g. German for DE/AT). If the supplier replies directly to the email, their reply automatically lands in the request’s message thread. The portal link works without an account — what the supplier sees there is described on the supplier portal page. Every supplier has one durable portal link: a new request to the same supplier reuses that link instead of issuing a second one. If several requests are open, the link lands on a request list split into To do and Completed.
  • Validity: 30 days — refreshed every time the link is reused. After a maximum lifetime of 90 days, the platform issues a fresh link automatically and sends it with the next request.
  • Replaced partial requests: if a new, wider request also covers earlier partial requests, those are cancelled. The dialog tells you on send: ”… earlier partial request(s) replaced — their old links no longer work.”

​
Request statuses

The supplier’s request history shows the status of every individual request: In the cockpit you additionally see the derived collection status per supplier: Not requested / Awaiting reply / Reply received — incomplete / Complete / Overdue — including the progress “{provided} of {total}”. Complete means the data has been fully provided, not merely that the supplier replied; Reply received — incomplete distinguishes the supplier who answered but did not provide everything from the one who has not answered at all (“A reply has been received, but some requested packaging data is still outstanding.”).

​
Reminders and chasing

Polygon One follows up automatically so requests don’t go stale:
  • Supplier reminders: by default, after 7 and 14 days without a reply, the supplier receives a reminder email (“Reminder: {company} — packaging data request (PPWR)”) with the same portal link.
  • Escalation to you: if a request stays unanswered for 21 days, your admins are notified.
  • The Reminders column in the cockpit shows “{count} reminder(s) · last {date}” for the most recent open request — or ”—” if none have been sent.
The rungs (7/14 days, escalation after 21 days) are defaults. Under Settings → PPWR you can add or remove rungs and switch chasing off entirely. When a request is reopened for correction, the reminder ladder starts over — and the supplier’s link is refreshed.
Requests you delivered via Create link trigger no automatic reminder emails to the supplier — the platform never emailed them, so chasing is on you. The 21-day escalation to your admins still fires.

​
Message thread

Every request has a message thread between you and the supplier. You open it via the messages button in the cockpit row (“Message {name}”); the supplier reaches the same thread from the portal — even after submitting their reply.

Message thread between you and the supplier

Direct email replies from the supplier to the request email are automatically filed into the thread — nothing gets lost in mailboxes.

​
Reviewing replies

Once the supplier has submitted, three review mechanisms apply. The second — reading the uploaded documents automatically — depends on AI document analysis.
AI document analysis is an add-on. The steps described here are available once it is enabled for your workspace. Without it, you enter the values manually as before.
  1. Delivered component data is written by the platform directly to the packaging unit — including the supplier’s self-declaration that their information is accurate. The obligation checklist and the collection progress update immediately; the cockpit shows what is complete and what is missing.
  2. Uploaded documents are read by the AI, which puts the values it found — each with its source passage — in front of you to decide and enters confident values directly. While the request is still open for the supplier, the values from their documents are not yet decidable on your side; their submission resolves that. You can approve or reject individual documents — on rejection, the request automatically goes back to the supplier with a note on which documents to replace. Details: Evidence documents.
  3. Request correction: if something is substantively wrong, send the whole reply back via the row action Request correction with an optional reason. The request switches to Correction requested, the supplier sees their previous answers prefilled and resubmits corrected data. The supplier can also ask for a reopen themselves (“Request a correction” in the portal) — but only you actually reopen it.

​
Proposals from the analysis

Once the supplier has replied it rarely ends with one round: individual entries are missing, differ, or cannot be confirmed from the uploaded document. From exactly those points the system drafts the next data request itself — per point the affected field, the quoted document and the reason.
These drafts go out without an approval click by default — under your name, as soon as the documents in the reply have finished being read (usually immediately, correspondingly later while files are still being analysed), and automatically at most once per supplier in 24 hours. To switch off: Settings → PPWR → Automatic packaging data requests, toggle “Ask about detected gaps automatically”. All the rules are in Automatic follow-ups.
While the automation is off, drafts collect in the supplier’s request history in the block “Proposed requests”. Every proposal carries the AI draft label, the number of open entries and the note that it was derived from the supplier’s reply: If a proposal was not sent automatically, the reason is printed below it:
  • “Not sent automatically: this supplier was already asked automatically recently”
  • “Not sent automatically: daily limit reached”
  • “Not sent automatically: this supplier’s data is already complete”
For cooldown and daily limit the draft stays approvable and goes out on your click — your own sends never count against the daily limit. When the reason is already complete, however, your approval is refused as well (“Nothing sent — this draft’s data is already complete.”) for as long as the scope stays complete.
The 24-hour cooldown counts automatic sends only. A request you send yourself does not delay the automation — it neither starts the cooldown nor shortens it. All that counts is when this supplier was last asked automatically. The cooldown is per supplier across both modules: an automatic EUDR request to the same supplier therefore also holds back the PPWR follow-up.
You can spot an automatically sent request in the request history by the label “Sent automatically”; the audit log records it with System as the actor. You can withdraw it there via “Cancel request” — the supplier’s portal link expires immediately, and this does not restart the 24-hour cooldown.

​
Next steps

Automatic follow-ups

When the system asks on its own — and how to switch it off.

Supplier portal

What your supplier sees after clicking the link.

Evidence documents

AI analysis, proposal review, and the document library.