Outlook to RAG to Trello: a case study of email-to-developer-task delivery
A working path from incoming technical email to an assigned Trello task, with knowledge context and a recorded decision.
We built a workflow that reads a defined Outlook mail window, separates actionable development requests from routine correspondence, resolves the responsible developer, retrieves relevant Acumatica knowledge and sends approved tasks to Trello through n8n. The system also records why a message did or did not become a card.
OUTLOOK → collect and normalize messages
→ AI INTAKE → create task or skip
→ ASSIGNMENT → recipient, customer and solution signals
→ RAG → retrieve relevant knowledge before planning
→ FINAL REVIEW → approved create or skip
→ N8N → Trello card and auditThe problem behind the inbox
Technical work arrived as email threads rather than clean issue tickets. A message could contain a new request, a forwarded request, a correction, a status update or a simple acknowledgement. Creating a card from every message would overwhelm developer boards; missing a genuine request would leave work in an inbox. The workflow needed to make that distinction before it touched Trello.
Assignment added another layer. A customer may have an established owner, a product area may have a specialist, and the people in To or Cc may provide different signals. We needed a process that could use those signals consistently while keeping an operator-readable trail of the decision. An LLM alone was not enough to own board IDs, delivery state and repeat processing.
What we delivered
The active system connects Microsoft Outlook, n8n, a separate Python AI Orchestrator, an Acumatica RAG service and Trello. n8n remains the transport: it collects mail, normalizes technical fields, sends a batch to the decision service, receives compact actions and creates cards on developer boards. The Orchestrator handles semantic task decisions, owner resolution, knowledge retrieval, planning and final review. Trello writes remain in n8n, not in the Orchestrator.
We also kept the older connected n8n path visible in the architecture because it explains the progression: classification, customer and solution matrices, a deterministic RAG lookup before drafting a plan, a compact card payload and an audit update. The active AI-first branch moves semantic decisions into the Orchestrator while leaving technical validation, delivery and traceability explicit. The case describes the working combined system, rather than presenting every staged component as live.
The path of one potential task
A scheduled n8n run reads messages from Outlook Inbox and Archive for its configured window. Normalization extracts stable identifiers, subject, sender and recipients, date and the context of replies or forwards. That information matters because a forwarded technical request may be written by one person and addressed to another; a status reply in the same conversation is not automatically a new task.
The normalized batch reaches the AI Orchestrator. Intake decides whether a message asks for work. If it does, assignment resolution and knowledge lookup run before a planner drafts a compact implementation outline. A final reviewer checks the proposed action. Only an approved create action is returned to n8n for Trello delivery; messages classified as updates, acknowledgements, uncertain requests or unsafe actions leave no create action.
Consider an illustrative request for a change to an Acumatica integration. The workflow can identify the development request, consult ownership signals, retrieve relevant knowledge and produce a card for the chosen developer. The article does not reproduce a real customer email or claim that every ambiguous request is classified perfectly.
Assignment is a business rule, not a guessed name
The system combines the direct recipient, customer ownership, solution ownership, copied recipients and current board load in an ordered decision. Customer and product ownership live in editable matrices; the Python resolver uses synchronized copies rather than placing full matrices inside every model prompt. Trello board and list identifiers are applied only after the developer has been chosen.
A clear direct recipient can be stronger than a general customer or product default. If the signals do not identify a safe owner, the workflow can skip creation instead of putting a task on an arbitrary board. This is a deliberate tradeoff: a skipped ambiguous message can be reviewed, whereas a confidently wrong assignment can cause invisible operational noise.
RAG supplies context before the plan
The Acumatica knowledge service provides reference material for technical planning. Retrieval is a defined step before the plan is drafted, rather than an optional tool call an agent might omit. The planner receives relevant excerpts and can use them to shape a concise task for the developer. This makes the knowledge base part of the workflow, not a separate search page that an operator must remember to open.
Retrieved text is still evidence, not authority to invent product behaviour. When the knowledge is missing or materially off topic and execution depends on it, the safe outcome is to withhold a confident card. Simple administrative or list requests can be evaluated from the email and ownership context without pretending that every task needs a strong RAG match. That distinction prevents both unsupported technical instructions and unnecessary blanket rejection.
A compact Trello card and a separate audit
The developer should receive an actionable card, not a dump of a private email thread or model trace. The compact payload carries a clear task name, short execution context, the chosen destination and relevant labels. The normalized email subject is retained at the end of the visible title, preserving a recognizable link to the request without copying the whole message into Trello.
Decision details live in audit storage. The n8n path records source and delivery status, while the Orchestrator keeps decision traces separately from the card. This separation helps investigate a missed task, wrong owner or failed handoff without exposing raw mail and retrieval output on developer boards. A successful API response from an intermediate service is not, by itself, proof that a Trello card was created.
A real defect changed the action contract
A production audit exposed a precise failure: an update-only message had been recognized as an update by the AI stages, but the Orchestrator's fallback produced a generic new task and allowed it through to Trello. The issue was in the action contract between decision and delivery. Switching to a larger model would not have repaired that path.
We changed the active contract to a binary outcome. Intake must explicitly decide to create a task and final review must explicitly approve that creation. Any update-like, missing, uncertain or unsafe result becomes skip and yields no compact Trello action. The patch passed focused remote regression tests, but the next real scheduled batches still need observation for false positives and missed work. We do not claim that duplicate or classification risk has vanished.
Delivery today and the staged reliability layer
The working production route uses n8n, an asynchronous Orchestrator callback and the existing delivery path. A lightweight ledger helps avoid repeated create actions for already reserved decisions, but an external write can still become ambiguous if a process fails between card creation and acknowledgement. That is why an idempotency design cannot honestly be described as an unconditional no-duplicate guarantee.
We built a more durable outbox design with persisted jobs, action claims and explicit creation acknowledgement, and deployed its code behind an inactive feature gate. Its worker is disabled and the n8n callback has not been cut over. Those pieces are engineering work completed in preparation, not part of the active delivery claim in this case. Their final acceptance requires a controlled end-to-end Trello creation and reconciliation check.
The delivered outcome
The result is a working email-to-task system with a defined division of labour: n8n moves messages and creates Trello cards; the Orchestrator decides, assigns and reviews; RAG brings knowledge into planning; audit storage preserves the decision path. It turns a technical inbox into a more structured developer intake process while retaining human-readable boundaries around what was created and why.
This case demonstrates a delivered integration and the engineering needed to correct a consequential production defect. It does not claim a measured time saving, perfect classification, zero duplicates or that the staged delivery v2 is active. Those claims would require different evidence from the implemented and tested path described here.
The implemented flow
- Outlook window → n8n normalization
- AI decision and owner resolution
- Acumatica RAG → task plan → final review
- Approved create action → n8n → Trello
- Decision and delivery audit
Need to turn a complex inbox or knowledge workflow into a controlled product?
Discuss a project · Explore AI automation · More case studies