Workflow
Automatically Email New Files in a Folder
A watched folder can start an email workflow when a new file arrives. This is useful for sending finished job reports, approved drawings or customer documents. The folder should have a clear purpose: files placed there are ready for the agreed recipient.
Key takeaways
Use a dedicated folder for approved files.
Match recipients to a trusted job record rather than guessing from a filename.
Record each delivery before allowing a repeat attempt.
Choose a delivery folder, detect each completed new file, check its type and recipient, then send an attachment or an access-controlled link. Record the file ID, version and delivery result so the same event cannot send repeated emails. Keep uncertain delivery attempts in a review queue.
- Place an approved file in the delivery folder
- Check file and recipient
- Check the delivery record
- Send the agreed attachment or link
- Record the outcome and exceptions
Give the folder one clear job
Start with one folder and one document type. An internal working folder often contains drafts, temporary files and incomplete uploads. A separate Ready to send folder makes the trigger easier to understand and test.
Decide whether subfolders count, whether a moved file counts as new, and what happens when someone replaces an existing file. These behaviours depend on the storage service and trigger. Test them in the actual account instead of assuming that every folder watcher behaves alike.
For example, the SharePoint connector documents a When a file is created (properties only) trigger. Its output contains file properties. A workflow that needs an attachment must retrieve the file content separately. Select the current trigger for your library and check its documented limitations.
Use a checked recipient map
Keep a stable job or customer reference with the file. Look up the permitted recipient in your existing job register or CRM. Hold files whose reference is missing or whose recipient is unclear.
A filename can help a person recognize a document, but it should not be the only authority for sending it. Someone can rename a file or include the wrong customer number. Check the document's recorded job ID against the approved delivery record.
| Check | Example rule | If the check fails |
|---|---|---|
| Document status | Approved revision only | Return to the review owner |
| File type | PDF for this delivery workflow | Hold unsupported files |
| Recipient | Matches the approved job record | Ask the job owner to resolve it |
| File readiness | Upload complete and file can be opened | Wait or hold after the agreed timeout |
| Prior delivery | No successful delivery for this file version and recipient | Skip the duplicate event |
Choose an attachment or a private link
An attachment gives the recipient a separate copy. Check its size against the actual mail service limits and confirm that the file is suitable to leave your storage system. A later correction will need a new message or another agreed correction process.
A private link can keep the document in a managed location. Verify access as the intended recipient before using it. A link that works for the workflow owner may fail for a customer. Avoid changing a folder to public access just to make delivery easier.
Keep the subject and message simple: job reference, document name, revision and a contact for questions. This is a transactional delivery workflow; adding marketing recipients or unrelated promotions changes its purpose.
Example: send a completed visit report
Suppose job J-104 has a finished service report and an approved customer contact. A reviewer approves revision 3 and moves it to the delivery folder. This is an illustrative setup, not a customer result.
The workflow reads the job reference, checks the approved revision, retrieves the recipient and checks the delivery log. It then sends the PDF and records the message reference, file version and time. A second notification for the same file finds that record and does not send another copy.
If revision 4 is needed, it goes through review again. Its message identifies it as the corrected report. The earlier delivery remains in the history, which helps the team explain exactly what was sent.
Handle uncertain sends carefully
A successful request to a mail service is different from proof that the recipient opened the message. Label the log with what you actually know: accepted by the mail service, failed, or outcome unknown. Record a later bounce separately when your service exposes it.
A timeout can happen after the mail service accepted the message. Blindly retrying may send it twice. Use a stable delivery key made from the file ID, approved version and recipient. If the provider cannot confirm the first attempt, have the owner check the sent record before another send.
Keep a manual recovery path. The reviewer should see the file, intended recipient, reason for the hold and previous attempts. They should be able to approve a corrected retry without rebuilding the workflow.
Test a small delivery set
Try an ordinary file, a duplicate event, an unfinished upload, an oversized attachment, a missing customer reference and an inaccessible link. Also move an existing file into the folder and replace one with a new revision. Write down the expected result before each test.
Automations For Business can help connect your storage, job records and email service with a review queue and delivery history. Bring one approved example file and a description of who should receive it. Use the downloadable brief to agree the trigger and checks first.
Your ready-to-use checklist
0 of 7 checked
Make the next step clear.
Folder-to-email delivery brief
Free templateSources and notes
Sources checked on October 28, 2026.
- Microsoft: SharePoint connector reference
File-created triggers, file properties and file-content actions.
