Helpdesk Ticket to Lead — Outbound
Extends the Helpdesk Ticket to Lead conversion workflow with an optional outbound webhook step. When an agent converts a helpdesk ticket into a CRM lead they can select an external destination so that the lead data and the full ticket conversation history are also forwarded to an external CRM platform (e.g. Zoho CRM) through an intermediate automation layer such as n8n.
No external API client code lives inside this module. All HTTP dispatching, logging and error handling are handled by the Webhook Hub module.
Features
crm.lead.destination — lightweight configuration model that pairs a friendly name with an outbound webhook.webhook record. Managed under CRM → Configuration → CRM Lead Destinations.
destination_id field on crm.lead — selectable in the conversion wizard so the agent picks the target at conversion time (one lead at a time). Leaving it empty keeps the lead in Odoo CRM only.
sent_to_destination status flag on crm.lead marks whether outbound synchronization has succeeded. Leads with destination and pending status are retried by a scheduled job every 2 hours.
Payload sent to the intermediate layer includes:
Lead fields: name, email, partner name, mobile, phone.
Ticket fields: id, reference number, origin email of the customer, and the full conversation history as an HTML string.
Origin email resolution order: ticket partner email → first received inbound email (message_type_mail = email_received). Left empty if no customer email is found (never falls back to a support agent’s address).
Conversation history is built by get_message_body_with_history() when helpdesk_ticket_mail_message is installed; raw ticket description is the fallback.
Attachment metadata (id, name, MIME type, download URL) for every attachment across all ticket messages.
Webhook failures never abort the lead creation; errors are logged at WARNING / ERROR level and the webhook log in Webhook Hub records the full request and response.
CRM form warning banner: if a lead has destination configured but is still pending synchronization, a warning is displayed to inform users that automatic retry runs every 2 hours.
Configuration
The setup requires three manual steps. Repeat for every external CRM target.
Step 1 — Payload Template
Webhook Hub → Payloads → New
Field |
Value |
|---|---|
Name |
CRM Lead — Ticket to Lead Outbound |
Model |
CRM Lead (crm.lead) |
Content |
(see template below) |
Template content (copy-paste and adjust as needed):
{
"lead": {
"name": {{ record.name | safe_tojson("") }},
"email_from": {{ record.email_from | safe_tojson("") }},
"partner_name": {{ record.partner_name | safe_tojson("") }},
"mobile": {{ record.mobile | safe_tojson("") }},
"phone": {{ record.phone | safe_tojson("") }}
},
"ticket": {
"id": {{ record.helpdesk_original_ticket_id.id | safe_tojson("") }},
"name": {{ record.helpdesk_original_ticket_id.name | safe_tojson("") }},
"number": {{ record.helpdesk_original_ticket_id.number | safe_tojson("") }},
"origin_email": {{ context.get('ticket_origin_email', '') | safe_tojson("") }},
"body_with_history": {{ context.get('ticket_body', '') | safe_tojson("") }}
},
"attachments": {{ context.get('ticket_attachments', []) | tojson }}
}The Jinja2 template context exposes:
record — the crm.lead record just created.
context.get('ticket_body', '') — HTML string with the full conversation history.
context.get('ticket_attachments', []) — list of dicts {id, name, mimetype, url} for every ticket attachment.
context.get('ticket_origin_email', '') — origin email of the customer who opened the ticket (empty string if not determinable).
context.event_type — always "create" for this flow.
Filters: use safe_tojson("") for scalar fields (handles False/None gracefully) and tojson for lists/dicts.
Save.
Step 2 — Webhook
Webhook Hub → Webhooks → New
Field |
Example value |
|---|---|
Name |
n8n — CRM Lead (Zoho) |
Direction |
Outbound |
URL |
|
Allowed Methods |
POST |
Payload |
CRM Lead — Ticket to Lead Outbound |
Custom Headers |
|
Log Retention Days |
30 (0 = keep forever) |
Save, then activate the webhook.
Step 3 — CRM Lead Destination
CRM → Configuration → CRM Lead Destinations → New
Field |
Value |
|---|---|
Name |
Zoho CRM via n8n |
Outbound Webhook |
n8n — CRM Lead (Zoho) (from Step 2) |
Notes |
Contact: ops team / n8n workflow ID: … |
Save, then activate the destination (toggle the Active switch).
Converting a Ticket
Open a helpdesk ticket and click Convert into CRM Lead.
In the conversion wizard, set External Destination to the destination created in Step 3 (leave it empty to create the lead in Odoo CRM only).
Fill in the remaining lead fields and click Save.
The lead is created in Odoo and, if a destination was selected, the webhook fires immediately. Check Webhook Hub → Webhooks → <webhook> → Logs to inspect the request and response.
Credits
Contributors
Juan Manuel Regalado <juanmanuel.regalado@somit.coop>
Maintainers
Som IT Cooperatiu SCCL
1 maintainer
Metadata
1 maintainer
Release files for odoo-addon-helpdesk-ticket-to-lead-outbound 16.0.1.0.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| odoo_addon_helpdesk_ticket_to_lead_outbound-16.0.1.0.1.tar.gz | 13.6 kB | Without provenance | Details |
Release files / odoo_addon_helpdesk_ticket_to_lead_outbound-16.0.1.0.1.tar.gz
| Download URL | odoo_addon_helpdesk_ticket_to_lead_outbound-16.0.1.0.1.tar.gz |
|---|---|
| Size | 13.6 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
a6f8dcdd7d15e5c496381810c8a84b744ec85e42a8ab0996901469b2a53f8488
|
|
BLAKE2b-256 checksum How to use checksums |
2eb947bbf57f7aef513e124fda28737fa8b2ccd652277f9934681b3ab93046ff
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.10.12
|
Security for odoo-addon-helpdesk-ticket-to-lead-outbound 16.0.1.0.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
