Le canal email ingère vos emails entrants et permet à un pipeline de répondre, transférer ou créer des tâches downstream.
Modèle
Deux modules complémentaires :
email_inbound— réception (IMAP)email_outbound— émission (opérateur configuré, ou relai via votre SMTP)
Ils sont indépendants : vous pouvez n'utiliser que le entrant (pour trier sans répondre), ou n'utiliser que le sortant (pour notifier depuis un pipeline déclenché autrement).
Mise en place
- Administration → Email → Boîtes — connecter une boîte IMAP avec ses credentials.
- Mapper la boîte vers un pipeline cible.
- (Optionnel) Configurer un émetteur (SMTP) pour répondre.
Pour les architectures qui veulent rester en contrôle de leurs serveurs mail, betool ne se substitue pas à votre MTA : nous lisons et écrivons via IMAP / SMTP standards.
Ce que le pipeline reçoit
Pour chaque email entrant, un nouvel exchange est créé avec :
exchange.user_message— corps de l'email (HTML → texte normalisé)exchange.email.subject— sujetexchange.email.from— expéditeur normaliséexchange.email.thread_id— identifiant de fil (utile pour le contexte multi-turn)exchange.email.attachments— liste deFileMetadata(pièces jointes parsées)
Pièces jointes
Les pièces jointes sont passées au nœud file_transform pour extraction (texte, OCR si PDF scanné, parsing structuré pour CSV / Excel). De là, votre agent peut les exploiter comme s'il s'agissait de texte natif.
Threads & contexte multi-turn
Si un client répond à une réponse précédente, betool reconnaît le thread_id et restore l'historique du fil dans le contexte de l'agent. C'est transparent pour la conception du pipeline.
Limites connues
- Pas (encore) de support MS Exchange EWS natif (vous pouvez exposer Exchange en IMAP).
- Pas de support Microsoft Graph pour Office 365 (en roadmap).
- Le parsing des emails très anciens (Outlook 2003 RTF imbriqué) peut perdre du formatage.