Operational automation
Set up the document mapping once. Reuse it next time.
It started with…
Administrative teams generate documents for different records. Rebuilding the same link between Airtable fields and template placeholders makes every run a setup task.
So we built…
An Airtable extension connected to Docupilot, with record selection, template mapping and saved configurations that can be restored for the next run.
Take a look inside
Screen 1 of 6Start with a template
The entry screen gives administrative teams a short, ordered path through document preparation.
What we set out to change
Reduce repeated setup by keeping templates and mappings reusable, with a previous configuration available to restore.
How it is builtData model, code, controls and team ownership
The user journey
- 01
Choose the relevant record set and document template.
- 02
Check the field mapping and generate the required documents.
- 03
Reuse or restore a saved mapping for the next run.
Base structure
| Entity / table | Key fields | Relationships |
|---|---|---|
| Source records | Student or candidate fields used by the template | Mapped fields populate the document payload |
| Mapping backups | Name · JSON value · type · modified time | Saved versions preserve reusable configuration |
| Document templates | Template definition in Docupilot | Template placeholders map to Airtable fields |
Technical implementation
- The extension supports two configured source tables and a shared mapping-backup table.
- Mapping configuration is serialised so that it can be saved and restored.
- The workflow includes individual and batch document generation and download.
Engineering decision
Serialise Airtable field types into a template contract
Adapted from the document generator’s field-type mapping. Select labels, linked IDs and attachment URLs have different representations; missing or unreadable mappings are reported before handoff. Diagnostic reporting is expanded here; the reviewed generator skips those fields. Required-field validation and the server-side document-service adapter remain outside this excerpt.
export function buildTemplatePayload(table, record, mapping) { const payload = {}; const issues = []; for (const [placeholder, fieldId] of Object.entries(mapping)) { const field = fieldId && table.getFieldByIdIfExists(fieldId); if (!field) { issues.push({ placeholder, reason: "missing-mapping" }); continue; } try { const value = record.getCellValue(field); if (value == null) continue; switch (field.type) { case "singleSelect": payload[placeholder] = value.name; break; case "multipleSelects": payload[placeholder] = value.map(item => item.name).join(", "); break; case "multipleRecordLinks": payload[placeholder] = value.map(item => item.id).join(", "); break; case "multipleAttachments": payload[placeholder] = value.map(item => item.url).join(", "); break; default: payload[placeholder] = record.getCellValueAsString(field); } } catch { issues.push({ placeholder, reason: "unreadable-field" }); } } return { payload, issues };}Adapted implementation excerpt
Controls and boundaries
- Document generation transmits selected fields to Docupilot; restrict the field set and service access.
- Credential handling and required-value validation need a dedicated review before presenting this integration as hardened.
Who can contribute
- Administration: select records and approved templates.
- Builders: maintain template mappings and their saved configurations.
- Developers: maintain the integration, error handling and service authentication.
What supports this case
The source repository and the live DocuPilot interface were inspected: template selection, source filters, typed field mapping and mapping backups. No documents were generated or sent during review.