Building One Internal Request Hub with Airtable and Make

The Business Situation

Linden Forge Components is a fictional 85-person light manufacturing business operating from one production and office site. Its employees regularly need help from IT, human resources, finance, facilities, procurement, and production support.

Note: This case study is provided as a representative example of the types of AI integration and digital transformation solutions Intelligex designs and delivers. Actual engagements are tailored to each client’s goals, constraints, existing systems, timeline, and available resources, so the approach, tools, and outcomes may vary.

The business receives approximately 180 internal requests each month. About 55 concern IT, 25 concern HR, 30 concern finance, 25 concern facilities, 20 concern procurement, and 25 concern production operations.

Employees were submitting those requests through personal email, shared mailboxes, chat messages, hallway conversations, paper notes, and separate Google Sheets. Urgent work sometimes reached the correct person quickly, but there was no consistent way to distinguish a genuinely urgent issue from an ordinary request.

The operating group included an operations coordinator who became the system owner, an office administrator who served as the backup owner, and six queue owners:

• An IT coordinator for equipment, software, account, and access requests
• A People Operations manager for HR and policy requests
• A finance administrator for reimbursements, invoice questions, and reporting requests
• A facilities supervisor for building and maintenance requests
• A purchasing coordinator for procurement requests
• A production support coordinator for operational issues

Department managers and the finance manager remained responsible for approvals. Requesters remained responsible for supplying missing information and confirming when appropriate that an issue had been resolved.

Linden Forge Components already used Google Workspace. The selected implementation retained Google Forms, Google Sheets, Google Drive, and Gmail while adding Airtable as the operational system of record and Make as the automation layer.

The Existing Process

The original request process followed no single path, but a typical request moved through these steps:

1. An employee sent an email, chat message, or verbal request to the person they believed could help.
2. The recipient decided whether the request belonged to them. If not, they forwarded it or asked the employee to contact someone else.
3. The eventual owner copied some requests into a personal or departmental spreadsheet.
4. Supporting documents remained attached to email, stored in personal Drive folders, or linked from chat.
5. Approvals were requested in separate email threads.
6. The owner manually followed up when information was missing.
7. The requester asked for status updates because there was no common status record.
8. Managers assembled monthly reports from inbox searches and spreadsheets.

The problem was not simply that requests were slow. The business could not see the complete workload, assign clear ownership, establish consistent service targets, or identify which recurring issues should be prevented.

What the New System Needed to Do

The project team defined the requirements before selecting the final tools.

The form was explicitly not designed for emergencies. The introduction directs employees to call the designated supervisor for immediate safety risks, suspected security incidents, or production conditions requiring an immediate shutdown.

Implementation Approaches Considered

Google Workspace only

A Google-only implementation could store form responses in Sheets and use Google Apps Script for routing, reminders, approvals, and reporting. It was not selected because the script would have to implement record relationships, restricted operational views, retry controls, and substantial audit behavior.

Microsoft 365

Microsoft Forms, SharePoint, Power Automate, Outlook, and Power BI could support the process. This was a technically credible option, but Linden Forge Components already used Google Workspace. Introducing Microsoft 365 solely for this workflow would have increased identity and support overhead.

Airtable, Google Workspace, and Make

This approach retained the familiar employee-facing form and email tools while introducing a structured operational database and configurable automation. It provided enough workflow control for the expected volume without requiring a custom application.

Dedicated service-management software

A dedicated platform would become more attractive if the business needed a customer-style service portal, formal service-level management, configuration management, on-call scheduling, complex asset relationships, or a larger support organization. Those requirements were not part of the initial scope.

The Selected Solution

The selected solution used Google Forms for intake, a linked Google Sheet as a durable response buffer, Make for integration and scheduling, Airtable for operational records and reporting, Google Drive for documents, and Gmail for communication.

The implementation removed manual spreadsheet entry, informal routing, most status inquiries, and individually scheduled reminders. Google Workspace remained the employee-facing environment, reducing training requirements.

Human decisions were deliberately retained. Queue owners could correct a route, managers approved qualifying purchases, IT approved access, finance released payments, HR handled employment decisions, and supervisors assessed safety or production risks.

System Architecture and Data Flow

• Intake: Google Forms with conditional request sections and optional file upload
• System of record: Airtable Requests, Routing Rules, Team Members, Approval Events, Activity Log, and Knowledge Articles tables
• Automation layer: Make scenarios triggered by new Google Sheets rows and scheduled monitoring intervals
• Document storage: Google Drive with restricted folders and links recorded in Airtable
• Notifications: Gmail sent from a delegated automation mailbox
• Reporting: Airtable views and Interfaces using current request records and calculated fields
• AI layer: Optional constrained triage assistant for eligible, non-sensitive Unsure requests

1. Submission: An authenticated employee submits the Google Form. Google Forms validates required questions and writes a row to its linked response sheet. An incomplete form cannot be submitted. A form-level failure remains visible to the user and creates no operational record.
2. Trigger: Make monitors the response sheet for new rows. It receives the submission timestamp, row number, requester details, category fields, description, and file links.
3. Source key creation: Make combines the spreadsheet identifier and row number into a source key such as GF-YOUR_SPREADSHEET_ID-442. This key supports idempotency, meaning the same source event can be processed repeatedly without creating duplicate requests.
4. Duplicate check: Make searches Airtable for the source key. If a matching request exists, it records the existing request ID in the response sheet and stops the create branch.
5. Validation and transformation: Make normalizes email addresses, converts amount fields to numbers, converts dates to ISO date values, maps form labels to controlled Airtable values, and checks category-specific requirements.
6. Routing: Make searches the Airtable Routing Rules table using request type, subtype, location, and risk flags. It receives the owner, service target, approver rule, escalation owner, and knowledge link.
7. Record creation: Make creates the Airtable request. Airtable returns its record identifier and calculates the human-readable request ID. Make reads the completed record and writes both identifiers back to the source sheet.
8. Document handling: If files were uploaded, Make creates a request folder in Google Drive, moves or copies permitted files into it, and saves the folder and file links in Airtable. If file processing fails, the request still exists but is marked with a document exception.
9. Communication: Gmail sends a confirmation to the requester and an assignment alert to the owner. A relevant approved knowledge link is included when one is present in the routing rule.
10. Ongoing monitoring: Scheduled Make scenarios search Airtable for due reminders, overdue work, pending approvals, failed automation, and completed requests awaiting closure. Each notification is logged before the next reminder time is calculated.
11. Resolution: The owner marks the request Resolved in an Airtable Interface. The requester receives a final message. The record moves to Closed after confirmation or after the defined closure period.
12. Failure path: A failed module updates either the source sheet or the Airtable request with the error, retry count, last run time, and recovery status. The system owner receives a failure message after automated retries are exhausted.

Data Structure

The Airtable base contains one primary Requests table and five related tables. One request can have many approval events and activity-log entries. Each request links to one active routing rule, one owning team, and zero or more knowledge articles.

Workflow Statuses and Ownership

Records can move backward. A resolved request can return to In Progress if the requester reports that the problem remains. Pending Approval can return to Awaiting Info. Manual Review can return to New only through a controlled retry process.

Step-by-Step Implementation

Step 1: Prepare the Accounts and Permissions

1. Create an organization-owned Google Form for request intake and a separate approval-response form. Do not create them under an employee’s personal account.
2. Link each form to an organization-controlled Google Sheet. Protect raw response columns from normal editing.
3. Create a dedicated automation mailbox such as YOUR_REQUEST_HUB_EMAIL_ADDRESS. Use Google Workspace delegation or another approved shared-mailbox pattern rather than sharing a password.
4. Create an Airtable workspace and base owned by an organizational administrator. The account must support the required Interfaces, automation access, and permission model. Verify current vendor features before purchasing a subscription.
5. Create a Make organization, production folder, and separate test folder. Restrict scenario editing to the system owner and backup owner.
6. Connect Make to Google Sheets, Google Drive, Gmail, and Airtable using organization-controlled connections. Use OAuth where supported or a scoped Airtable personal access token. Do not use legacy or personal credentials.
7. Limit the Airtable credential to the request-hub base and required record scopes. Limit Google access to the mailbox, forms, response sheets, and document locations required by the workflow.
8. Create a restricted Google Drive root folder named Internal Request Hub. Grant access to the system owner, backup owner, and automation identity. Queue-specific subfolders receive narrower permissions.
9. Create test identities representing an employee, queue owner, approver, unauthorized user, system owner, and absent approver.
10. Build first in a test Airtable base, test forms, test sheets, and test Drive folder. Production connections should not be enabled until user acceptance testing is complete.

The Google connections request access to read response sheets, manage designated Drive files, and send Gmail messages. The Airtable connection requires permission to read routing data and create or update records. Administrators should review the actual consent screen because scopes can change as connectors are updated.

Step 2: Build the Intake

Create one Google Form titled Internal Request Hub. Restrict it to authenticated employees where the Google Workspace configuration permits this. Collect the authenticated email address rather than relying only on an employee-typed address.

The first section contains the common questions. The Request Type question is a multiple-choice field configured to send respondents to the corresponding category section.

Configure conditional sections as follows:

• IT: issue type, affected system, asset tag, number of users affected, access request indicator, privileged access indicator, and work stopped indicator
• HR: request subtype, desired response date, confidentiality indicator, and whether the request concerns the requester or a team
• Finance: finance subtype, amount, vendor or payee, cost center, related invoice number, and required date
• Facilities: building area, issue type, safety concern indicator, equipment affected, and access-window information
• Procurement: item or service, estimated amount, supplier, cost center, needed-by date, and whether an existing contract applies
• Operations: production area, work center, product or job reference, downtime indicator, quality impact, and supervisor notified indicator
• Unsure: affected team, desired outcome, and any known deadline

Use numeric validation for amounts and email validation for manager addresses. Required category-specific questions should prevent submission when they are blank. Make performs a second validation because source sheets can still be edited and because conditional requirements may be more complex than form-level rules.

Google Forms file upload normally requires the respondent to sign in. Confirm where uploaded files are stored and whether the organization’s shared-drive configuration supports the intended process. If those controls are unsuitable, replace file upload with a required organization-controlled Drive link.

The confirmation message should state that the request has been received and that a separate email will provide the request ID. Google Forms cannot display the Airtable request ID because Airtable processing occurs after submission.

Step 3: Create the System of Record

Create the Requests, Routing Rules, Team Members, Approval Events, Activity Log, and Knowledge Articles tables described earlier. Use controlled single-select values rather than free text for status, priority, type, approval status, and exception type.

In Routing Rules, create one active rule for every supported type and subtype combination. A representative rule contains:

• Rule ID: IT-EQUIPMENT-HIGH
• Request Type: IT
• Request Subtype: Equipment Issue
• Risk Condition: Work Stopped equals Yes
• Owner Team: IT
• Default Owner: IT coordinator
• Priority: High
• Target Hours: 8
• Approval Rule: None
• Escalation Owner: Operations manager
• Knowledge Article: Approved printer and workstation troubleshooting article
• Active: Yes

Use calendar-hour targets during the pilot because they are easier to calculate and audit consistently. If the organization requires business calendars, holidays, shifts, or site-specific coverage, add an approved calendar service or dedicated service-management platform rather than embedding increasingly complex date rules.

Create filtered Airtable views for each queue and for each lifecycle state. Base editors should be limited to administrators. Queue users should work through restricted Interfaces or another permission-controlled view that does not expose unrelated sensitive records.

Record history in Airtable is useful, but the Activity Log is still required. It creates an explicit event trail for automated reminders, approvals, reassignments, and key status changes.

Step 4: Connect the Tools

Configure the source and destination connections as follows:

1. Google Sheets to Make: Use a new-row trigger on the linked form-response worksheet. Select the sheet by identifier, not by a user-maintained copy.
2. Make to Airtable: Use the approved Airtable connection to search Routing Rules, search Requests by Source Key, create Requests, create Activity Log records, and update processing fields.
3. Make to Google Drive: Create the request folder and move or copy uploaded files when permitted. Capture the returned Drive folder and file identifiers.
4. Make to Gmail: Send from the automation mailbox. Map requester, owner, approver, request ID, subject, status, due time, and approved links into controlled templates.
5. Make to Google Sheets: Update the source row with Processing Status, Request ID, Airtable Record ID, Last Attempt, Retry Count, and Error Summary.

Connector module labels may vary as Make and the source products update their interfaces. The required pattern remains trigger, validation, duplicate search, routing lookup, destination creation, returned-ID capture, source update, and error handling.

Step 5: Build the Core Automation

Automation 1: Intake and record creation

• Trigger: A new row appears in the Google Forms response sheet.
• Conditions: Processing Status is blank or Failed, required common values are present, and the row has not already produced an Airtable request.
• Actions: Generate Source Key, validate data, search for duplicates, select the routing rule, create the request, retrieve the calculated Request ID, create an activity event, update the source row, create the Drive folder, and send email.
• Fields updated: Source Key, Request ID, owner, status, priority, due date, automation status, folder link, and processing fields.
• Notification: Requester confirmation and owner assignment message.
• Exception: Missing data, no routing rule, document failure, or notification failure creates a classified exception.

The exact action order is important:

1. Read the row and reject rows without a stable row number or submission timestamp.
2. Build GF-YOUR_SPREADSHEET_ID-ROW_NUMBER.
3. Search Airtable Requests for the exact Source Key.
4. If found, write the existing Request ID to the source sheet and stop.
5. Normalize email, date, number, and controlled-choice fields.
6. Check category-specific required values.
7. Search active Routing Rules for the exact type and subtype.
8. If multiple rules match, apply the most specific risk rule and flag the record if ambiguity remains.
9. Create the Airtable request with Automation Status set to Processing.
10. Capture the returned Airtable record ID.
11. Read the created record so the Request ID formula is available.
12. Calculate Due Date from creation time and Target Hours.
13. Calculate the first Next Reminder At value.
14. Create the Drive folder and process file links.
15. Create an Activity Log entry with event key CREATE:AIRTABLE_RECORD_ID.
16. Update the request to Assigned, Pending Approval, Manual Review, or Exception.
17. Send requester and owner messages.
18. Set Automation Status to Complete and write the result back to Google Sheets.

Automation 2: Assignment changes

• Trigger: A scheduled Make scenario finds an Airtable request with Reassignment Needed set to Yes.
• Conditions: The new owner is active, belongs to an authorized queue, and differs from the current owner.
• Actions: Save the previous owner, update the owner, clear the reassignment flag, create an activity event, and send notices.
• Fields updated: Owner, Owner Team, Last Automation Run, Automation Status.
• Notification: Previous owner, new owner, and requester receive the appropriate update.
• Exception: Invalid or inactive owners send the record to Manual Review.

Automation 3: Requester follow-up

• Trigger: A new row appears in a separate Google Form response sheet for additional information.
• Conditions: Request ID exists, requester email matches the original requester, and status is Awaiting Info.
• Actions: Create an Activity Log entry, link any new files, change the status to Assigned, and notify the owner.
• Fields updated: Status, Last Updated, Next Reminder At, Automation Status.
• Notification: Owner receives the new information; requester receives confirmation.
• Exception: Mismatched email or invalid status is held for manual review without changing the request.

Automation 4: Completion

• Trigger: A scheduled scenario finds a request newly marked Resolved.
• Conditions: Resolution note and Resolved At are present.
• Actions: Create a resolution event, send the completion message, and set a closure-review date.
• Fields updated: Resolved At, Next Reminder At, Automation Status.
• Notification: Requester receives the resolution and reopening instructions.
• Exception: Missing resolution information returns the record to the owner’s incomplete-work view.

Step 6: Add Approvals, Reminders, and Escalations

Create a second Google Form called Internal Request Approval. It collects the authenticated approver email and requires Request ID, Decision, and Comments. Decision values are Approve, Reject, and More Information.

Use representative approval rules such as:

• Procurement below $1,000 receives normal owner review but no separate workflow approval.
• Procurement from $1,000 through $4,999.99 requires the requester’s department manager.
• Procurement of $5,000 or more requires department-manager approval followed by finance-manager approval.
• Privileged IT access requires line-manager approval followed by IT approval regardless of stated urgency.
• Payment release is never performed by this workflow. Finance completes that action in the accounting system after its own controls.

The approval scenario performs these steps:

1. Watch for a new row in the approval-response sheet.
2. Build an approval event key from the sheet identifier and row number.
3. Search Approval Events for that key and stop if it already exists.
4. Find the request using Request ID.
5. Confirm the request is Pending Approval.
6. Compare the collected approver email with Current Approver Email after normalizing case.
7. Create an immutable Approval Event.
8. For Approve, move to the next approval level or set Approval Status to Approved and Status to In Progress.
9. For Reject, set Approval Status and Status to Rejected and notify the requester.
10. For More Information, set Approval Status to More Information and Status to Awaiting Info.
11. Write the outcome to the approval-response sheet.

Approver links contain the Request ID but no confidential description. The approver reviews details through an authorized Airtable Interface or restricted Drive location before submitting the decision.

For unavailable approvers, the Team Members table includes a designated backup and an Active flag. The system owner can activate delegation with a start and end date. Make records the delegation source in the Approval Event. An employee cannot delegate approval merely by forwarding the email.

Reminder and escalation rules are:

• For targets of eight hours or less, send the first owner reminder two hours before the due time.
• For longer targets, send the first reminder four hours before the due time.
• At the due time, send an overdue message to the owner.
• Four hours after the due time, notify the owner and escalation owner.
• Repeat once every 24 hours, up to three escalation levels.
• After the third escalation, place the request in the manual-review queue rather than sending unlimited email.
• Remind pending approvers after 24 hours and escalate to the approved backup after 48 hours.

Each reminder first searches Activity Log for its unique event key. Only after confirming that the event does not exist does Make send the email, create the log entry, increment Reminder Count, and calculate Next Reminder At.

Step 7: Add Documents and File Management

Create the following Drive structure:

Internal Request Hub
  2026
    IT
    HR Restricted
    Finance Restricted
    Facilities
    Procurement
    Operations
    Exceptions

For each accepted request, Make creates a folder named with the request ID and a sanitized subject, for example:

REQ-20260715-A1B2C3 - Packaging label printer unavailable

Remove or replace characters that are unsuitable for a controlled folder name, limit the subject portion to a practical length, and never include confidential HR details in the folder name.

When Google Forms supplies multiple file links, Make splits the response value, obtains the Drive file identifiers, and moves or copies each file to the request folder according to the organization’s storage model. The original URL is retained until file processing succeeds.

Apply these controls:

• HR and finance folders receive separate restricted permissions.
• Uploaded files are not made public through link sharing.
• Replacement files receive a revision suffix or date rather than overwriting the original evidence.
• The Airtable record stores the folder link and current-document links.
• Duplicate file names are retained with unique suffixes.
• Unsupported or oversized files remain a document exception, with instructions sent to the requester.
• Failed moves do not delete the source upload.
• Retention follows the applicable HR, finance, security, and operations policy rather than one universal period.
• Closed request folders are archived only after the retention owner confirms the applicable rule.

Step 8: Add Reporting and Operational Views

Build Airtable views and Interfaces for the following operational queues:

• New requests awaiting automation
• Assigned work awaiting owner action
• Pending approvals
• Requests awaiting requester information
• Overdue requests
• Open requests by owner and queue
• Rejected requests
• Manual-review records
• Document exceptions
• Automation failures
• Requests due in the next 24 hours
• Recently resolved and closed requests

The management Interface should show monthly request volume, open workload by team, overdue count, median completion time, request type distribution, reassignment count, exception rate, and automation failure count.

Airtable is the reporting source, not the raw response sheet. This avoids counting duplicate form rows or failed submissions as accepted requests. Calculated fields update as request records change, and Interface users see current Airtable data subject to their permissions.

The operations coordinator owns dashboard definitions. Queue managers validate their figures monthly. An alert is generated if any request remains New for more than 15 minutes, automation failures exceed three unresolved records, or a queue has work at escalation level three.

Step 9: Add Security and Governance Controls

• Give employees form access without giving them Airtable base access.
• Limit base-editor rights to the system owner, backup owner, and approved administrator.
• Use queue-specific Interfaces for operational users and verify that interface permissions enforce the intended restrictions.
• Store only routing metadata for highly sensitive HR matters. Detailed records can remain in a restricted HR system or Drive location.
• Never collect passwords, authentication codes, complete bank details, medical records, or unnecessary government identifiers.
• Restrict Drive links to named users or approved groups. Disable broad public links.
• Store Make and Airtable credentials in managed platform connections, not spreadsheet cells or scenario notes.
• Require multifactor authentication for administrators and automation owners.
• Record approvals as append-only Approval Events rather than relying only on the current Approval Status field.
• Review Google, Make, Airtable, and Drive activity logs when investigating a failure or unauthorized change.
• Remove access promptly when an employee leaves or changes roles.
• Back up routing rules, request exports, and critical configuration on an approved schedule.
• Apply department-specific retention policies rather than assuming that all requests have the same legal or operational value.
• Do not send restricted HR, finance, access, legal, safety, or security information to an AI service.

Step 10: Deploy and Test

1. Build and document the process in test forms, sheets, Drive folders, Make scenarios, and an Airtable test base.
2. Create at least two test records for every request type, approval path, priority, and exception path.
3. Use synthetic names, amounts, files, and descriptions. Do not test with real employee or financial information.
4. Run technical tests for mapping, duplicate prevention, permissions, dates, retries, and logging.
5. Conduct user acceptance testing with one requester, queue owner, and approver from each function.
6. Pilot the workflow with IT and facilities for two weeks before enabling the more sensitive HR and finance queues.
7. Freeze routing-rule changes during the final production test.
8. Duplicate approved configuration into production and replace test connection identifiers with production values.
9. Enable the intake scenario first, followed by approval, reminder, escalation, follow-up, and recovery scenarios.
10. Monitor every production execution during the first three operating days.
11. Publish a one-page employee guide and a queue-owner operating guide.
12. Retain the previous shared mailboxes during the pilot but configure automatic replies directing employees to the new form.
13. Define rollback as disabling Make scenarios, preserving all created records, and returning intake to the documented shared mailbox while the issue is corrected.

Code and Configuration

No custom code is required for the core implementation. Google Forms, Google Sheets, Airtable, Make, Google Drive, and Gmail provide the necessary native triggers and actions. This reduces source-code maintenance, but the scenarios and formulas still require version control, testing, and documentation.

Airtable formulas

Place the following formula in the Requests table’s Request ID formula field:

"REQ-" & DATETIME_FORMAT(CREATED_TIME(), "YYYYMMDD") & "-" & UPPER(RIGHT(RECORD_ID(), 6))

This creates a readable ID while retaining Airtable’s full internal record ID for integrations.

Create an Open Flag formula:

IF(
  OR(
    {Status} = "Closed",
    {Status} = "Rejected"
  ),
  0,
  1
)

Create an Overdue Flag formula:

IF(
  AND(
    {Open Flag} = 1,
    {Due Date},
    IS_BEFORE({Due Date}, NOW())
  ),
  1,
  0
)

Create a Resolution Hours formula:

IF(
  {Resolved At},
  DATETIME_DIFF({Resolved At}, {Submission Timestamp}, "hours")
)

Confirm Airtable workspace timezone and locale settings before relying on date-time reporting.

Make scenario configuration

Scenario INT-01: Intake and Routing
Trigger: Google Sheets, new row in Form Responses
Schedule: Every 1 to 5 minutes, according to operational need

1. Read new response row
2. Filter: Processing Status is blank or Failed
3. Build Source Key
4. Airtable search: Requests where Source Key exactly matches
5. Router:
   Existing record branch:
     Update source sheet with existing Request ID
     Stop
   New record branch:
     Validate common and category-specific fields
     Search active Routing Rules
     Create Airtable request
     Read calculated Request ID
     Calculate due and reminder times
     Create Google Drive folder
     Process file links
     Create Activity Log event
     Send requester confirmation
     Send owner or approver notification
     Update request as Complete
     Update source sheet as Complete
6. Error route:
   Increment Retry Count
   Save sanitized error
   Mark source row or Airtable request as Failed
   Notify system owner after retry threshold

Scenario INT-02: Reminder and Escalation
Trigger: Scheduled
Schedule: Hourly

Search Requests where:
  Open Flag = 1
  Next Reminder At is at or before the current run time
  Status is not Closed or Rejected
  Automation Status is not Processing

For each request:
  Build reminder event key
  Search Activity Log for the event key
  If absent:
    Send reminder or escalation email
    Create Activity Log event
    Increment Reminder Count or Escalation Level
    Calculate Next Reminder At
    Update Last Automation Run

Scenario INT-03: Approval Response
Trigger: Google Sheets, new row in Approval Form Responses

1. Build approval event key
2. Reject duplicate event keys
3. Find Request ID
4. Validate Pending Approval status
5. Validate authenticated approver email
6. Create Approval Event
7. Apply Approve, Reject, or More Information branch
8. Create Activity Log event
9. Send decision notifications
10. Update approval response row

Scenario INT-04: Failed Record Recovery
Trigger: Scheduled
Schedule: Every 15 minutes

Search source rows and Airtable requests where:
  Automation Status = Failed
  Retry Count is less than 3

For each record:
  Confirm no completed request already exists
  Re-run the failed operation
  Increment Retry Count
  Mark Complete on success
  Leave in Exception and notify the system owner after the third failure

Duplicate-search configuration

In the Make Airtable search module, filter the Requests table using the exact Source Key. A representative filter value is:

{Source Key} = "GF-YOUR_SPREADSHEET_ID-442"

The dynamic source key contains only the controlled spreadsheet identifier and numeric row number. Do not build search formulas directly from uncontrolled request descriptions.

Email templates

Subject: Request {{Request ID}} received: {{Subject}}

Your request has been recorded.

Request ID: {{Request ID}}
Type: {{Request Type}} / {{Request Subtype}}
Owner: {{Owner Name or Queue Name}}
Status: {{Status}}
Target time: {{Due Date}}

Approved guidance:
{{Knowledge Link or "No matching article was selected"}}

Replying to this email does not automatically change the request record.
Use the provided follow-up link when additional information is requested.

Test formulas with known dates, open and closed statuses, and multiple record IDs. Test each Make scenario by processing one synthetic row at a time, then inspect the scenario execution history, Google Sheets processing columns, Airtable Activity Log, and received Gmail messages.

Failure Handling and Operational Reliability

Idempotency is applied to request creation, approval events, reminders, escalations, and resolution messages. Each operation has a stable event key. The automation searches for that key before repeating an externally visible action.

For failures that occur before Airtable creation, Google Sheets acts as the recovery queue. For failures that occur after creation, Airtable’s Automation Status, Retry Count, Error Message, and Activity Log provide the recovery state.

The system owner reviews failed runs each working day and performs a weekly reconciliation between processed form rows and Airtable Source Keys. No source row should show Complete without an Airtable record ID, and no form-sourced Airtable request should lack a matching source key.

A Complete Example

At 9:10 a.m. on July 15, 2026, a production planner submits an IT request from a mobile phone. The subject is Packaging label printer unavailable. The employee selects Equipment Issue, Packaging Line 2, High requested priority, work stopped for one user group, and asset tag PRN-204.

1. Google Forms validates the required fields and writes response row 442 to the linked Google Sheet.
2. Make receives row 442 and builds source key GF-YOUR_SPREADSHEET_ID-442.
3. Make searches Airtable and finds no existing request with that key.
4. The routing search matches the active IT equipment rule for work-stopping issues.
5. The submitted High priority remains High. The rule assigns the IT coordinator and an eight-hour calendar target.
6. Make creates the Airtable record. Airtable returns its internal record ID and calculates representative request ID REQ-20260715-A1B2C3.
7. Make sets the due time to 5:10 p.m. and the first reminder to 3:10 p.m.
8. A Drive folder named REQ-20260715-A1B2C3 - Packaging label printer unavailable is created. A photo uploaded with the form is linked to the folder and Airtable record.
9. The requester receives a Gmail confirmation with the request ID, owner, target time, and an approved printer reset article.
10. The IT coordinator receives an assignment message with the asset tag, area, impact, description, and Airtable Interface link.
11. No approval is required. Approval Status is set to Not Required and Status becomes Assigned.
12. At 9:24 a.m., the IT coordinator changes Status to In Progress.
13. At 1:45 p.m., the owner replaces a failed network adapter, enters a resolution note, and changes Status to Resolved.
14. Make records the resolution event, stamps Resolved At, and sends the requester a resolution message.
15. Because the request was resolved before 3:10 p.m., the reminder scenario finds a closed reminder condition and sends no owner reminder.
16. After requester confirmation, the queue owner changes the request to Closed. The completed request remains available for reporting and audit history.

If Make had received row 442 twice, the second execution would have found the existing Source Key, written the same request ID to the sheet, and stopped without creating another request or sending duplicate confirmation email.

Implementation Cost

All amounts below are representative planning assumptions, not vendor quotes or verified client results. Actual licensing depends on current product editions, user counts, operation volume, data retention, and security requirements.

The representative payback calculation later in this case study uses the $3,740 internal implementation cost and $140 monthly incremental software allowance. It excludes optional AI and optional professional implementation.

Estimated Time and Cost Savings

The estimates cover administrative handling such as intake review, copying data, routing, status follow-up, and reconciliation. They do not include the substantive time required to repair equipment, answer an HR question, review a purchase, or complete other requested work.

Current monthly labour hours: Monthly volume × current minutes per record ÷ 60

180 × 12 ÷ 60 = 36 hours

New monthly labour hours: Monthly volume × new minutes per record ÷ 60, plus exception handling and maintenance

(180 × 4 ÷ 60) + (180 × 10% × 8 ÷ 60) + 4 = 12 + 2.4 + 4 = 18.4 hours

Monthly hours recovered: Current monthly labour hours minus new monthly labour hours

36 - 18.4 = 17.6 hours

Estimated monthly labour value: Monthly hours recovered × loaded hourly labour cost

17.6 × $55 = $968

Net estimated monthly value: Monthly labour value minus recurring tool costs

$968 - $140 = $828

Estimated payback period: One-time implementation cost ÷ net estimated monthly value

$3,740 ÷ $828 = approximately 4.5 months

Recovered time does not automatically reduce payroll. It can provide additional capacity, quicker turnaround, less overtime, fewer administrative interruptions, higher manageable request volume, and lower dependency on individual employees.

Non-financial benefits include clearer ownership, fewer repeated follow-ups, fewer incomplete submissions, consistent approval evidence, improved auditability, better reporting, and a more predictable employee experience.

Readers should replace monthly volume, handling time, exception rate, maintenance effort, loaded labour cost, software allowance, implementation effort, and approval frequency with their own measured values.

Adding AI to the Automation

AI should be introduced only after deterministic intake, routing, reminders, approvals, security, and failure handling work reliably.

The core automation already provides structured intake, exact-match routing, ownership, due dates, notifications, escalation, document links, and reporting. None of those functions requires AI.

Potential AI enhancements include summarizing long descriptions, suggesting a category for Unsure requests, identifying likely missing information, assigning approved knowledge tags, and detecting requests that appear similar to recent submissions.

Required fields, amount thresholds, email validation, approval rules, access permissions, exact duplicate checks, due-date calculations, and final decisions should remain rule-based. Using AI for those tasks would add uncertainty without a corresponding business benefit.

The Recommended AI Enhancement

The recommended enhancement is a constrained triage assistant for requests submitted as Unsure. It does not make final routing or approval decisions.

• Trigger: Airtable request has Request Type equal to Unsure, AI Status equal to Queued, and Sensitive Data Review equal to Clear.
• AI input: Subject, minimized description, affected team, desired outcome, deadline, and a list of allowed categories and knowledge tags.
• System instruction: Classify only within the allowed taxonomy, identify uncertainty, and return valid JSON without inventing policies or links.
• Expected output: Suggested category, subtype, priority, summary, missing fields, knowledge tags, confidence, and sensitive-data warning.
• Validation: Make parses the JSON and checks enums, types, confidence range, field length, and prohibited output.
• Record update: Valid suggestions are written to separate AI Suggestion fields, not authoritative routing fields.
• Human review: The operations coordinator accepts, edits, or rejects the suggestion.
• Low-confidence handling: Confidence below 0.80 remains in Manual Review.
• Prohibited data: HR case details, medical information, payroll data, bank details, credentials, privileged-access details, legal advice, safety investigations, and security incidents.
• Failure behavior: The original request remains in Manual Review and follows the normal human triage process.

Reusable system instruction

You are an internal request triage assistant.

Classify only the supplied business request. Use only the allowed request types, subtypes, priorities, and knowledge tags included in the user message.

Do not make approval, employment, payment, access, safety, legal, or disciplinary decisions.

Do not invent a policy, owner, URL, amount, deadline, or fact.

If the input appears to contain credentials, medical details, bank information, legal case details, security incident details, or other prohibited sensitive data, set sensitive_data_warning to true and avoid repeating that information.

Return only one JSON object that conforms to the supplied schema. If the request cannot be classified reliably, use suggested_request_type "Unsure", provide a confidence below 0.80, and identify the missing information.

Reusable user prompt

Allowed request types:
IT, HR, Finance, Facilities, Procurement, Operations, Unsure

Allowed priority suggestions:
Low, Normal, High, Urgent

Allowed knowledge tags:
password-reset, printer-help, software-request, expense-policy,
purchase-request, building-maintenance, production-support, none

Request subject:
{{Subject}}

Minimized request description:
{{Description}}

Affected team:
{{Affected Team}}

Desired outcome:
{{Desired Outcome}}

Requested deadline:
{{Needed By or "Not supplied"}}

Return a JSON object matching the required schema.

Structured output schema

{
  "type": "object",
  "additionalProperties": false,
  "required": [
    "suggested_request_type",
    "suggested_subtype",
    "suggested_priority",
    "summary",
    "missing_fields",
    "knowledge_tags",
    "confidence",
    "sensitive_data_warning",
    "reason"
  ],
  "properties": {
    "suggested_request_type": {
      "type": "string",
      "enum": [
        "IT",
        "HR",
        "Finance",
        "Facilities",
        "Procurement",
        "Operations",
        "Unsure"
      ]
    },
    "suggested_subtype": {
      "type": "string",
      "maxLength": 80
    },
    "suggested_priority": {
      "type": "string",
      "enum": ["Low", "Normal", "High", "Urgent"]
    },
    "summary": {
      "type": "string",
      "maxLength": 300
    },
    "missing_fields": {
      "type": "array",
      "items": {
        "type": "string",
        "maxLength": 80
      },
      "maxItems": 10
    },
    "knowledge_tags": {
      "type": "array",
      "items": {
        "type": "string",
        "enum": [
          "password-reset",
          "printer-help",
          "software-request",
          "expense-policy",
          "purchase-request",
          "building-maintenance",
          "production-support",
          "none"
        ]
      },
      "maxItems": 3
    },
    "confidence": {
      "type": "number",
      "minimum": 0,
      "maximum": 1
    },
    "sensitive_data_warning": {
      "type": "boolean"
    },
    "reason": {
      "type": "string",
      "maxLength": 300
    }
  }
}

In Make, use the organization’s approved AI connection. Store the API credential in the managed connection, not in an Airtable field. Send only eligible fields, request structured output where the connector supports it, and parse the response using Make’s JSON tools.

After parsing, use filters to confirm that category and priority are allowed, confidence is between 0 and 1, text fields are within limits, and sensitive_data_warning is false. Invalid output sets AI Status to Failed and leaves the request in Manual Review.

The Knowledge Articles table maps approved tags to approved URLs. The AI does not generate links. Cost monitoring records eligible request count, input and output usage where available, failure count, and monthly service cost.

Benefits of the AI Enhancement

• Less time reading long Unsure descriptions
• More consistent category suggestions
• Short summaries for the manual-review queue
• Earlier identification of missing details
• Approved knowledge-tag suggestions without invented URLs
• Better reporting on recurring themes in unstructured requests

These are AI-specific benefits. Central intake, record creation, ownership, approvals, reminders, escalation, file management, and operational reporting are benefits of the core rule-based automation.

What Remains Rule-Based or Human-Controlled

• Final routing: A coordinator confirms AI suggestions because incorrect routing can expose sensitive information or delay work.
• Priority: Rules and queue owners validate urgency. An AI suggestion cannot declare a safety emergency or force an escalation.
• Access approval: Managers and IT approve access based on identity, role, and security policy.
• Purchase approval: Authorized managers approve spending according to deterministic amount thresholds.
• Payment release: Finance performs release in the accounting system under separate controls.
• HR decisions: Employment, leave, disciplinary, and policy-exception decisions remain with authorized people.
• Safety decisions: Supervisors assess hazards and production shutdown requirements.
• Legal conclusions: The system does not provide or approve legal conclusions.
• Final risk acceptance: An accountable manager must accept operational or security risk.

Estimating the Additional Value of AI

Assume 45 of the 180 monthly requests are submitted as Unsure and are eligible for AI after data screening.

Manual triage without AI: 45 × 3 ÷ 60 = 2.25 hours

Review with AI: 45 × 1 ÷ 60 = 0.75 hours

Correction effort: 45 × 15% × 2 ÷ 60 = 0.225 hours

Failure fallback: 45 × 3% × 3 ÷ 60 = 0.0675 hours

Net additional capacity: 2.25 - 0.75 - 0.225 - 0.0675 = approximately 1.21 hours per month

Estimated labour value: 1.21 × $55 = approximately $66.55

Estimated net value after AI usage: $66.55 - $15 = approximately $51.55 per month

This modest estimate illustrates why AI should be evaluated on measured eligible volume, consistency, and service quality rather than assumed to create large savings automatically.

Testing Checklist

Use synthetic sample data before processing real employee, financial, access, or operational information.

Ongoing Maintenance

The operations coordinator is the primary system owner. The office administrator is the backup owner. Functional queue managers own their routing rules, service targets, and knowledge content.

Configuration changes should be documented with the date, owner, reason, affected scenario, test evidence, and rollback method. Routing changes should be tested in the test base before production activation.

When to Move to Dedicated Software

The Airtable and Make implementation should not be replaced merely because the request volume grows moderately. It can remain appropriate while permissions, reliability, reporting, and maintenance remain manageable.

Reassess dedicated service-management, workflow, procurement, HR case-management, or facilities-management software when several of these conditions appear:

• Request volume materially exceeds the tested connector and operating capacity
• Multiple sites require separate calendars, queues, languages, and escalation policies
• Shift schedules, holidays, and service-level calculations become complex
• Formal regulatory or audit requirements demand stronger immutable controls
• Requesters need a full portal showing all their requests and conversations
• Advanced asset, configuration, vendor, contract, or inventory relationships are required
• Mobile technicians need offline access, dispatching, location, or barcode features
• Customers or suppliers need external portal access
• Permissions become too complex for the Airtable base and Interface model
• Exception rates or manual workarounds continue to increase
• Automation maintenance consumes more time than the process saves
• API limits, database scale, file handling, or reporting performance become constraints
• The organization requires vendor-managed support and contractual service commitments
• Security risk increases because sensitive cases are being forced into a general operational workflow

A migration should preserve request IDs, activity history, approval evidence, document links, status definitions, ownership rules, and reporting measures. The structured Airtable data can make that later migration more controlled than moving directly from disconnected email and spreadsheets.

Implementation Checklist

• Confirm business scope, monthly volume, request types, and emergency exclusions.
• Define queue owners, backup owners, approvers, and the system owner.
• Select Google Forms, Google Sheets, Airtable, Make, Google Drive, and Gmail roles.
• Create organization-owned accounts, forms, folders, mailboxes, and connections.
• Apply least-privilege permissions and restrict sensitive queues.
• Build the Requests and related Airtable tables.
• Define controlled statuses, priorities, exception types, and approval values.
• Create active routing rules for every supported category and subtype.
• Build conditional Google Forms sections and field validation.
• Link forms to protected Google Sheets response destinations.
• Document source-to-destination field mappings.
• Build intake, duplicate-check, routing, record-creation, and recovery scenarios.
• Capture returned Airtable, Drive, and source identifiers.
• Configure approvals, sequential thresholds, delegation, and rejection handling.
• Configure reminders, overdue escalation, and notification event keys.
• Create Drive folder structures, naming rules, permissions, and retention controls.
• Build operational views, manual-review queues, failure views, and dashboards.
• Configure activity logging, retry counts, error fields, and reconciliation.
• Test normal, exception, approval, file, notification, security, and retry paths.
• Run user acceptance testing with synthetic data.
• Pilot selected queues before enabling sensitive functions.
• Document deployment, rollback, support, and change-control procedures.
• Replace representative implementation and savings assumptions with measured figures.
• Add optional AI only after the core workflow is reliable.
• Keep AI suggestions separate from authoritative fields and require human review.
• Assign primary and backup maintenance owners.
• Review dedicated-software criteria at least annually.