You can build an Airtable assignment submission portal by linking each adult learner to their assignment records and storing every submitted attempt separately. miniExtensions provides the learner-facing forms and portal; instructors review the work in Airtable and attach feedback to the attempt they actually reviewed.

The important design choice is to preserve the first submission when a learner sends a revision. If both files live in one replaceable attachment field, a comment about an earlier draft can appear to refer to a later one. Separate attempt records keep the file, submission date, feedback, and revision request together.

A practical example for a small professional course

A fictional training company, Northbank Learning, runs an adult business-writing course. Each participant submits a short project proposal. An instructor responds with specific feedback, and the participant can submit a revised proposal. The team needs to answer: Which attempt is awaiting review? What did the instructor ask to change? Which attempt did the instructor accept?

This is a focused submission-and-feedback workflow. The broader enrollment and learning resource portal guide covers registration and general student portal structure. Here, the outcome is a clear revision trail after an adult learner is already enrolled. Course sales, payments, and enrollment eligibility remain outside the example.

Model assignments separately from learner attempts

Use fictional examples while configuring a base connected to miniExtensions. Create four tables:

  • Learners: Name (single line text, primary field), Email (email), and Active (checkbox). Store only the basic account information needed for this workflow.
  • Assignments: Title (single line text), Instructions (long text), Example File (attachment, optional), and Course Name (single line text). This holds the common task definition.
  • Learner Assignments: Assignment Label (single line text), Learner (linked record to Learners), Assignment (linked record to Assignments), Due Date (date), Overall Status (single select: Open, Awaiting review, Revision requested, Accepted), and Accepted Attempt (linked record to Attempts).
  • Attempts: Attempt Label (single line text), Learner (linked record to Learners), Learner Assignment (linked record), Work File (attachment), Learner Note (long text), Created At (created time), Review Status (single select: Awaiting review, Revision requested, Accepted), Instructor Feedback (long text), and Reviewed At (date with time).

The extra Learner Assignments table lets two participants work on the same common assignment with different due dates and outcomes. Attempts must link directly to Learners as well as to the assignment relationship. A learner’s name appearing two tables away is not a substitute for the portal’s user relationship. See the users-table setup reference.

For the sample data, create Avery and Quinn, one “Project proposal” assignment, and one Learner Assignment for each. Avery’s first attempt might be “Avery — Proposal — First submission.” The label is for readability; do not use a typed label as the only way of associating the work with its author or assignment.

Keep the learner interface narrow

Create a Portal using Learner Assignments as the initial data table and Learner as the user field. Set up appropriate login verification and personal-record views using the detailed portal guide. Then add Attempts, which also has its direct Learner link. Keep shared instructional content separate from private submission records.

Show the assignment instructions, due date, overall status, and accepted-attempt summary as read-only context. In the Attempts table, enable record creation and configure the create form with Learner Assignment, Work File, and Learner Note. Keep Instructor Feedback, Reviewed At, and review decisions out of the learner’s create form. Configure the assignment selector to offer only assignments linked to that learner, then verify it with both sample accounts. Staff reviews whether an assignment still accepts attempts; this example does not automatically enforce an assignment deadline.

The existing learning portal guide explains the association of records created inside a Portal with the logged-in user. Verify the saved Learner relationship on your own sample submissions rather than asking learners to choose their identity from a directory. This check matters particularly if you add a different standalone form or entry route later.

Use a separate expanding form for previously submitted attempts and make its displayed fields read-only. A revision should be a new attempt, not an edit of the first file. The creation and editing documentation explains where these controls live. Check every view and linked-record route so an alternate form does not still allow replacement.

For login, open Users & Login, select the email login field, and enable Two-Factor Authentication (Email verification). Use one valid email per user record.

For every private table view, open Views → Filter and Sort and set Choose Records to Display to Personal records only (linked to the logged in user). Repeat the two-user access check after adding views.

Configure the Learner Assignment linked field in the create child form: open Filter Records and use Choose Records to Display to limit the finder to personal records. The destination table must link directly to Learners. Turn off creation and expansion of destination records in that field so the selector cannot become another editing route. This documented personal-record finder filter does not change existing linked values; inspect those separately. Set Allow users to link to Single Record in Advanced, following the single-record selection guide.

Give uploads a clear contract

Tell learners exactly what to submit: for example, one PDF containing their project proposal, with any supporting explanation in Learner Note. In the Work File field’s settings, the documented Maximum allowed files option can keep each attempt to one principal document. Set a suitable upload size limit for the course and explain it beside the field.

File constraints do not establish that the assignment is complete, original, or readable. The instructor still opens the document and checks it. A valid upload can be the wrong assignment; a filename containing “final” does not mean it has been accepted. Avoid relying on filenames alone when identifying the attempt under review.

Run a revision cycle without losing context

Receive the first attempt

Avery creates a new attempt for the proposal assignment and uploads the file. The instructor checks an internal Airtable review queue for submissions without a completed review. In this initial workflow, the instructor or coordinator sets the review status manually; saving a file does not automatically send an email or advance the assignment.

Created At records when the attempt record was created. If you later add draft-saving behavior, that timestamp will not necessarily mean the learner completed submission at that moment. Choose an explicit submitted-time mechanism and test it before treating timestamps as deadline evidence. Do not silently turn a draft creation time into an assessment decision.

Attach feedback to the exact work reviewed

The instructor opens Avery’s first file, writes “Add a measurable outcome and identify the intended reader,” records Reviewed At, and marks that attempt Revision requested. The coordinator updates the Learner Assignment to Revision requested. Avery can now see both the submitted file and the reason another attempt is needed.

Accept the revision deliberately

Avery submits a second attempt with a note explaining the changes. The instructor reviews that new file and marks it Accepted. The coordinator links it in Accepted Attempt on the Learner Assignment and updates Overall Status. The first attempt remains available with its original feedback. A third upload should not silently replace the accepted attempt; staff must decide whether to review it.

Handle an extension or mistaken submission

If Quinn receives an extension, change Quinn’s Learner Assignment due date, not the common assignment definition for everybody. Record the operational reason in an appropriate internal note without collecting unnecessary personal detail. This design does not automatically reject late work or calculate penalties.

If Avery uploads the wrong file, retain that attempt and label it clearly for staff review rather than pretending it never existed. Ask for a new attempt and explain which record supersedes it. Decide an appropriate retention policy separately; a convenient revision trail should not become an indefinite store of material your organization no longer needs.

Verify the full learner-to-instructor loop

  • Log in as both fictional learners and check all assignment and attempt views.
  • Create an attempt, reload it, and confirm the correct Learner, Learner Assignment, and file in Airtable.
  • Confirm that learner accounts cannot edit feedback, review decisions, or previously submitted files through an alternate route.
  • Add feedback, create a second attempt, and verify the original file and feedback remain attached to the first.
  • Set an accepted attempt and check that the learner sees the intended outcome without seeing internal instructor notes.

Use this when the review process is small and explicit

This arrangement is useful for adult workshops, coaching programs, and professional courses that want a configurable submission queue. It is not a full learning management system, automated grader, plagiarism checker, certification service, or proof of academic compliance. Instructors still make assessment decisions and manage communication.

The practical benefit is that each discussion refers to a specific attempt. Learners know what to revise, instructors know what they have reviewed, and the final accepted work remains distinguishable from everything submitted along the way.