Integración de ServiceNow con Salesforce: guía paso a paso
El artículo de Make del 13 de mayo de 2026 propone crear o actualizar un caso de Salesforce a partir de una incidencia de ServiceNow, devolver el identificador del caso y avisar al responsable de la cuenta.
Ese recorrido no constituye por sí solo una sincronización bidireccional completa de todos los campos. Para propagar posteriores cambios desde Salesforce haría falta diseñar otro recorrido y evitar que ambos se realimenten.
Esta adaptación se apoya en la ayuda actual de ServiceNow, Salesforce, filtros y programación, consultada el 27 de septiembre de 2026. No se ha ensayado con instancias empresariales.
Antes de empezar
Necesitas una instancia de ServiceNow con permisos suficientes, una organización Salesforce con acceso API y una cuenta Make. La ayuda de Salesforce advierte que no todas sus ediciones incluyen acceso API: confírmalo con tu administrador.
Para la disponibilidad comercial de ServiceNow en Make, revisa el apartado aplicable de su ayuda oficial y las condiciones vigentes de la página de precios de Make. No se reproduce como conclusión actual el requisito de plan del artículo original. Puedes registrarte en Make mediante nuestro enlace de afiliado. Podemos recibir una comisión si compras a través de este enlace, sin coste adicional para ti.
Preparación editorial: acuerda con los administradores qué campos identifican la cuenta y la incidencia en ambos sistemas. Los nombres personalizados que aparecen abajo son ejemplos, no campos que existan automáticamente.
1. Conecta ServiceNow
Añade ServiceNow > Watch Records y crea la conexión. La ayuda oficial describe una conexión con usuario y contraseña y otra con credenciales OAuth. Sigue el procedimiento autorizado por tu organización; no se presenta una de ellas como garantía universal de seguridad.
En Sub Domain, introduce solo el subdominio de la instancia. Para equipo.service-now.com, sería equipo. No incluyas el dominio completo si el campo solicita únicamente esa parte.
Selecciona la tabla incident. El módulo vigila registros creados o actualizados. Esta guía utiliza su ejecución programada; configurar una Business Rule con webhook sería una variante distinta, no una opción que deba suponerse incluida en el mismo módulo.
2. Filtra las incidencias pertinentes
Coloca un filtro en la conexión después del disparador. No es un módulo independiente. Define la condición con los valores reales de tu instancia: por ejemplo, categoría relacionada con clientes y estado que requiera atención.
El original usaba category = customer y state != 6. No copies esos valores sin comprobarlos: las etiquetas visibles y los valores internos de las opciones pueden diferir.
Inspecciona los datos recibidos, en particular sys_id, number, short_description, description, la referencia de cuenta y la prioridad. No des por hecho que tu tabla contiene todos los campos del ejemplo.
3. Busca la cuenta de Salesforce
Añade Salesforce > Search Records (SOQL) y busca el objeto Account mediante la referencia acordada. Un campo externo estable es preferible a una coincidencia aproximada por nombre.
Incluye Id y OwnerId entre los campos devueltos. El primero relacionará el caso con la cuenta; el segundo permitirá asignar la tarea al responsable.
Antes de continuar, exige una coincidencia inequívoca. Si no existe o hay varias, deriva el caso a revisión, no elijas una cuenta al azar. Advertencia de diseño: un router posterior no resolverá por sí solo una búsqueda que produzca cero bundles. Comprueba ese comportamiento. Si necesitas una rama explícita sin resultados, utiliza una consulta mediante Salesforce > Make an API Call que devuelva una respuesta con el array de registros y evalúa dicho array antes de crear el caso.
4. Crea o actualiza el caso
En Salesforce > Create a Record, elige Case. Para ejecuciones repetidas, utiliza Create or Update a Record, el nombre recogido en la ayuda actual, con el campo externo configurado por el administrador.
| Campo de Salesforce | Valor que debe revisarse |
|---|---|
| Subject | short_description |
| Description | description |
| AccountId | Id de la cuenta encontrada |
| Priority | Prioridad transformada a una opción válida de Salesforce |
| Origin | Una opción válida que identifique el origen del caso |
| Campo externo de incidencia | sys_id de ServiceNow |
El ejemplo de campo externo es ServiceNow_Incident_ID__c. Debe existir con la configuración necesaria para identificar el registro. No basta con escribir ese nombre en un texto.
No copies una escala fija de prioridades: acuerda una tabla de equivalencias con los valores reales de ambos sistemas. La creación de un caso y su actualización deben conservar la misma referencia de incidencia.
5. Devuelve la referencia a ServiceNow
Añade ServiceNow > Update a Record, selecciona incident y usa el sys_id original para localizar el registro. Guarda el ID del caso de Salesforce en un campo preparado para ello, por ejemplo u_salesforce_case_id.
Actualizar la incidencia puede volver a hacerla elegible para el disparador. Recomendación editorial: evita volver a escribir valores que ya son iguales y comprueba que la repetición no cree otro caso ni otra notificación innecesaria.
6. Avisa al responsable
Una opción del original es crear una Task en Salesforce. Asigna:
- Subject: el número de incidencia y una descripción clara.
- WhatId: el ID de la cuenta.
- OwnerId: el responsable obtenido en la búsqueda.
- ActivityDate: la fecha de atención acordada.
No supongas que sumar un día natural equivale a sumar un día laborable. Slack o correo son alternativas de notificación, no pasos obligatorios adicionales.
7. Valida antes de activar
Usa una instancia de prueba y una sandbox cuando estén disponibles. Revisa el historial de ejecución, las condiciones del filtro, los campos de salida y la relación entre registros. Prueba una incidencia nueva, una ya procesada y otra sin cuenta coincidente.
Solo después de validar configura la programación y activa el escenario. Los ejemplos de alertas de SLA o renovaciones por activos del artículo original son posibles ampliaciones; no se anuncian aquí como procesos ya implantados.
No prometemos ausencia de duplicados, escalabilidad automática ni un plazo fijo de implementación. Los controles dependen de los identificadores, permisos y reglas que se configuren.