> 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/admin/set-up.md).
# Set Up
### Purpose
This document describes the administrator / integrator process required to configure the Email-to-Checkpoint feature in Didge. It outlines the required form configuration, checkpoint setup, and how checkpoint email addresses are generated and provided for use.
### Overview of Admin Responsibilities
To enable Email-to-Checkpoint, an administrator must:
1. Configure a form with the correct file component and field tag
2. Create checkpoints using that form (typically one per service provider)
3. Retrieve and provide the unique checkpoint email address for each provider
Once these steps are completed, the feature operates automatically.
***
### Step 1: Form Configuration
#### Option A: Use the Global Vendor Reports Form
Didge provides a global form called Vendor Reports, which is already suitable for Email-to-Checkpoint use.
This form may be used without modification.
#### Option B: Create a Custom Form
Administrators may also create their own form using the Form Builder, provided the following requirements are met.
***
### Mandatory Form Requirements
For Email-to-Checkpoint to function, the form must meet two mandatory requirements:
#### 1. File Component
* The form must include a File component
* This component is where emailed attachments will be stored
#### 2. File Component Field Tag
* Open the File component settings
* Navigate to the API section
* Add the following Field Tag:
```
Email.Attachments
```
This tag is required for the server to correctly identify and ingest email attachments.
> Without this tag, Email-to-Checkpoint will not function.
***
### Step 2: Checkpoint Creation
* Using the configured form, create checkpoints as normal within Didge
* Typically, one checkpoint is created per service provider or report type
Examples:
* Pest Control Reports
* Calibration Reports
* Microbiological Testing
* Training Provider Reports
Notes:
* Multiple checkpoints may use the same form
* Each checkpoint remains independent
***
### Step 3: Checkpoint Email Generation
Once a checkpoint has been created:
1. Open the checkpoint
2. In the checkpoint table modal header, locate the email icon
3. Click the email icon to reveal the checkpoint email address
The email address will appear in the format:
```
@mail.didge.io
```
#### Key Details
* The number portion is the Operation ID
* Each checkpoint has a unique email address
* This email is permanently linked to that checkpoint
***
### Step 4: Providing Emails to the Client
The checkpoint email addresses can be:
* Provided to the client by the implementation or service team
* Accessed directly by the client within Didge, if required
Typically, the client is supplied with:
* A list of checkpoint names
* Their corresponding Email-to-Checkpoint addresses
* Instructions to provide each address to the relevant service provider
***
### Runtime Behaviour
Once configured:
* Any email sent to a checkpoint email address
* With one or more attachments (e.g. PDF, Word)
* Will automatically submit those attachments into Didge
* The files are stored against the correct checkpoint
No further admin or user intervention is required.
***
### Admin Process Summary
To establish Email-to-Checkpoint:
1. Ensure the form includes a File component with the email.attachments field tag
2. Create checkpoints using that form
3. Retrieve and distribute the checkpoint email addresses
After setup, the feature operates automatically and continuously.
---
# 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/admin/set-up.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.
