> For the complete documentation index, see [llms.txt](https://docs.didge.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.didge.io/home/email-to-checkpoint/end-user/email-to-checkpoint.md).
# Email-to-Checkpoint
### Overview
Email-to-Checkpoint is a feature in Didge that allows email attachments to be automatically submitted into checkpoints. It is designed to eliminate manual document handling for reports that are commonly distributed via email, while ensuring records are centrally stored, auditable, and consistently managed.
This feature is particularly useful for compliance-driven environments such as food safety, workplace safety, facilities management, and training, where third-party service providers regularly issue reports and certificates.
***
### Use Case Context
In most operations, external service providers send reports by email, such as:
* Pest control service reports
* External calibration certificates
* Training completion records
* Cleaning and GMP reports
* Maintenance or contractor service reports
Traditionally, these documents are manually saved into shared folders (e.g. Google Drive or SharePoint) and later retrieved for audits. Email-to-Checkpoint removes this manual step by automatically capturing attachments directly into Didge.
***
### Checkpoint Model
* A separate checkpoint is created in Didge for each functional report or service provider.
* Each checkpoint represents a single, recurring source of documentation.
Examples:
* Pest Control – Provider A
* External Calibration – Provider B
* Training Provider – Provider C
* Night Cleaning – Provider D
This structure ensures documents are always stored against the correct compliance area.
***
### Unique Checkpoint Email
* Every checkpoint in Didge is assigned a unique email address.
* This email address is permanently linked to that checkpoint.
* It is used solely for ingesting emailed attachments into Didge.
***
### Provider Setup (End-User Action)
From an end-user perspective, setup is minimal:
1. Obtain the unique checkpoint email from Didge.
2. Provide this email address to the relevant service provider.
3. Request that the provider includes this email address in all future report emails.
Providers may continue to:
* Include their usual recipients (site staff, managers, etc.)
* Send reports in their standard formats (PDF, Word, etc.)
* Use their existing email workflows
***
### Email Submission Flow
1. The service provider sends an email containing one or more report attachments.
2. The email is received by site staff as normal.
3. The same email is also received by Didge via the unique checkpoint email.
***
### Automatic Ingestion into Didge
* All attachments in the email are automatically detected.
* Attachments are:
* Uploaded into Didge
* Stored against the correct checkpoint
* Time-stamped and logged for traceability
* No user login or manual upload is required.
Supported attachments typically include PDF and Word documents.
***
### Record Management & Audit Readiness
Once ingested, documents are:
* Centrally stored within Didge
* Consistently organised by checkpoint
* Immediately available for review, verification, and audits
This approach:
* Reduces reliance on email inboxes
* Eliminates manual filing errors
* Improves audit preparedness
* Ensures no reports are missed
***
### Ongoing Operation
* After initial setup, the process is fully automated.
* As long as providers include the Didge checkpoint email:
* Reports continue to be captured automatically
* Checkpoints remain continuously up to date
No further action is required from site users.
***
### Summary
Email-to-Checkpoint streamlines the capture of third-party reports by embedding document ingestion directly into everyday email workflows.
The only action required by end-users is to provide the checkpoint email address to each service provider.
All attachments are then automatically stored, organised, and audit-ready within Didge.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.didge.io/home/email-to-checkpoint/end-user/email-to-checkpoint.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
