# Workflow integration record — blank template

**Planning and verification template. This is not a completed test or acceptance record.**

Complete the fields for the agreed project. Leave results blank until work has been carried out; use “not applicable” with a reason where needed. Agree acceptance criteria before testing. Reference supporting evidence instead of placing passwords, API tokens, personal information or confidential field files in this document.

## 1. Workflow and scope

| Field | To complete |
| --- | --- |
| Project / workflow reference | |
| Prepared by / date / document version | |
| Customer task owner / project contact | |
| Current workflow and problem to solve | |
| Intended outcome and acceptance criteria | |
| Included work and deliverables | |
| Exclusions, assumptions and dependencies | |
| Configuration or deployment record reference | |

## 2. Information handoffs

Describe one handoff per row. Identify what authorizes the next step. Do not assume that an available API supports the target equipment or task.

| Step / task reference | Source → destination | Information and version | Transfer method | Responsible person / reviewer | Trigger / approval for next step |
| --- | --- | --- | --- | --- | --- |
| | | | | | |
| | | | | | |
| | | | | | |

Methods to assess: ☐ Manual review and entry · ☐ Supported file import/export · ☐ Interface or synchronization requiring verification.

| Transfer conditions | To complete |
| --- | --- |
| File format / required fields / naming and task references | |
| Interface documentation / supported products / access conditions | |
| Transfer limitations / validation evidence / fallback procedure | |

## 3. Configuration and compatibility

Record the actual configuration being assessed. Availability, access and compatibility must be checked for the customer’s region and account; tool names alone do not establish compatibility.

| Component / role | Model or software / version | Controller / firmware / licence | Account owner / access role | Region / availability conditions | Compatibility finding / evidence / unresolved condition |
| --- | --- | --- | --- | --- | --- |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |

## 4. Data and access arrangements

| Arrangement | To complete |
| --- | --- |
| Data required and permitted purpose; data not needed | |
| Account administrator, authorized people and least access needed | |
| Storage services, processing location and transfer route | |
| Any cross-border handling and agreed safeguards / notice | |
| Exportable information, format and handover recipient | |
| Retention period, deletion responsibility and project closeout | |
| How project access will be transferred or revoked | |
| Separate authorization, if any, for publication, reuse or model training | |

Data supplied for testing does not by itself authorize other uses. Do not record credentials here.

## 5. Responsibilities and value sources

| Responsibility | Assigned person | Review / approval requirement | Backup or escalation contact |
| --- | --- | --- | --- |
| Prepare field information | | | |
| Review and confirm the task | | | |
| Prepare equipment / execute confirmed task | | | |
| Organize records and investigate discrepancies | | | |
| Maintain configuration and assess changes | | | |

Classify values at field level. A planned quantity is not evidence of actual application; planned area is not completed area. Preserve original source, unit, timestamp and revisions. Multispectral findings require appropriate ground review; an index alone does not diagnose a crop problem or authorize execution.

| Data field | Source class: planned / device record / manual entry / measured | Source reference and timestamp | Unit / conversion rule | Reviewer / discrepancy rule |
| --- | --- | --- | --- | --- |
| | | | | |
| | | | | |
| | | | | |

## 6. Verification and evidence

Adapt the proposed checks below to the agreed scope. Record test inputs, expected behaviour and actual findings separately. Use authorized, appropriately minimized test data. An observed connection alone does not constitute acceptance.

| Test | Suggested check / behaviour to agree | Actual result and date | Evidence reference | Reviewer / open issue |
| --- | --- | --- | --- | --- |
| Correct handoff | Confirm source, destination, task and received content for the agreed transfer method. | | | |
| Field or task mismatch | Present information for a different field or task; confirm detection and the review needed before use. | | | |
| Outdated or changed version | Introduce an older or changed task version; confirm version identification and renewed approval where required. | | | |
| Fields and units | Check required fields; distinguish area, total weight and rate, and verify any conversions. | | | |
| Missing or incomplete file | Remove required information; confirm the missing item is visible and processing follows the agreed recovery procedure. | | | |
| Duplicate import | Repeat a transfer; confirm duplicates are identified and do not silently create a second task or record. | | | |
| Interrupted connection | Interrupt the transfer where applicable; check partial data, retry and recovery without duplicate execution. | | | |
| Unavailable operation record | Check the missing-record procedure; do not substitute planned values for measured or completed results. | | | |
| Access and permissions | Verify intended roles can act and unauthorized roles cannot access or change the tested information. | | | |
| Review and execution approval | Check who may approve the task, how approval is recorded and what changes require renewed approval. | | | |
| Export and handover | Verify the agreed exports and instructions can be used by the receiving person. | | | |

| Evidence reference | Location / access owner | Test configuration and input version | Notes / retention arrangement |
| --- | --- | --- | --- |
| | | | |
| | | | |

## 7. Open items and acceptance decision

| Issue / limitation | Operational impact | Owner | Next action / target date | Closure evidence / reviewer |
| --- | --- | --- | --- | --- |
| | | | | |
| | | | | |
| | | | | |

| Acceptance field | To complete |
| --- | --- |
| Criteria reviewed / supporting evidence | |
| Decision, applicable configuration and permitted use | |
| Conditions, remaining restrictions and deferred work | |
| Customer reviewer / approval reference / date | |
| SpeedyDrone reviewer / approval reference / date | |

A decision applies only to the documented scope and conditions. Leave it blank until the designated people have reviewed the evidence and unresolved items.

## 8. Handover, maintenance and change review

| Item | To complete |
| --- | --- |
| Workflow description and configuration / compatibility records | |
| Test evidence, open items and maintenance notes delivered | |
| Training / handover recipient, reference and acknowledgment | |
| Daily operation owner / records owner / issue reporting route | |
| Maintenance scope, provider responsibilities and excluded work | |
| Licensing, third-party charges and separately agreed support fees | |
| Changes requiring review: equipment, firmware, software, interface, account, region, data format or responsibilities | |
| Change reviewer, re-test criteria and approval before resuming use | |
| Export, access removal and closeout confirmation | |

## Change log

| Document version / date | Change and reason | Author / reviewer | Related re-test or approval reference |
| --- | --- | --- | --- |
| | | | |