You can use Airtable and a miniExtensions Portal to collect client brand assets against a project checklist, review each item, and decide whether the project is ready to start. Give the logo, brand guide, approved copy, and photographs their own requested-asset records. That makes a missing or unsuitable item visible instead of burying it in a folder of uploads.

This workflow is for agencies and independent studios that already coordinate projects in Airtable. The example follows a fictional studio preparing a website for Cedar & Pine. It focuses on the kickoff decision: which inputs are usable, which still need attention, and who can resolve the remaining gaps. Uploading a file is only one step.

Define what the project needs before inviting the client

A vague request to “send your brand assets” produces vague results. Before sharing the checklist, the project lead should name the materials needed for the agreed scope and explain what makes each one usable. A website might need a vector logo, a current brand guide, approved introductory copy, and three licensed photographs. A social campaign might need different crops and a shorter copy set.

Write a specific acceptance note for each requirement. For the logo, ask for the original artwork rather than a screenshot. For copy, identify the page or section and who should approve the wording. For photographs, ask the client to confirm the intended use and supply relevant usage information. Staff still need to assess that information; an upload cannot establish intellectual-property rights.

Separate essential inputs from optional references. Cedar & Pine can start layout work without inspiration images, but not without an agreed logo and the core page copy. This distinction prevents a single optional item from making an otherwise prepared project look blocked.

Build records around requirements, not a single file bucket

The following fields are a suggested workflow design, not a built-in brand-management template. Begin with fictional data in a practice base.

  • Clients: Client Name as primary single-line text and Company Notes as long text. This table represents the organization.
  • Contacts: Contact Name as primary text, Email as an email field, and Client as a link to Clients. Store one person per record; use this table for portal users.
  • Projects: Project Name as primary text, Client as a link, Project Lead as a collaborator field, Planned Kickoff as a date, and Kickoff Decision as a single select: Collecting, Ready, or Deferred.
  • Asset Requests: Request Name as primary text; Project and Responsible Contact as linked fields; Required for Kickoff as a checkbox; Instructions and Acceptance Criteria as long text; Due Date as a date; Files as an attachment; Submitted Copy and Client Notes as long text.
  • Asset Requests review fields: Review Status as a single select: Requested, Received, Needs Revision, Accepted, or Waived; Client Feedback as long text; Reviewer as a collaborator; Reviewed On as a date; and Internal Notes as long text.

Keep Responsible Contact directly linked to Contacts. Do not assume that the chain from an asset to its project and then its client automatically provides the portal relationship you need. The login documentation explains the users-table and related-record model.

Create four required rows for Cedar & Pine: Logo artwork, Brand guide, Homepage introduction, and Hero photographs. Add a fifth optional row for Reference websites. Assign an actual responsible contact to each. A request without an owner should appear in the project lead’s internal preparation queue, not quietly disappear from the client checklist.

Give the client a focused collection experience

Use the file upload and document portal walkthrough for the detailed portal setup. Apply it to Asset Requests and the Responsible Contact relationship, then retain the project-level readiness model described here. That existing guide covers personal-record views, email verification, read-only review fields, and checking the experience with two contacts.

The client-facing record should show the requirement, due date, instructions, and feedback. Allow the client to supply Files, Submitted Copy, and Client Notes. Keep reviewer decisions and internal notes outside the editable client inputs. For this first version, staff create the required rows; clients complete them rather than inventing a different checklist.

Use separate views for Action Needed, Awaiting Review, and Accepted. A client who returns after a week should immediately see what still needs their attention. Preserve each view’s personal-record scope and inspect any linked-record selectors as well as the main list. A tidy-looking view is not sufficient evidence that access is configured correctly.

For the Files field, the documented path is Form Fields, the attachment field, then Upload settings and Restrict Attachment Types To. Choose categories appropriate to the materials being requested. See the file-type restriction guide. File acceptance rules help guide uploads, but do not verify image quality, current branding, or permission to use an asset.

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.

Review the actual material and record a useful decision

When the client supplies the first three items, the coordinator marks those rows Received in Airtable. These status changes are manual in this example. The designer then opens the files and reads the copy. A filename such as final-logo.png does not establish that the file is the current approved logo.

Suppose the brand guide and copy are accepted, but the logo is a low-resolution screenshot. Mark the logo Needs Revision and write actionable feedback: “Please provide the original logo artwork; the uploaded screenshot becomes blurry at the intended header size.” Leave the two accepted rows alone. The client should not need to upload the whole package again.

If a replacement needs its own review trail, create a separate revision row linked to the original requirement or add a dedicated Asset Submissions table. Do not describe a collection of attachments in one cell as a complete version-control system. Start with the smallest model that preserves the decisions your team actually needs.

Make kickoff readiness an explicit project decision

The project lead reviews required rows, not the total number of uploaded files. Five photographs should not compensate for a missing logo. Create an internal Airtable view for the project where Required for Kickoff is checked and Review Status is neither Accepted nor Waived. Those rows form the remaining work list.

Keep waivers deliberate. If the client cannot provide a brand guide, the lead might agree to proceed using a written palette and typography brief. Record the reason, owner, and date in the requirement’s review notes before marking it Waived. This is a project-management choice, not a recommendation to skip a contractual requirement.

When no required issues remain, the lead records Ready on the project and confirms the next step through the team’s normal communication process. Changing the field does not itself book a meeting, notify the client, or promise a launch date. If you later add reminders, document and test that automation separately.

Check the complete handoff before using real assets

  • Use two fictional contacts linked to different projects; verify each sees only the intended asset requests and cannot redirect a request to another person.
  • Upload a harmless logo sample and confirm it lands on the correct requirement. Check that review decisions remain staff-controlled.
  • Return one item for revision and verify the client can identify the problem without changing accepted items.
  • Leave one required item empty and one optional item empty. Confirm the internal readiness queue treats them differently.
  • Record a sample waiver and verify its explanation is retained. Check the project’s readiness manually rather than assuming a checkbox completed it.

These are acceptance checks to perform in your own setup; this example has not been runtime-tested. Use the sharing guide to publish the configured extension and test the actual shared link, not only the builder preview.

This approach fits a team that wants a clear intake-to-kickoff handoff while keeping Airtable as its working database. It adds review discipline rather than replacing digital asset management, rights administration, or design software. For the later outbound stage, use the separate approved project attachment handoff guide. Collecting usable inputs and delivering finished work deserve different checklists.