Integración Jira Salesforce: conecta equipos de desarrollo y ventas en 2026
Un caso de Salesforce y una incidencia de Jira pueden describir el mismo problema desde perspectivas distintas. Esta guía, basada en la publicación de Make del 1 de julio de 2026, propone relacionarlos mediante identificadores y reglas de campos, no copiando indiscriminadamente toda la información.
Requisitos y correspondencias
Prepara un proyecto Jira Cloud, un caso de Salesforce de prueba y un campo que conserve el ID del caso. Necesitas permisos de API y escritura sobre los objetos elegidos. La documentación de Salesforce en Make explica las conexiones disponibles y la necesidad de acceso a la API; la de Jira Cloud Platform explica su token y sus webhooks.
Para la cuenta de Make, precios, planes y cuotas se rigen por la página oficial de precios. Puedes registrarte mediante nuestro enlace de afiliado de Make. Podemos recibir una comisión si te registras a través de este enlace, sin coste adicional para ti.
Documenta la relación entre campos, valores de listas y responsables. Decide qué sistema puede modificar cada campo. Este recorrido se refiere a Jira Cloud; no presupone compatibilidad directa con una instalación privada de Jira ni prescribe abrirla a Internet.
1. Observa los cambios de Jira
Añade Watch Issues y elige expresamente entre la variante periódica y la instantánea. En la primera, configura la programación; en la segunda, prepara el webhook según la documentación. Filtra por el proyecto, el tipo de incidencia y la presencia del ID de Salesforce.
Inspecciona un bundle de prueba para identificar el campo personalizado correcto. No confíes únicamente en su etiqueta visible.
2. Recupera el caso de Salesforce
Si ya tienes un ID de caso válido, puedes obtenerlo con Get a Record. Si necesitas una consulta, utiliza Search Records (SOQL) con criterios que identifiquen unívocamente el registro.
No actualices el primer resultado de una búsqueda ambigua. Trata cero coincidencias y varias coincidencias como casos de revisión; comprueba también cómo continúa el escenario si la búsqueda no emite bundles.
3. Reconoce eventos ya procesados
Como recomendación editorial, utiliza la clave de Jira y la marca temporal del cambio para identificar el evento. Comprueba el estado antes de escribir y marca la actualización como completada después de confirmarla.
No supongas que un almacén de datos elimina registros por una caducidad automática que no hayas configurado. Tampoco basta una consulta previa para impedir carreras entre ejecuciones simultáneas. Conserva una estrategia de conciliación para escrituras cuyo resultado sea incierto.
4. Transforma los campos
Prepara equivalencias que existan en tu organización. Por ejemplo, un estado de trabajo en Jira puede corresponder a un estado operativo del caso, pero el valor exacto debe estar permitido por Salesforce.
Usa filtros y variables para separar reglas. Según la documentación de Router, las rutas no son exclusivas por defecto: si solo debe ejecutarse una, sus condiciones no pueden solaparse.
No conviertas todos los campos numéricos en texto. Respeta el tipo de destino y conserva fechas, identificadores y valores de listas en el formato esperado.
5. Actualiza y notifica
Usa Salesforce > Update a Record con el ID confirmado. Escribe solo los campos acordados y evita reemplazar toda la descripción del caso si contiene información ajena a la integración. Después, envía el aviso al responsable con enlaces a ambos sistemas.
Un comentario interno de ingeniería no debe copiarse automáticamente a un canal visible para el cliente. Si añades sincronización de comentarios, recupera y filtra esos comentarios explícitamente; no asumas que todos aparecen completos en el disparador de incidencias.
6. Construye la vuelta en otro escenario
Para Salesforce → Jira, crea otro escenario con Watch Records o Watch Record Fields, según la necesidad. Una ruta de Router no introduce un segundo disparador independiente en el escenario original.
Filtra cambios que procedan de la propia integración y acuerda la prioridad cuando ambos sistemas se modifican. No prometas una latencia fija: intervienen la programación y los servicios conectados.
Pruebas y recuperación
Prueba un cambio válido, un ID inexistente, un valor de estado no permitido, un evento repetido y una actualización de vuelta. Comprueba los campos finales en los dos sistemas.
Consulta Error handlers y Exponential backoff para la recuperación de errores. No uses precios como fuente de reglas de reintento. Para datos sensibles, revisa permisos y políticas de tu organización; este flujo no certifica cumplimiento normativo.
Las recomendaciones de diseño y verificación son aportaciones editoriales, no una implementación probada por MakeAutomation.
Fuente principal
Artículo oficial de Make. Las referencias técnicas específicas se enlazan en los pasos correspondientes.