You can collect comparable supplier quotes in Airtable by issuing one shared set of requested line items and giving each supplier its own response records. A miniExtensions Portal provides the response experience, while the buyer reviews prices, availability, exceptions, and terms in Airtable. Each reply stays attached to the specific item being quoted rather than arriving as an unrelated spreadsheet.

This is a buyer-side request-for-quotation workflow. It is different from preparing a quote for your own customer, covered in the quote request and estimate tutorial. Here, the buyer defines the requirements, several suppliers respond, and a person decides whether the replies are comparable before considering an award.

Start with a small purchasing comparison

Imagine a fictional community organization, Harbor Learning, seeking prices for event supplies. Its buyer requests 120 reusable notebooks and 120 pen sets, delivered to one location by a stated date. Two suppliers, Oak Supply and Meadow Goods, receive the same item descriptions, quantities, and response deadline.

The practical outcome is a review sheet that answers: did each supplier quote the specified item, in the requested unit, for the full quantity, with the relevant charges and delivery assumptions? A lower headline price is not helpful if one supplier quoted a pack of ten and another quoted a single item.

Keep the first version modest. One currency, a few suppliers, and a handful of lines make it easier to verify the model. More complex sourcing may require dedicated procurement software, formal tender controls, or a separate contract process. This example collects information; it does not make an award or place an order.

Separate buyer requirements from supplier responses

Use the following suggested Airtable tables. The field names and workflow stages are an example you can adapt.

  • Suppliers: Supplier Name as primary single-line text, Contact Name as text, and Email as an email field. For this example, give each responding contact its own portal user record.
  • RFQs: RFQ Reference as primary text, Project as text, Buyer as collaborator, Response Due and Required Delivery as date fields, Delivery Instructions as long text, and Stage as a single select.
  • Requested Items: Item Reference as primary text, RFQ as a link to RFQs, Description as long text, Unit as text, Required Quantity as a number, and Specification as an attachment.
  • Supplier Responses: Response Reference as primary text, RFQ and Supplier as linked fields, Supplier Notes as long text, Currency as a single select, Freight Amount as currency, Other Charges as long text, Valid Until as a date, and Supplier Declared Complete as a checkbox.
  • Response Lines: Response Line Reference as primary text, Supplier Response and Requested Item as links, Supplier as a direct link, Offered Description as long text, Quoted Unit as text, Unit Price as currency, Available Quantity as number, Delivery Date as date, and Exception Notes as long text.
  • Buyer review fields: add Review Outcome and Clarification Needed to Supplier Responses, plus Internal Assessment as long text. Keep these separate from supplier-entered wording.

The requested quantity belongs to the buyer’s requirement. The available quantity belongs to a supplier’s reply. Do not overwrite the former with the latter. Similarly, keep the original specification even if a supplier proposes a substitute.

Create RFQ-HL-01 and two Requested Items: NB-01 for 120 notebooks, unit Each; and PEN-01 for 120 pen sets, unit Set. Create a response header for each supplier, then two response lines beneath each header. Link all four lines to the appropriate requested item and supplier. Staff prepare these rows manually in this example, ensuring every supplier receives the same checklist.

Configure a supplier-specific response experience

Create a Portal using Supplier Responses as the data table and its Supplier link as the users relationship. The portal login guide explains the user and related-record structure. Configure the login method deliberately and verify each supplier’s record scope before sharing anything commercially sensitive.

Use the response child form to display the RFQ reference and buyer instructions without letting the supplier edit those requirements. Expose supplier-owned fields such as notes, freight, validity date, and the completion checkbox. The linked Response Lines field lets the supplier open the pre-created rows and enter its offer for each item.

For those pre-assigned lines, the desired behavior is to edit their contents without choosing another supplier’s lines, unlinking an item, or creating a substitute requirement. Follow the linked-record permission guide: leave the parent Response Lines field’s Read only setting off, hide the record finder, disable unlinking and creation, and retain expansion into the appropriate child form. Configure editable fields separately inside that child form.

Within a response line, make the buyer’s requested-item relationship informational rather than a supplier-editable selector. Show the relevant description, quantity, unit, and specification through carefully selected read-only fields or lookups. Allow edits only to the offered description, quoted unit, price, available quantity, delivery date, and exception notes.

Do not expose internal assessment fields or an unrestricted supplier list. Validate any nested navigation and every portal view with two test suppliers. The linked-record filter documentation distinguishes finder filtering from existing values; do not assume one finder filter controls all paths to a response.

In Users & Login → Login Fields, select the user Email field and enable Two-Factor Authentication (Email verification). Store exactly one email address per user record. Follow the email verification instructions; knowing an email address alone is not this example’s login method.

For every exposed private table and every view, go to Portal Tables → table → Views → view → Filter and Sort and set Choose Records to Display to Personal records only (linked to the logged in user). Maintain a real direct link from each private data record to its portal user, not an email-text match. The personal-record guide documents this setting.

Ask for exceptions explicitly

A supplier should be able to say that it cannot meet a requirement without corrupting the original line. Add short instructions: “Enter the unit you are pricing. If you cannot supply the requested quantity or specification, explain the difference.” Leave room for an unavailable item with a clear explanation rather than forcing a misleading zero-price offer.

Oak Supply quotes both items in the requested units. Meadow Goods quotes notebooks in packs of ten and can supply only 100 pen sets by the deadline. Both responses contain useful information, but they are not ready for a simple lowest-total comparison.

The buyer checks the notebook pack contents and normalizes the comparison in internal review fields only after clarification. Keep Meadow’s original Quoted Unit and Unit Price intact. Record the pen-set shortage as an exception and ask whether a later delivery or alternative is acceptable. Do not silently assume that partial supply satisfies the request.

Treat completeness as a declaration, then verify it

The supplier can check Supplier Declared Complete after reviewing all its lines. That provides a useful handoff signal, not proof that every commercial detail is present. Staff still review the response for missing prices, units, dates, freight, tax treatment, and validity assumptions before marking it Ready for Comparison.

The multi-table form documentation notes that child-form saves can reach Airtable before parent submission. Keep partially entered responses out of the comparison queue until the supplier declaration and buyer review are complete. Do not interpret a newly saved line as a final quotation.

Use a separate dated response revision if a supplier changes its offer after review. Retaining earlier responses makes it possible to understand why a decision changed. This workflow is not an immutable audit system, so agree on who may edit reviewed records and how revisions are retained.

Check the comparison and access boundaries

  • Log in as each fictional supplier. Verify it sees only its response and cannot reach the other supplier’s prices through a view, finder, or expanded record.
  • Confirm neither supplier can change the buyer’s item descriptions, units, quantities, or specification attachments.
  • Enter one response line, leave the rest incomplete, and verify staff do not treat it as a final response.
  • Try a pack-versus-each quotation and a partial quantity. Confirm the buyer’s review catches both differences before calculating a comparison.
  • Retain an unavailable-item explanation without manufacturing a price. Check that zero and blank have distinct meanings in your review process.
  • Create a practice revision and confirm the original offer is still available to the buyer.

These checks describe what to test in your own configuration; the fictional sourcing exercise has not been executed. Follow the sharing instructions and test the published end-user portal after setup. Check current plan and sharing requirements.

When the replies are comparable, the buyer can make a documented selection through the organization’s normal approval process. Keep ordering, contracts, payment, and supplier notification as separate deliberate steps. The value of this workflow is a consistent evidence set for that decision: the same requested items, clearly attributed responses, visible exceptions, and a human-reviewed comparison.