An Airtable time-off request workflow can collect requested dates, record a manager’s decision and preserve later amendments without overwriting the original request. Use a miniExtensions Portal for the employee-facing request history, while managers review staffing needs and policy through a separate staff process.

The useful outcome is a clear answer to three questions: what did the employee request, what has the manager decided, and has a later change been reviewed? This example uses fictional Cedar Studio employees and ordinary time-off dates. It excludes medical explanations, statutory entitlement calculations, payroll processing and legal-compliance claims.

Define the decision the system records

Alex requests 18–20 June away from work. The manager needs to know the dates and a practical handover note, such as “Morgan will cover the weekly client report.” The form does not need a private personal reason. If the organization needs sensitive information for another process, keep that separate and assess the appropriate system and permissions.

Use precise status labels: Submitted, More information needed, Approved, Declined and Withdrawn. Approval in this workflow means a named manager recorded a decision. It does not automatically update a payroll system, confirm a statutory right or create a calendar event.

Create requests without turning the employee profile into a calendar

  • Employees: Employee name as primary text, Work email as email, Team as single select and Manager name as text.
  • Time-off requests: Request reference as primary text; Employee as a linked-record field; Start date and End date as dates; Requested portion as a single select such as Full days or Partial day; Handover note as long text; Request state as single select; Decision date as date; Decision by as text; Employee-facing decision as long text.
  • Amendment requests: Amendment reference as primary text; Employee and Original request as links; Proposed start and Proposed end as dates; Change explanation as long text; Amendment state as single select; Reviewer response as long text.

Use a separate request record for each absence. A single pair of dates on Employees would be overwritten by the next request. For partial days, define an explicit convention and add time fields only if the team needs them. Do not imply that two calendar dates produce a correct working-day balance without accounting for the organization’s schedule and rules.

Configure the employee view around their own requests

Use Time-off requests as the Portal’s Data Table and Employee as the linked User Field. The Users Table setup requires a direct link for each displayed data table, including amendments.

Let employees create requests and read manager responses. Keep the decision fields outside employee editing. Do not expose all employees through a public Interface: the intended experience is individual history with suitable authentication. Configure personal-record filtering for each employee-facing view, then test the linked-record pickers and expanded forms separately.

Keep a normal list or grid view when the same table needs existing-request browsing. The Portal view documentation describes the creation-only Form view and its restrictions. For a manager-facing prototype, staff can work directly in Airtable; this avoids assuming employee relationships automatically create a correctly scoped manager portal.

Put approved requests in a separate history view and route changes through Amendment requests, rather than leaving original values editable. Under the view’s Expand Records settings, turn off Allow users to expand and edit records. The record-editing guide explains that this affects that view, not every access path. Check other views plus creation and unlinking controls. Test that historical values cannot change through any exposed route.

Check dates before deciding

Make both dates required and explain whether the end date is inclusive. A start date after an end date should enter a correction path rather than an approval queue. The Field Validation guide documents that direct comparisons between two fields require an Airtable formula-based approach with Save & Continue, rather than a simple field-to-field validation switch.

For the first version, a staff review can flag reversed dates and missing partial-day details. If formula-backed validation is added later, test saved intermediate records and final submission behavior before relying on it. Validation of input shape cannot decide whether the absence fits policy or whether a project has enough coverage.

The manager reviews Alex’s dates, checks the actual team schedule and records the outcome. “Approved” should appear only after that review. If more context is needed, the employee-facing response should ask a concrete operational question, such as who will complete a handover task, instead of requesting unnecessary personal details.

Preserve approved dates when plans change

Alex later asks to move the absence to 19–21 June. Create an Amendment request linked to the original request rather than allowing the approved dates to change silently. The manager reviews the new dates, records the amendment decision and deliberately updates the current approved arrangement through the team’s chosen process.

Keep the original request and the amendment together so staff can explain the sequence. A simple set of editable records is not an immutable audit log. If formal retention or approval evidence is required, assess those requirements separately and control who can edit completed records.

If the employee withdraws a request that was already approved, the manager should confirm the operational effect and update downstream schedules. A withdrawal flag should not silently reverse payroll entries or remove a calendar event unless a separate integration has been designed, authorized and tested.

Make the handoff visible and test the edge cases

Give the manager a queue of Submitted requests and Pending amendments. Review overlapping dates in context rather than automatically declining a second request. Two employees being away together may be acceptable in one team and problematic in another. The responsible person owns that staffing decision.

Before launch, use two fictional employees to test a new request, reversed dates, a partial-day request, a declined request, an approved request and an amendment. Check that neither user can see the other’s details, select the other’s original request or change decision fields. Confirm that a saved amendment remains pending until a manager acts.

Finally, publish the reviewed extension configuration before sharing its end-user URL; the sharing guide distinguishes saved configuration drafts from published changes. These are suggested acceptance checks, not tests performed for this article. The workflow fits teams needing request visibility and explicit decisions, while dedicated HR and scheduling systems remain responsible for more complex policy, balance and payroll needs.