Securing Payroll Change Requests with Approval Controls

The Business Situation

Kestrel Grove Manufacturing is a fictional 105-person specialty components manufacturer. The company runs payroll twice each month and uses Google Workspace for email and document storage. Payroll itself is processed in a separate payroll application that does not provide a sufficiently configurable workflow for collecting and approving every type of employee change.

The process is jointly owned by Human Resources and Finance. The people involved include an HR manager, an HR coordinator, a payroll specialist, a controller, approximately 14 line managers, and employees submitting their own banking, tax, benefit, or deduction changes.

The business receives an average of 36 payroll change requests per month. Volume is higher during benefit enrollment periods and before common compensation review dates. Requests include:

• Salary and hourly-rate changes
• Direct-deposit and banking changes
• Tax withholding forms
• Benefit elections and qualifying-event changes
• Voluntary deductions
• Corrections to previously submitted changes

Requests were being sent to individual HR or payroll employees through Gmail. Supporting documents were attached to messages, approvals were gathered by forwarding email chains, and a spreadsheet was used to track whether each change had been entered into payroll.

This created both operational and privacy problems. Sensitive documents appeared in inboxes, approvals were difficult to reconstruct, cutoff dates were inconsistently applied, and managers could be copied into messages containing information they did not need to see.

The company needed a controlled intake and approval process without automating final payroll-system entry. Payroll staff would continue to review and enter every approved change manually, preserving a human control before information affected an employee’s pay.

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 Existing Process

The original process followed a loose chronological sequence:

1. An employee or manager emailed HR or payroll with a requested change.
2. HR replied if required information or documentation was missing.
3. Supporting forms were sent as Gmail attachments.
4. HR forwarded compensation or benefit requests to a manager or controller for approval.
5. The payroll specialist copied request details into a tracking spreadsheet.
6. The specialist checked a separate payroll calendar to determine whether the request met the cutoff.
7. Approved information was entered manually into the payroll application.
8. A second reviewer checked selected high-risk changes, especially banking and compensation changes.
9. The payroll specialist emailed the requester after processing.
10. The spreadsheet was updated, although this step was sometimes delayed until the end of the payroll cycle.

The spreadsheet was useful as an informal checklist, but it was not a reliable system of record. It did not enforce status values, prevent duplicate rows, restrict sensitive fields by role, or record which person changed an approval field.

The practical objective was not simply to send fewer emails. The business needed structured intake, privacy-aware routing, explicit ownership, reliable deadlines, controlled approvals, and evidence showing how each request moved from submission to completion.

What the New System Needed to Do

The design also needed to distinguish security controls from convenience filters. A filtered Airtable view is not a sufficient permission boundary if the user also has access to the underlying base. Managers and requesters therefore could not be ordinary base collaborators with broad record access.

Implementation Approaches Considered

Microsoft 365

A Microsoft 365 implementation could use identity-aware forms, SharePoint permissions, Power Automate approvals, and Outlook notifications. It was not selected because Kestrel Grove Manufacturing had already standardized employee identity, email, and file storage on Google Workspace. Introducing Microsoft 365 solely for this workflow would add account administration and duplicate document governance.

Google Workspace

A Google Workspace implementation would avoid an additional record-management subscription, but it would require more custom logic. Google Sheets can hold the records, while Apps Script can create folders and send messages. The main concern was safely presenting role-specific records and approval controls without exposing the underlying spreadsheet. A custom web application could solve that problem, but it would require more development and ongoing code ownership.

Airtable with Zapier

Airtable provided linked request, approval, document, calendar, and automation records. Interfaces could present role-specific work queues without giving managers access to the base. Zapier could react to new and updated records, create Drive folders, copy files, send Gmail notifications, and run scheduled reminder workflows.

This option still required a security assessment. Airtable plan features, interface permissions, identity requirements, audit history, and data residency had to meet the company’s policies before payroll information could be stored there.

Payroll-System Workflow

Using the payroll platform’s employee self-service and native approval workflow would reduce the number of systems containing payroll data. That option should be selected whenever the product supports the required request types, approvals, cutoff logic, document restrictions, reporting, and audit evidence.

In this representative scenario, the payroll application supported final data entry but not the complete intake and cross-functional workflow. Replacing the payroll product solely to address 36 monthly requests was not justified, so final entry remained manual.

The Selected Solution

The selected implementation connected Airtable, Zapier, Google Drive, Gmail, and the existing payroll application. Google Docs, within Google Workspace, was used only to render a completion and approval summary from a controlled template.

Two intake experiences were created. Employees used an authenticated form for banking, tax, benefit, and deduction requests. Managers and HR used a separate compensation-change form. This prevented employees from selecting salary-change fields and reduced the chance that a compensation request would bypass management controls.

Gmail notifications contained only the request ID, category, status, due date, and a link to an authenticated interface. Full bank details, tax identifiers, compensation values, medical information, and uploaded documents were excluded from email.

The payroll application was deliberately not connected through an unattended API. Zapier prepared and routed the work, but an authorized payroll specialist performed the final entry. A second authorized person verified high-risk changes before the request was marked complete.

System Architecture and Data Flow

• Intake: Authenticated Airtable interface forms for employee and manager submissions
• System of record: Airtable base containing requests, approvals, documents, pay periods, change logs, and automation runs
• Automation layer: Zapier event-based and scheduled workflows
• Document storage: Restricted Google shared drive folders organized by data category, pay period, and request ID
• Notifications: Gmail sent through a controlled payroll-request mailbox
• Reporting: Airtable Interfaces and restricted operational views
• AI layer: Optional sanitized-note classification added only after the core workflow is stable

1. Submission: An authenticated employee, manager, or HR user submits an Airtable form. Airtable creates a request record and returns its internal record ID.

   Failure path: If identity cannot be matched to the employee directory, the request enters Validation Exception and no approval notices are sent.

2. Initial trigger: Zapier detects a new record in the controlled intake view. It creates an automation-run record using the Airtable record ID and event type as an idempotency key.

   Failure path: If the same event key already exists as completed, the Zap stops without repeating folder creation or email.

3. Validation: Zapier verifies the request type, requester identity, employee status, required fields, required attachments, target pay period, and effective date.

   Transformation: The request type is mapped to a document category, owner, approval route, and verification requirement.

4. Cutoff evaluation: The request is linked to a pay-period record. Zapier compares the submission timestamp and requested effective date with the maintained cutoff timestamp.

   Failure path: A past-cutoff request is routed to Deferred to Next Payroll or Manual Review. The target period is never changed silently.

5. Folder creation: Zapier searches Google Drive for a folder containing the request ID. If no folder exists, it creates one beneath the correct restricted category and pay-period folders.

   Returned identifier: Google Drive returns the folder ID and URL, which are saved in Airtable.

6. Document transfer: Each Airtable staging attachment is copied to Google Drive. A child document record stores the Drive file ID, checksum or available file metadata, category, and upload status.

   Failure path: The Airtable attachment is retained if copying fails. The request moves to the document exception queue.

7. Approval creation: Zapier creates linked approval-step records in sequence. Banking and tax changes bypass line managers. Compensation requests include manager, HR, controller when required by policy, and payroll approval.

8. Notification: Gmail sends an acknowledgment to the requester and an action notice to the first approver. Messages include no sensitive changed values.

9. Decision processing: Approvers record decisions through authenticated Airtable interfaces. An updated-record trigger validates the actor, records the decision, activates the next step, and writes a change-log entry.

10. Payroll entry: Once approvals are complete, the status becomes Approved for Entry. The payroll specialist manually enters the change and records the payroll batch or transaction reference.

11. Verification: A second authorized reviewer checks required high-risk changes. Rejected verification sends the item back to payroll entry with a reason.

12. Completion: Zapier creates an approval summary from a Google Docs template, stores it in the request folder, updates the request to Completed, and sends a generic completion notice.

13. Monitoring: Scheduled Zaps review reminders, overdue approvals, incomplete document transfers, stale automation runs, and pending notifications.

Data Structure

The Airtable base contained seven related tables. Airtable does not enforce relational foreign keys or unique constraints in the same manner as a SQL database, so validation Zaps and restricted editing permissions provided compensating controls.

The relationship model was:

• People Directory to Payroll Change Requests: one to many
• Pay Periods to Payroll Change Requests: one to many
• Payroll Change Requests to Approval Steps: one to many
• Payroll Change Requests to Documents: one to many
• Payroll Change Requests to Change Log: one to many
• Payroll Change Requests to Automation Runs: one to many

Approval and change-log records were not exposed to employee intake users. Managers saw only approval steps assigned to their authenticated identity, and they did not receive access to banking, tax, benefit medical details, or documents.

Workflow Statuses and Ownership

A record moved backward when an approver selected Return for Information, when verification found a mismatch, or when a previously accepted document was found to be unreadable. Rejections and cancellations required a reason. Reassignment required both a new owner and an administrative note.

Banking and tax requests never entered a line-manager approval stage. Managers had no business need to see those changes. Payroll verified the employee’s identity and documentation, while a second authorized reviewer checked the entered result.

Step-by-Step Implementation

Step 1: Prepare the Accounts and Permissions

1. Create separate production and test Airtable bases. The test base should contain invented employee IDs, email aliases for test users, and sample documents with no real payroll information.

2. Confirm that the selected Airtable subscription supports the required interface, collaborator, authentication, revision-history, and administrative controls. Feature availability can change, so requirements should be verified against current vendor documentation and the organization’s security policy.

3. Create the following Airtable access groups:

   • Base administrators: Limited to the HR system owner and designated backup
   • Payroll processors: Access to payroll queues and restricted document links
   • HR reviewers: Access to HR, benefit, and compensation views
   • Controller reviewers: Access only to compensation approvals and verification items
   • Managers: Interface access only to approval steps assigned to their authenticated identity
   • Employees: Authenticated intake access without base access

4. Create a restricted Google shared drive or equivalent organization-owned storage area. Do not place payroll folders in an employee’s personal My Drive. Create fixed category roots with inherited access:

   • YOUR_BANK_TAX_FOLDER_ID: payroll-only access
   • YOUR_COMPENSATION_FOLDER_ID: HR, controller, and payroll access
   • YOUR_BENEFITS_FOLDER_ID: authorized HR and payroll access

5. Create or designate a controlled Gmail identity such as YOUR_EMAIL_ADDRESS. It may send from an approved shared alias if Google Workspace and company policy permit. Do not connect a departing employee’s personal account to production Zaps.

6. Create a Zapier workspace owned by the company. Limit administrator rights, require multifactor authentication, and connect Airtable, Google Drive, Google Docs, and Gmail through OAuth.

7. Confirm the minimum Google permissions needed by the automation identity. The identity should be able to create and read files only within the approved payroll folder hierarchy and send mail through the controlled mailbox.

8. Create test identities representing an employee, manager, HR reviewer, payroll specialist, controller, unauthorized user, and delegated approver.

9. No API keys, inbound webhooks, database passwords, or service-account private keys are required for the core implementation. OAuth connections are stored in Zapier’s connection management rather than in Airtable fields.

10. Set Airtable, Zapier, and Google Workspace to the same payroll operating timezone. Test dates around daylight-saving changes if the organization operates in a region where those changes occur.

A filtered view must not be treated as a security boundary. Anyone with base-level access may be able to reach records beyond a view. Managers and employees should use controlled interfaces and should not be made broad base collaborators.

Step 2: Build the Intake

Two authenticated Airtable interface forms were created.

Employee Payroll Change Form

Manager and HR Compensation Form

The compensation form was visible only to authorized managers and HR users. It contained:

• Employee selection from the People Directory
• Change type, such as salary, hourly rate, allowance, or correction
• New compensation value
• Effective date and target payroll period
• Reason code from an approved list
• Cost center or department
• Supporting authorization, when required
• Business justification
• Confirmation that the submitter is authorized to initiate the request

The form confirmation message stated that a request had been received and that submission did not guarantee processing in the selected payroll period. It displayed the resulting request ID when the interface configuration supported it, or the acknowledgment email supplied the ID shortly afterward.

Conditional form visibility improved usability, but Zapier repeated all required-field checks after submission. This prevented a request from bypassing validation through an imported record, configuration change, or incomplete form submission.

Duplicate prevention used a potential-duplicate key based on employee ID, change type, effective date, and target pay period. Because Airtable does not enforce unique constraints, matching records were sent to manual review rather than automatically deleted. A legitimate correction can look like a duplicate and must not be discarded without review.

The privacy notice explained the purpose of collection, authorized recipients, storage systems, retention policy, and the instruction not to use email for sending omitted sensitive values. Legal and privacy owners should approve the actual notice.

Step 3: Create the System of Record

1. Create the seven tables described in the data-structure section.

2. Set the primary field of Payroll Change Requests to the formula-based Request ID. Preserve a separate formula field containing RECORD_ID() for integration use.

3. Create controlled single-select options for Status, Approval Status, Priority, Exception Type, Automation Status, Change Type, and Cutoff Result. Remove free-text status fields.

4. Create linked-record relationships to People Directory, Pay Periods, Approval Steps, Documents, Change Log, and Automation Runs.

5. Set defaults:

   • Status: Submitted
   • Approval Status: Pending
   • Priority: Normal
   • Automation Status: Pending
   • Retry Count: 0

6. Create a Last Modified Time field that watches only workflow-relevant fields. Create separate decision-specific modified-time and modified-by fields in Approval Steps. This helps prevent unrelated note edits from triggering decision processing.

7. Create filtered operational views:

   • Ready for Intake Automation
   • Validation Exceptions
   • Past Cutoff Review
   • Pending Manager Approvals
   • Pending HR Approvals
   • Pending Payroll Approvals
   • Approved for Entry
   • Pending Verification
   • Reminder Due
   • Escalation Due
   • Stale Automation Runs
   • Failed Document Transfers
   • Pending Completion Notifications

8. Restrict direct editing of calculated fields, external IDs, automation flags, and audit fields. Only authorized payroll users may enter the payroll external reference. Only the designated verifier may record verification.

9. Configure interface pages so managers see only Approval Steps where the assigned approver matches the current authenticated user. Remove confidential fields and document links from manager pages unless compensation policy explicitly requires them.

The Change Log table is append-oriented but not an immutable ledger. Airtable administrators may retain broad administrative capability. Where formal regulations require tamper-evident or immutable evidence, the design should use a suitable records-management or payroll platform rather than representing Airtable as an immutable audit system.

Step 4: Connect the Tools

All core integrations used OAuth connections. Credentials were not placed in form fields, Airtable records, Zap filters, email templates, or Google Docs templates.

Airtable attachment URLs can be temporary. Zapier copied each attachment to Google Drive immediately after validation rather than storing the temporary download URL as the long-term document reference.

Each external action stored its returned identifier before the workflow advanced. On a retry, the Zap checked for the existing Drive folder ID, file ID, acknowledgment timestamp, approval-step ID, or completion-summary ID before creating another object.

Step 5: Build the Core Automation

Automation 1: Validate and Route a New Request

• Trigger: New Airtable record in the Ready for Intake Automation view
• Conditions: Automation Status is Pending and the event key has not already completed
• Actions: Create automation-run record, set Processing, validate identity and fields, evaluate cutoff, assign owner, create or locate Drive folder, transfer files, create approval steps, write change log, send acknowledgment
• Fields updated: Owner, Status, Priority, Cutoff Result, Drive Folder ID, Document Link, Automation Status, Last Automation Run
• Notification: Requester acknowledgment and first approver action notice
• Exception: Invalid requests enter Validation Exception; technical failures remain visible through the stale-run reconciliation process

The exact action order was:

1. Read the Airtable record and linked directory and period values.
2. Build event key airtableRecordId:intake:v1.
3. Search Automation Runs for the event key.
4. Stop if a completed run exists.
5. Create or update the run as Processing.
6. Verify authenticated submitter against People Directory.
7. Check allowed request type for the selected form.
8. Check required conditional fields and documents.
9. Search for potential duplicate requests.
10. Evaluate cutoff and effective date.
11. Read Routing Rules for owner, approval sequence, folder category, and verification rule.
12. Search Google Drive for an existing request folder.
13. Create the folder if its ID is absent and no matching folder exists.
14. Loop through attachments and copy them into Drive.
15. Create one Documents record for each copied file.
16. Create linked Approval Steps in sequence.
17. Activate only the first required approval step.
18. Update the request’s status and next-action due date.
19. Append a Change Log record.
20. Send the requester acknowledgment.
21. Send the first action notice.
22. Mark the automation run and request automation status as Completed.

Automation 2: Process an Approval Decision

• Trigger: New or updated Approval Step where Decision Modified Time changed
• Conditions: Step was Pending, actor matches assigned approver or active delegate, and event key is new
• Actions: Validate actor, record decision, update request, append change log, activate next approval or return/reject request
• Fields updated: Approval Step status, decision actor, decision time, request status, owner, due date, approval summary
• Notification: Next approver, requester when more information is required, or HR after rejection
• Exception: An unauthorized decision enters Approval Exception and is not accepted

The event key combined the approval record ID and decision-modified timestamp. This allowed a corrected decision to produce a new event while preventing a replay of the same update.

Automation 3: Prepare Manual Payroll Entry

• Trigger: Request updated to Approved for Entry
• Conditions: All required approval steps are Approved, required documents have successful Drive IDs, and cutoff disposition is resolved
• Actions: Assign payroll owner, set entry deadline, add item to payroll entry view, send action notice
• Fields updated: Owner, Next Action Due, Approval Status, Last Automation Run
• Notification: Payroll specialist receives a link to the restricted record
• Exception: Missing approval or document moves the request to Manual Review rather than allowing entry

Zapier did not send payroll values to the payroll application. The specialist opened the approved Airtable record and restricted Drive documents, entered the change in the payroll application, and recorded the returned batch or transaction reference in Airtable.

Automation 4: Verify and Complete

• Trigger: Verification Decision changes on a request in Entered Pending Verification
• Conditions: External System ID is present, verifier is authorized, and verifier differs from the person who entered the change when separation of duties is required
• Actions: Create completion summary, store it in Drive, update status, append audit event, queue completion email
• Fields updated: Completion Summary ID, Status, Completed At, Notification Status
• Notification: Generic completion notice to requester and controlled payroll mailbox
• Exception: Failed verification returns the request to Approved for Entry with a discrepancy reason

Automation 5: Reconcile Stale or Partial Runs

• Trigger: Scheduled Zap running on business days
• Conditions: Automation run is Processing beyond the allowed interval, or required external identifiers are missing
• Actions: Mark run Failed, set request to Automation Exception, increment retry count, notify support owner
• Fields updated: Automation Status, Error Message, Retry Count, Exception Type
• Notification: Operational alert without payroll values or documents
• Exception: Items exceeding the configured retry limit remain in the manual recovery queue

Step 6: Add Approvals, Reminders, and Escalations

Approval routes were defined in the Routing Rules table rather than embedded separately in each Zap.

Approvals were sequential because later reviewers depended on prior policy checks. Parallel approvals were reserved for cases where two independent reviews could occur without exposing unnecessary information. For example, HR policy review and budget review could run in parallel only if the organization formally accepted the resulting timing and privacy implications.

Approval emails did not contain approval buttons that could be forwarded. They directed the approver to an authenticated Airtable interface. The workflow checked the decision actor against the assigned approver or approved delegate.

Reminder rules were:

• First reminder one business day after assignment when no decision was recorded
• Second reminder on the next-action due date
• Escalation one business day overdue or earlier when the payroll cutoff was near
• Daily payroll-entry reminder between approval and the entry deadline
• Immediate escalation if a required verification remained incomplete near payroll lock

A scheduled Zap ran on weekdays. Holidays and exceptional processing schedules were maintained in the Pay Periods table rather than inferred by the automation.

An unavailable approver was handled through a documented delegate field and effective dates in the People Directory. HR could reassign an approval using an administrative interface. Reassignment recorded the original approver, new approver, actor, timestamp, and reason.

A rejection closed the pending approval chain and set the request to Rejected. A return for information paused downstream approvals and assigned ownership to HR, payroll, or the requester. After corrected information was reviewed, the workflow created a new approval event rather than erasing the prior decision.

Step 7: Add Documents and File Management

The Drive hierarchy used fixed permission roots:

Payroll Change Requests
  Bank-Tax
    2026
      2026-07-31
        PCR-20260721-X4K9Q2
  Compensation
    2026
      2026-07-31
        PCR-20260718-Q7M2B8
  Benefits-Deductions
    2026
      2026-07-31
        PCR-20260720-R5T1N6

Folder names used the request ID and did not include employee names, bank names, salary values, tax identifiers, medical conditions, or other sensitive details.

Files were renamed using a controlled pattern:

{{Request ID}}_01_Submission_{{YYYYMMDD}}.pdf
{{Request ID}}_02_Authorization_{{YYYYMMDD}}.pdf
{{Request ID}}_03_Approval-Summary_{{YYYYMMDD}}.gdoc

Each category folder inherited permissions from its parent. Zapier did not create ad hoc public sharing links. Managers generally did not receive document access. If a manager needed a compensation document, access was provided through the compensation security group rather than by forwarding the file.

A file was considered transferred only after Google Drive returned a file ID and Zapier created the corresponding Documents record. After verification, the staging attachment could be removed from Airtable according to the approved data-minimization policy. If removal was enabled, it occurred only after the Drive file ID had been confirmed.

Duplicate files were identified using the request ID, document category, original file name, size, and available checksum information. A possible duplicate was not overwritten automatically. A replacement was uploaded as a new version or separately named file, and the previous document remained available according to retention policy.

File-size limits were tested using the actual Airtable, Zapier, and Google Workspace subscriptions. Oversized files entered Document Exception with instructions to use an approved secure transfer method. Sensitive documents were never requested as ordinary Gmail attachments.

Retention, legal hold, and archival periods were defined by HR, payroll, legal, and privacy owners. If Google Vault or another records-management control was required, its availability and coverage had to be validated separately.

Step 8: Add Reporting and Operational Views

Airtable Interfaces provided the operational dashboard. Each audience received a different interface:

• HR intake: New, incomplete, benefit, compensation, and requester-response queues
• Payroll: Banking, tax, deduction, approved-for-entry, and verification queues
• Managers: Only approvals assigned to the current authenticated manager
• Controller: Compensation approvals and verification items within the controller’s remit
• Automation owner: Failed runs, stale runs, missing file IDs, and pending notifications
• Leadership: Aggregated counts and processing times without confidential change values

Processing time was calculated from Created Date to Completed At. Separate duration measures were maintained for approval waiting time, payroll-entry time, and exception time so that a single average did not hide the source of delays.

Dashboard refresh was based on live Airtable records. The HR system owner reviewed definitions monthly to ensure that a renamed status or routing rule did not silently remove records from a view.

Step 9: Add Security and Governance Controls

• Least privilege: Employees and managers did not receive broad base access. Interfaces exposed only the records and fields required for their role.
• Field minimization: Complete bank account numbers and tax identifiers were not stored in ordinary text fields. Sensitive values remained in restricted documents or the payroll system.
• Email restrictions: Gmail messages contained no salary values, complete banking data, tax identifiers, medical details, or document attachments.
• Shared-link restrictions: Drive folders inherited controlled group permissions. Public links and unrestricted link sharing were disabled.
• Credential storage: OAuth connections were maintained in Zapier. Credentials were not copied into Airtable or Google Docs.
• Separation of duties: High-risk entries required a verifier who was different from the person performing entry when company policy required maker-checker control.
• Former employee removal: HR offboarding included Airtable, Zapier, Google Workspace, security groups, delegated mailboxes, and shared-drive access.
• Change evidence: Approval actor, timestamp, decision, comment, automation-run key, and external payroll reference were retained.
• Backups: Base snapshots or exports and Drive backup controls were tested according to the organization’s recovery policy.
• Privacy review: Data categories, retention, data location, subprocessors, and breach-response procedures were reviewed before launch.
• Regulatory review: Payroll, tax, employment, privacy, and records-retention requirements were evaluated for the jurisdictions involved.
• AI restrictions: The optional AI step was prohibited from receiving bank data, tax identifiers, compensation values, health information, attachments, or employee names.

Interface filtering and field visibility were tested using an actual manager test account. Administrators attempted direct URLs, search, exports, mobile access, and record navigation to confirm that unauthorized information could not be reached.

Step 10: Deploy and Test

1. Build and test the workflow in the non-production Airtable base, non-production Drive folders, and test Gmail identities.

2. Create at least one sample record for every request type, approval route, cutoff condition, rejection path, and document condition.

3. Run technical tests for duplicate triggers, failed OAuth connections, inaccessible Drive folders, invalid email addresses, and interrupted Zaps.

4. Conduct user acceptance testing with one HR reviewer, one payroll processor, one controller, two managers, and two employee test identities.

5. Verify that managers cannot see unrelated employees, banking requests, tax requests, or restricted documents.

6. Pilot with a limited group and low-risk request categories before enabling banking and compensation changes.

7. Document the production folder IDs, Airtable base identifiers, interface URLs, connected accounts, owners, and recovery procedures in a restricted administrator runbook.

8. Freeze structural changes during the initial payroll cycle. Any urgent change should be documented, tested in the test base, and approved before production deployment.

9. Activate production Zaps in sequence: intake, decision processing, entry preparation, verification, reminders, then reconciliation.

10. Monitor every production request during the first two payroll cycles. Reconcile Airtable requests against payroll entries and completion notices.

11. Maintain a rollback plan that disables Zaps, preserves submitted records, returns processing to a documented manual procedure, and prevents duplicate payroll entry.

12. Provide employees and managers with concise instructions explaining where to submit changes, what not to send by email, and how cutoff dates operate.

Code and Configuration

The core solution did not require custom JavaScript, Python, Apps Script, or direct API calls. Airtable formulas and native Zapier connectors supplied the required behavior. Avoiding custom code reduced the number of credentials, runtime environments, and software dependencies that the internal team had to maintain.

The following Airtable formulas were placed in the Payroll Change Requests table.

Request ID Formula

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

This produces a readable value such as PCR-20260721-X4K9Q2. The full Airtable record ID remains the integration identifier.

Potential Duplicate Key

LOWER(TRIM({Employee ID})) &
"|" &
{Change Type} &
"|" &
DATETIME_FORMAT({Requested Effective Date}, "YYYY-MM-DD") &
"|" &
{Target Pay Period ID}

This formula supports a duplicate search. It does not prove that two records are duplicates, so matching requests enter manual review.

Cutoff Result

IF(
  {Created Date} > {Cutoff At},
  "PAST CUTOFF",
  "ON TIME"
)

The intake Zap independently compares the raw timestamps before routing. The formula is useful for visibility but is not the only enforcement step.

Reminder Due Indicator

IF(
  AND(
    {Status} != "Completed",
    {Status} != "Rejected",
    {Status} != "Cancelled",
    {Next Action Due},
    DATETIME_DIFF({Next Action Due}, NOW(), "hours") <= 24
  ),
  "REMIND",
  ""
)

The scheduled reminder Zap reads a filtered view based on this indicator. Before sending, it checks the current status and previous reminder timestamp again to avoid sending an outdated notice.

Native Zapier Configuration

Zapier interface labels can vary. The required technical sequence is trigger, lookup, validation filter, branch by request type, destination action, returned-ID capture, source update, and error reconciliation.

Configuration Values

AIRTABLE_PRODUCTION_BASE: YOUR_AIRTABLE_BASE_ID
BANK_TAX_ROOT_FOLDER: YOUR_BANK_TAX_FOLDER_ID
COMPENSATION_ROOT_FOLDER: YOUR_COMPENSATION_FOLDER_ID
BENEFITS_ROOT_FOLDER: YOUR_BENEFITS_FOLDER_ID
PAYROLL_NOTIFICATION_MAILBOX: YOUR_EMAIL_ADDRESS
AUTOMATION_SUPPORT_EMAIL: YOUR_AUTOMATION_SUPPORT_EMAIL
DEFAULT_TIMEZONE: YOUR_PAYROLL_TIMEZONE
STALE_RUN_MINUTES: 15
MAX_AUTOMATED_RETRIES: 2

These values should be stored in restricted Zapier configuration fields or controlled routing records. They should not be exposed in employee-facing forms.

Gmail Action Notice Template

Subject: Action required for payroll request {{Request ID}}

A payroll change request requires your review.

Request ID: {{Request ID}}
Request category: {{Change Type}}
Action due: {{Next Action Due}}

Open the authenticated payroll request interface:
{{Authorized Interface URL}}

Do not forward this message or reply with payroll, banking, tax,
benefit, medical, or compensation details.

Testing and Troubleshooting Native Configuration

• Test each Zap with an invented Airtable record before activation.
• Confirm the Airtable trigger returns linked-record and attachment values in the expected structure.
• If an attachment is not copied, inspect whether the temporary file URL was still valid and whether the Zapier identity can write to the selected shared drive.
• If a folder is duplicated, verify that the Drive Folder ID is written before subsequent actions and that the search uses the unique Request ID.
• If an approval trigger repeats, confirm that the trigger watches decision fields rather than fields updated by the Zap itself.
• If messages are duplicated, inspect the event key and acknowledgment timestamp before replaying a failed run.
• Use Zapier task history, Airtable Automation Runs, and Google Workspace activity logs to trace a transaction.
• After correcting a failure, replay only when idempotency fields have been checked. Otherwise, use the documented manual recovery procedure.

Failure Handling and Operational Reliability

The Automation Runs table acted as a practical dead-letter queue for failed workflow events. Records with Failed or Manual Recovery status remained visible until an owner recorded a resolution.

Recovery followed a fixed sequence:

1. Identify the failed stage using Zapier task history and the Automation Run record.
2. Determine whether the external action actually succeeded before retrying.
3. Correct data, access, or credential issues.
4. Preserve existing Drive IDs, document IDs, email timestamps, and approval records.
5. Increment Retry Count and record the recovery actor.
6. Replay the event or run the approved recovery Zap.
7. Verify the destination object and source-record update.
8. Append a recovery event to Change Log.

Automatic retries were limited because repeated messages, folders, or approval steps could create more operational risk than a visible manual exception. Actual connector retry behavior depends on the connected application and Zapier subscription, so it was tested rather than assumed.

A Complete Example

An employee with fictional ID E-1047 submits a banking-change request on July 21, 2026. The requested effective date is July 31, and the payroll cutoff is July 24 at noon in the payroll timezone.

1. The employee signs in to the Airtable intake interface using a corporate identity.
2. The employee selects Banking, Checking, and enters account last four 4821. A signed direct-deposit authorization is uploaded. The complete account and routing data are not entered into ordinary Airtable text fields.
3. Airtable creates record recXXXXXXXXXXXXXX and formula ID PCR-20260721-X4K9Q2.
4. Zapier receives the record ID, authenticated submitter, employee link, request type, dates, target period, acknowledgment, and attachment.
5. The workflow creates event key recXXXXXXXXXXXXXX:intake:v1. No completed event exists.
6. The employee’s authenticated email matches the active People Directory record.
7. The request passes required-field and document checks. A search identifies no open banking request for the same employee, effective date, and pay period.
8. The July 21 submission is before the July 24 cutoff, so Cutoff Result becomes On Time.
9. The Banking routing rule assigns the payroll specialist, selects the payroll-only Drive root, requires payroll approval, and requires second-person verification.
10. Zapier creates Drive folder PCR-20260721-X4K9Q2 under the July 31 bank and tax folder. Google Drive returns a folder ID, which is stored in Airtable.
11. The authorization file is copied to Drive and renamed PCR-20260721-X4K9Q2_01_Authorization_20260721.pdf. A Documents child record stores the Drive file ID.
12. Zapier creates an identity-review approval step and a payroll-approval step. No manager approval is created.
13. The employee receives an acknowledgment containing the request ID and status, but no banking values or attachment.
14. The payroll specialist opens the restricted interface, confirms identity and document completeness, and approves the request.
15. The approval-update Zap validates the decision actor, writes the timestamp and change-log event, and moves the request to Approved for Entry.
16. The payroll specialist manually enters the banking change into the payroll application and records fictional reference PAY-2026-07B-184.
17. The request changes to Entered Pending Verification. A second authorized reviewer compares the payroll entry with the restricted authorization document.
18. The reviewer approves verification. Zapier creates a Google Docs completion summary containing the request ID, approval actor, approval time, external reference, verifier, and completion time.
19. The summary is stored in the restricted Drive folder. Airtable receives the document ID and changes the request to Completed.
20. A generic completion email confirms that request PCR-20260721-X4K9Q2 was processed. It does not repeat the bank name, account type, last four digits, or effective banking details.

If the document upload had failed at step 10, the request would have entered Document Exception. The staging attachment would have remained in Airtable, no payroll approval would have been activated, and the automation owner would have retried the transfer after resolving Drive access.

Implementation Cost

All amounts below are representative planning assumptions, not vendor quotations or verified client costs. Current subscription prices, included features, task limits, taxes, currency, and implementation rates should be confirmed directly with vendors and service providers.

The organization should not assume that an existing or nominally low-cost tool requires no implementation or maintenance. Permission reviews, failed-run handling, testing, documentation, and employee support remain necessary.

Estimated Time and Cost Savings

The model uses the following representative assumptions:

• Monthly workflow volume: 36 requests
• Current active handling time: 42 minutes per request across HR, payroll, and approvers
• New active handling time: 12 minutes per request
• Exception rate: 15 percent
• Exception handling time: 15 minutes per exception
• Monthly maintenance: 3 hours
• Loaded labor cost: $50 per hour
• Recurring software cost: $180 per month
• One-time implementation cost: $9,950

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

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

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

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

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

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

Recovered time does not automatically reduce payroll expense. It may instead provide additional capacity, reduce overtime, shorten turnaround, improve payroll-cycle resilience, or allow the same team to process higher volume without adding administrative effort.

Non-financial benefits include:

• Fewer follow-up emails for missing information
• Clear ownership at each stage
• More consistent cutoff treatment
• Reduced exposure of payroll details through email forwarding
• Better separation between request, approval, entry, and verification
• Faster answers to employee status questions
• More complete audit evidence
• Visible automation failures and exception queues
• Lower dependency on one payroll employee’s inbox and spreadsheet

Readers should replace the modeled volume, handling time, exception rate, maintenance effort, labor rate, software allowance, and implementation cost with their own measured figures.

Adding AI to the Automation

AI was not required for the core payroll workflow. Structured fields, lookup tables, exact identity matching, date comparisons, approval rules, permissions, and status transitions were handled more reliably through deterministic automation.

Potential AI uses include:

• Classifying sanitized free-text exception notes
• Summarizing long, non-sensitive requester explanations
• Suggesting which approved checklist item may be missing
• Grouping recurring exception themes for process improvement
• Drafting a non-sensitive internal summary for human review

AI was not used to approve a salary, reject a request, determine tax treatment, release payroll, change bank information, interpret employment law, or enter information into the payroll application.

The core automation created structured intake, routing, reminders, storage, and audit evidence. AI could only reduce the reading effort associated with a limited amount of unstructured, sanitized text.

The Recommended AI Enhancement

The recommended optional enhancement classified sanitized exception notes and suggested missing checklist items. It ran only after a human or deterministic redaction step confirmed that the note contained no prohibited data.

• Trigger: Airtable request enters the AI Review view with AI Eligible checked
• AI input: Request ID, request category, sanitized note, current status, approved checklist field names, and days until cutoff
• System instruction: Classify and summarize without making approval, payroll, legal, tax, benefit, or eligibility decisions
• Expected output: Structured JSON containing category, summary, missing-field suggestions, urgency suggestion, confidence, and rationale
• Validation: Exact enum checks, allowed missing-field names, confidence range, and maximum text lengths
• Record update: Separate AI Suggestion fields with status Pending Human Review
• Human review: HR or payroll accepts, corrects, or rejects the suggestion
• Low-confidence handling: Confidence below 0.80 goes directly to manual review
• Prohibited data: Names, bank values, tax identifiers, salary values, health details, attachments, passwords, and complete email content
• Failure behavior: Leave the request in the normal human queue without delaying payroll processing

The system instruction was:

You are a payroll request triage assistant.

Analyze only the sanitized metadata and note supplied by the user.
Do not approve, reject, defer, or alter a payroll request.
Do not make payroll, tax, legal, benefit, eligibility, compensation,
banking, or employment decisions.
Do not infer facts that are not present.
Select missing fields only from the supplied allowed checklist.
If the note appears to contain prohibited sensitive data, set
category to "other", set requires_human_review to true, and do not
repeat the sensitive content.
Return only JSON matching the required schema.

The reusable user prompt was:

Request ID: {{Request ID}}
Change category: {{Change Type}}
Current status: {{Status}}
Days until cutoff: {{Days Until Cutoff}}
Allowed checklist fields: {{Allowed Checklist Fields}}
Sanitized note: {{Sanitized Note}}

Classify the note, summarize it in no more than 60 words, suggest
missing checklist fields only when directly supported by the note,
and provide a non-binding urgency suggestion.

The required output schema was:

{
  "type": "object",
  "additionalProperties": false,
  "required": [
    "category",
    "summary",
    "missing_fields",
    "priority_suggestion",
    "confidence",
    "rationale",
    "requires_human_review"
  ],
  "properties": {
    "category": {
      "type": "string",
      "enum": [
        "missing_information",
        "employee_question",
        "cancellation_request",
        "deadline_risk",
        "ready_for_review",
        "other"
      ]
    },
    "summary": {
      "type": "string",
      "maxLength": 500
    },
    "missing_fields": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "maxItems": 10
    },
    "priority_suggestion": {
      "type": "string",
      "enum": [
        "normal",
        "time_sensitive",
        "urgent"
      ]
    },
    "confidence": {
      "type": "number",
      "minimum": 0,
      "maximum": 1
    },
    "rationale": {
      "type": "string",
      "maxLength": 300
    },
    "requires_human_review": {
      "type": "boolean"
    }
  }
}

The AI provider was connected through a Zapier action supporting structured output and an organization-approved account. If the selected provider or connector could not enforce the schema, the AI enhancement would remain disabled rather than accepting unvalidated free-form output.

The Zap validated category and priority against exact permitted values. It also checked that every suggested missing field existed in the request type’s approved checklist. Invalid output set AI Status to Failed Validation and left the ordinary manual process unchanged.

Every AI output was logged separately from human decisions. The human reviewer remained responsible for the final category, request status, follow-up message, approval, and payroll action.

Benefits of the AI Enhancement

The AI-specific benefits were limited to unstructured note handling:

• Less time reading lengthy exception explanations
• More consistent suggested categories for recurring questions
• Faster identification of possible missing checklist items
• Improved theme reporting across sanitized exception notes
• Quicker preparation of an internal summary for human review

AI did not create the main benefits of structured forms, automated folders, approval routing, deadline reminders, access restrictions, or audit logs. Those benefits came from normal workflow automation.

What Remains Rule-Based or Human-Controlled

• Identity matching: Uses authenticated accounts and directory records, not AI inference.
• Required fields: Uses form requirements and deterministic validation.
• Cutoff determination: Uses maintained payroll timestamps and explicit comparison rules.
• Approval routing: Uses controlled routing records and policy thresholds.
• Salary approval: Remains a decision by authorized managers, HR, and the controller.
• Banking approval: Remains a payroll and identity-verification control.
• Tax review: Remains with authorized payroll staff and applicable advisers.
• Benefit eligibility: Remains with authorized HR or benefit administrators.
• Payroll-system entry: Remains a manual action by payroll staff.
• Verification: Remains a human comparison against approved source evidence.
• Rejection and cancellation: Require an authorized human decision and recorded reason.
• Policy exceptions: Require human approval and must not be inferred from prior cases.

These decisions can materially affect pay, taxes, benefits, privacy, or employment records. They therefore remain deterministic or human-controlled even if AI provides administrative suggestions.

Estimating the Additional Value of AI

The AI estimate used the following assumptions:

• Fourteen requests per month contain eligible sanitized notes
• Core manual note review requires four minutes per eligible request
• AI output review requires 1.5 minutes per eligible request
• Fifteen percent of outputs require an additional two-minute correction
• Five percent of calls fail and use the ordinary manual process
• AI usage allowance is $8 per month
• Loaded labor value is $50 per hour

At $50 per hour, 0.43 hour represents approximately $21.50 in additional monthly capacity. After the $8 usage allowance, the modeled net additional value is approximately $13.50 per month.

This modest estimate is intentional. At the representative volume, AI is not the primary business case. Its value could increase if the number and length of exception notes rose, but cost, privacy, correction rate, and human-review time would need to be measured rather than assumed.

Testing Checklist

All testing should use invented employee records and sample documents before any real payroll information is processed.

Ongoing Maintenance

The HR system owner was the primary business owner. The payroll operations lead was the backup owner. A separate automation administrator maintained Zapier connections and technical recovery procedures.

Documentation should include the field dictionary, status model, approval routes, folder IDs, connection owners, Zap inventory, event-key format, recovery instructions, test cases, and data-retention decisions. Every structural change should be tested in the test base before production deployment.

When to Move to Dedicated Software

The Airtable and Zapier implementation should not be replaced automatically. It remains appropriate while its security controls, transaction volume, maintenance effort, reporting, and exception rate remain manageable.

Signs that the business should evaluate dedicated payroll workflow, human capital management, case-management, or custom portal software include:

• Transaction volume grows enough that task usage, queue size, or manual verification becomes difficult to manage
• Multiple legal entities, payroll providers, or countries require materially different workflows
• Formal regulations require stronger immutable audit evidence
• Employee self-service must write directly into payroll through a supported, controlled integration
• Advanced field-level, row-level, or document-level permissions exceed the selected tools
• Exception rates continue to rise despite form and process improvements
• Administrators spend excessive time repairing workflows or maintaining access rules
• The organization requires vendor-backed service commitments or specialized payroll support
• Mobile, offline, multilingual, or accessibility requirements exceed the current interfaces
• A customer-facing or employee-facing portal requires richer case communication
• Data-residency, encryption, retention, or legal-hold requirements cannot be satisfied
• Spreadsheet-style or low-code database performance becomes a constraint
• Advanced audit, analytics, or reconciliation requirements require a dedicated data platform
• Security risk increases because too many people require administrative access

If the payroll application’s native workflow later supports the required request types, permissions, approvals, and evidence, consolidating the process there may reduce duplicate data storage. Migration should preserve request IDs, approval history, document references, and retention obligations.

Implementation Checklist

• Confirm payroll-change categories and business requirements
• Document which decisions remain human-controlled
• Approve Airtable, Zapier, Google Drive, Gmail, and Google Docs for the data involved
• Verify required subscription features without assuming current plan capabilities
• Create production and test accounts
• Define base administrators, reviewers, processors, approvers, and backup owners
• Create restricted shared-drive category folders
• Build the People Directory and Pay Periods tables
• Create the Payroll Change Requests and related tables
• Configure required fields, status values, formulas, links, and defaults
• Build authenticated employee and compensation intake forms
• Add conditional fields and server-side validation
• Configure duplicate detection and manual review
• Define field mappings between Airtable, Zapier, Drive, Docs, and Gmail
• Configure event keys and idempotency checks
• Build new-record and updated-record automations
• Create approval routes by request type
• Configure delegation, rejection, return, and reassignment controls
• Add payroll cutoff dates, reminders, and escalations
• Create document naming, storage, transfer, and retention rules
• Exclude sensitive values and attachments from Gmail
• Create role-specific interfaces and operational dashboards
• Configure automation-run and change-log records
• Add stale-run, failed-document, and pending-notification reconciliation
• Apply least-privilege access and test unauthorized navigation
• Document OAuth connections and connection owners
• Test all request types with invented sample data
• Complete user acceptance testing and a limited pilot
• Prepare rollback, recovery, and manual-processing procedures
• Validate implementation and recurring cost assumptions
• Replace savings assumptions with measured internal figures
• Enable optional AI only after the core workflow is stable
• Prohibit sensitive payroll data from entering the AI step
• Assign primary and backup maintenance owners
• Schedule permission, credential, integration, cost, and exception reviews
• Define the security, volume, maintenance, and compliance criteria that would justify dedicated software