This guide builds a document collection portal for a design agency. Each client will log in, see a list of requested files, upload their materials, and read the agency’s feedback. The agency will manage requests and review decisions in Airtable.

We’ll use two tables: Contacts for the people who log in, and Document Requests for the items they need to provide. You can use the same structure for supplier onboarding, supporting documents for applications, or project handovers.

You’ll need an Airtable base connected to miniExtensions. We’ll create a Portal because each contact can have several requests. For a single upload with no ongoing checklist, a Form may be enough.

Create the Contacts table

In Airtable, create a table named Contacts with these fields:

  • Name: single line text; use this as the primary field.
  • Email: email; store one email address per person.
  • Company: single line text.
  • Active: checkbox; check it for people who should have portal access.

Add one record per person who will log in, rather than one record per company. For example, Alex at Northstar Studio and Sam at Harbor Design would have separate contact records and email addresses. The names here are sample data; use addresses you control while setting up your own example.

This will be the portal’s users table. Your clients do not need miniExtensions accounts: their login information comes from their contact records. See the login guide for how user records and portal login work.

Create the Document Requests table and link it to Contacts

Create a second table named Document Requests. Add the following fields:

  • Request: single line text, used as the primary field. Example: “Website logo.”
  • Contact: linked record field pointing to Contacts. For this example, assign each request to one contact.
  • Instructions: long text describing the file you need.
  • Due date: date.
  • Files: attachment.
  • Client notes: long text for information supplied with the upload.
  • Review status: single select with Requested, Received, Needs an update, and Approved.
  • Feedback: long text for comments the client should see.
  • Internal notes: long text for the agency’s private review notes.

The Contact field must be a real linked record field, not a text field containing a name or email. miniExtensions uses that relationship to connect a request to the person who can access it. The users-table documentation explains this relationship.

Add three requests for Alex: “Website logo,” “Homepage copy,” and “Product photographs.” Link all three to Alex’s contact record and set Review status to Requested. Add a different request linked to Sam. This gives you two distinct sets of records.

If your agency needs project tracking too, add a Projects table and a Project linked record field later. Keep the direct Contact link on Document Requests; a project name alone does not establish which portal user owns the request.

Create the Portal

  1. In miniExtensions, select your base, choose Create Extension, and select Portal.
  2. Select Document Requests as the Data Table.
  3. Select Contact as the User Field. This identifies Contacts as the users table.
  4. Finish creating the portal and give it a clear title, such as “Client Documents.”

Choose the users table carefully: it cannot be changed after the portal is created. You would need a new portal to use a different users table.

Configure email verification and active-user access

Portal login is enabled automatically. To use email verification:

  1. Open Users & Login.
  2. Under Login Fields, make Email from Contacts the only selected login field for this example.
  3. Open that login field’s settings and enable Two-Factor Authentication (Email verification).

With email verification, the Email field can be the only login field. Each contact needs exactly one valid email address in that field. The user receives a code to complete login; simply knowing someone’s email address is not the intended authentication method for this example. See the email verification setup guide.

In Users & Login, turn on Conditional Login and add the condition that Active is checked. Your team can then uncheck Active in Airtable when access should end. These conditions are checked when the user loads the portal, as described in the conditional login documentation.

Limit each portal view to the logged-in contact

Open the Document Requests portal table, go to Views, and select its view. Under Filter and Sort, set Choose Records to Display to Personal records only (linked to the logged in user).

Apply this setting to every view you add for these requests. Alex should see the three records linked to Alex; Sam should see the record linked to Sam. Do not select the option to show all records for a private client checklist. The personal-record filter guide covers the exact setting.

Configure the form used to open each request

Open the Document Requests table’s child form, which controls the fields people see when they expand a request. Use this field layout:

  • Read-only: Request, Instructions, Due date, Review status, and Feedback.
  • Editable: Files and Client notes.
  • Not included: Contact and Internal notes.

Select each field that should only display information and enable its Read-only setting. Keep that setting off for Files and Client notes. This lets clients provide their materials without changing the request, assigning it to another contact, or approving their own submission. See how to make a field read-only.

For this example, the agency creates requests in Airtable. In the portal table’s Create & Expand Records section, leave Allow users to create new records off. Clients will update existing requests rather than add items to the checklist.

Set the upload rules

Open the Files attachment field in the child form. Under Upload settings, use Restrict Attachment Types To if you only want particular file categories, such as images or documents. For a checklist that accepts several kinds of files, allow the categories your requests need. Explain the expected format in each record’s Instructions field. See the file-type restriction guide.

Then decide how updates should work:

  • Replacement workflow: use the normal editable attachment field so clients can return to the request and replace an outdated file.
  • Add-only workflow: in the attachment field’s Advanced section, enable Add-only mode. Enable Show existing values if clients should see previously uploaded files without being able to remove them.

For our agency checklist, use the replacement workflow so the client can correct a file after feedback. Add-only is better when you want to retain earlier attachments. It does not create a separate version-history system.

One important difference: attachment fields with add-only enabled disappear from grid views. Uploading still happens through the record’s form. If you need both a read-only grid display and add-only uploads, the add-only documentation provides a lookup-field workaround.

Add useful views and define the review process

In Airtable, create views in Document Requests with these filters:

  • Action needed: Review status is Requested or Needs an update.
  • Under review: Review status is Received.
  • Approved: Review status is Approved.

In the portal table’s Views section, reuse the initial view as Action needed: select the Action needed Airtable view under Filter and Sort. Then add Under review and Approved, selecting the matching Airtable view for each. Retain Personal records only in all three. Remove any other unfiltered or editable view that includes approved requests. Show useful columns such as Request, Due date, Review status, and Feedback.

Keep status changes with the agency for this first version. When a file arrives, your team sets Review status to Received. After reviewing it, set Approved or Needs an update and write clear Feedback, such as “Please upload the original-resolution photograph.” This guide does not configure automatic Review status updates. Your team changes that field in Airtable; you can add an automated status-update workflow separately.

To prevent edits through the Approved view, open that view’s Expand Records section and turn off Allow users to expand records. This also disables inline editing in that view, but means clients cannot open the record’s detail form there. Keep the important summary fields visible in the view. Make sure approved requests are not also exposed through another editable view. See how to limit editable records.

Publish the extension and share the portal link

When the configuration is ready, publish the extension, then open Share and use Copy URL. New users following that link will see the portal’s login page. Later configuration changes remain in Draft until you publish them again. The sharing guide explains the available options.

Before inviting clients, use your sample contacts to check the complete workflow: each contact sees only their assigned requests, can upload to Files and edit Client notes, and cannot change the review fields. Confirm the uploaded attachment appears in the correct Airtable record. Then change a sample request to Approved and check that it is no longer editable through any portal view.

You now have a repeatable process: create a request in Airtable, link it to the right contact, collect the file through the portal, and record the review outcome. Keep client documents in the login-controlled workflow rather than turning them into public attachment links.