Suppliers can submit delivery updates through a miniExtensions portal while your purchasing team keeps a separate, staff-confirmed delivery date in Airtable. The key is to store each supplier update as its own record linked to a purchase-order line. That gives buyers a review queue without letting every new estimate overwrite the date operations is currently planning around.

In this fictional example, Harbor Workshop has ordered 60 desk frames from Alder Components. The supplier expects 40 units on the original date and 20 a week later. A single “delivery date” field on the purchase order cannot explain that split clearly. This workflow is a proposed record design based on documented portal capabilities, not a tested purchasing or logistics integration.

Separate order lines, supplier reports and accepted plans

Start with these tables:

  • Supplier contacts: Name as single-line text, Email as an email field, and Supplier name as text. One record represents one portal user.
  • Purchase orders: PO reference as text, Supplier name as text, Buyer as a collaborator field, and Order state as a single select.
  • PO lines: Line reference as text, Purchase order as a linked record, Item as text, Ordered quantity as a number, and Current confirmed date as a date.
  • Delivery updates: Update reference as text, PO line and Supplier contact as linked records, Reporting round as text, Proposed quantity as a number, Proposed delivery date as a date, Reason or comment as long text, and Buyer review as a single select.

Use a lookup to display the PO line’s item and order reference on each update. The direct Supplier contact link is important for portal setup; an indirect path through the purchase order should not be assumed to identify the logged-in user.

Keep “supplier proposed” and “buyer confirmed” values visibly different. The supplier reports an estimate. A buyer decides whether it is sufficiently clear to use in the current plan, checks any impact with operations and updates the confirmed fields. Acceptance here is an internal planning step, not an automatic contract amendment.

Create a small supplier reporting queue

For the first version, have a coordinator prepare one Delivery updates record per requested line and reporting round. For example, “PO-208 / line 1 / Friday update” links to the desk-frame line and Alder’s contact. This makes the requested work unambiguous and avoids relying on untested automatic linking or unrestricted line selection.

Configure the portal with Delivery updates as its data table and Supplier contact as the linked Users table field. See the Users table setup instructions. If you later expose PO lines themselves, establish and test their direct user relationship too.

Each supplier-facing view should use Personal records only (linked to the logged in user) under Choose Records to Display. Follow the personal-record filtering guide. Review all enabled views with fictional supplier accounts; a filtered overview alone does not establish the behavior of other views.

Show the item, requested reporting round, proposed quantity, proposed date and comment. Keep the buyer’s confirmed plan outside the supplier’s editable form. Choose a suitable verified login setup, using the email-verification documentation where relevant.

Turn a date change into an actionable review

Alder reports that all 60 frames will be late and explains the cause. The buyer checks the quantity and date, contacts the supplier if the message is ambiguous, and decides what to use for planning. Suggested Buyer review choices are Awaiting review, Clarification needed and Reviewed. These are custom fields, not a built-in supplier approval process.

After review, the buyer updates Current confirmed date on the relevant PO line and records a concise internal note. If the change affects a customer commitment, purchasing coordinates that separately with the responsible team. No customer notification, revised promise or external message is implied by saving the supplier’s form.

For the next reporting round, create a new update rather than clearing the previous record. This preserves the sequence of reported estimates for ordinary operational review. It does not make the records immutable. Set an appropriate editing policy and test the available configuration if suppliers should stop changing an update after review.

Represent split deliveries explicitly

For the 40-plus-20 scenario, create two clearly labeled update records for the same PO line, each with its own quantity and proposed date. The buyer checks that the quantities describe distinct portions rather than two replacements for the whole order. Ask for clarification before adding them together if the supplier’s wording is unclear.

If split deliveries are common, introduce a Delivery lots table with a PO line link, Lot quantity, Supplier proposed date and Buyer confirmed date. Treat that as an intentional extension to the data model. Do not force two dates into one field or overwrite a confirmed 40-unit lot with a later estimate for the remaining 20.

Keep actual receipt separate as well. A supplier’s “dispatched” or “delivered” report is useful information, but warehouse staff should record what was actually received under the team’s receiving procedure. This portal is not live carrier tracking and does not independently verify a shipment’s location.

Check the result before inviting suppliers

  • Create two fictional suppliers and confirm that each sees only its intended update records.
  • Submit an estimate, reload it and verify the saved quantity, date and comment.
  • Confirm that submitting an estimate does not silently change the buyer-confirmed plan.
  • Add a second reporting round and verify the first remains distinguishable.
  • Test a split delivery, a missing date and a quantity larger than the outstanding order. Make sure staff can identify and resolve each case.

This pattern works well when buyers need a structured follow-up queue and can review changes manually. It is not an ERP replacement, a contractual change-control system or a guarantee that delivery estimates are accurate. For a generic requester-and-reviewer relationship, the two-role approval portal guide provides a useful foundation. The delivery-specific outcome here is a traceable sequence of supplier proposals alongside a deliberately maintained operational plan.