Integración de ServiceNow con Salesforce: guía paso a paso
Crea una integración en tiempo real de ServiceNow con Salesforce en Make. Sincroniza incidentes con casos, asigna cuentas y automatiza notificaciones sin código personalizado ni middleware. 
Al final de esta sección tendrás un escenario de Make en funcionamiento que vigila los nuevos o actualizados incidentes en ServiceNow y crea o actualiza un caso correspondiente en Salesforce. Después, escribe el ID del caso de Salesforce de vuelta en el incidente de ServiceNow de origen y notifica automáticamente al propietario de la cuenta de Salesforce. Antes de empezar, confirma que tienes lo siguiente: * Cuenta de Make en el plan Enterprise (requerido para la app de ServiceNow, según la última documentación. * Instancia de ServiceNow con acceso de administrador, ya sea una instancia de desarrollador o una instancia de producción en la que puedas gestionar roles de usuario y obtener la URL de tu instancia, nombre de usuario y contraseña * Cuenta de Salesforce en una edición que incluya acceso a la API REST; no todas las ediciones sirven, así que verifica la tuya antes de conectar * Conocimientos básicos de la estructura de la tabla de incidentes de ServiceNow y de los objetos Case y Account de Salesforce | Solo instancias de prueba y de desarrollo | | OAuth 2.0 (client credentials) | Todos los entornos de producción | Para OAuth 2.0, localiza el campo Sub Domain e introduce solo la parte del subdominio de la URL de ServiceNow. Por ejemplo, si la URL de tu instancia es ‘yourinstance.service-now.com’, introduce solo ‘yourinstance’. La parte ‘.service-now.com’ la añade Make automáticamente. Pega tu Client ID y tu Client Secret en sus campos correspondientes y luego haz clic en Save. Una vez conectado, configura el campo Table como ‘incident’. Esto le indica al módulo qué tabla de ServiceNow debe vigilar. Para el tipo de desencadenador, tienes dos opciones: polling (Make consulta ServiceNow en un intervalo programado) o Webhooks (ServiceNow envía los cambios a Make en tiempo real). Los Webhooks requieren que un administrador de ServiceNow configure una Business Rule saliente, y las instancias gratuitas de desarrollo normalmente no los admiten. Empieza con polling y migra a Webhooks una vez que el escenario esté validado en producción.  | Ambas condiciones deben configurarse con lógica AND para que solo pasen los incidentes abiertos y orientados al cliente. Estos nombres de campo son nombres de API, no las etiquetas visibles que ves en la interfaz de ServiceNow. Esta es una de las fuentes de error de configuración más comunes: el campo etiquetado como "Caller" en ServiceNow es 'caller_id' en la API; "ID" es 'sys_id'. Usa siempre los nombres de API al asignar campos en Make. El paquete de salida del Paso 1 contiene los siguientes campos disponibles para mapear en tu filtro y en todos los módulos posteriores: * 'sys_id', 'number', 'short_description', 'description' * 'caller_id', 'account', 'priority', 'state', 'category' módulo después del filtro. Configura el objeto como 'Account' y consulta por nombre de empresa o por un campo personalizado de ID externo. Los dos enfoques son: | Método de búsqueda | Mejor para | | --- | --- | | Coincidencia por nombre de empresa | Empezar rápidamente; menos preciso | | ID externo personalizado (por ejemplo, 'ServiceNow_Account_ID__c') | Entornos de producción; fiable y exacto | Si tu org de Salesforce ya almacena una referencia de cuenta de ServiceNow como campo personalizado, úsala. La coincidencia por nombre introduce riesgo si los nombres de empresa tienen un formato distinto entre ambos sistemas. Después de este módulo, añade un router para gestionar ambos resultados: * Ruta 1: Cuenta encontrada — continúa con la creación del caso en el Paso 4 * Ruta 2: No se encontró ninguna cuenta — registra los detalles del incidente en un canal de Slack o en una hoja de Google Sheets para revisión manual; no continúes con la creación del casoOmitir la ruta sin coincidencia es un error común. Sin ella, tu escenario fallará en silencio cuando llegue una cuenta no reconocida. La lista completa de módulos de Salesforce disponibles, incluido Search Records, está documentada en la documentación de la app de Salesforce en Make.
Paso 4: Crear o actualizar el caso de Salesforce
El objetivo de este paso es escribir los datos del incidente de ServiceNow en un registro de caso de Salesforce. En la ruta "Cuenta encontrada" de tu router, añade el módulo Salesforce > Create a Record y configura el objeto como 'Case'. Mapea los siguientes campos desde el paquete de ServiceNow: | Campo de Salesforce | Origen | Notas | | --- | --- | --- | | Subject' | short_description' | Asignación directa | | Description' | description' | Asignación directa | | Priority' | priority' | Requiere transformación (ver abajo) | | AccountId' | Id de la cuenta del paso 3 | Crítico: el caso quedará huérfano sin esto | | Origin' | Valor fijo: 'ServiceNow' | Permite filtrar en Salesforce por origen | La escala de prioridad de ServiceNow va de '1' (Crítica) a '4' (Baja); Salesforce espera 'High', 'Medium' o 'Low'. Usa una función de texto de Make o un módulo de tabla de búsqueda entre ambos para transformar el valor antes de que llegue al registro del caso. Sin este paso, el campo de prioridad devolverá error o se rellenará incorrectamente. Para escenarios que se desencadenan de nuevo, en los que el mismo incidente hace que el escenario se ejecute más de una vez, sustituye el módulo Create a Record por Upsert a Record. Configura un campo de ID externo personalizado (por ejemplo, 'ServiceNow_Incident_ID__c') como clave de coincidencia. Esto evita que se creen casos duplicados en ejecuciones posteriores para el mismo incidente.Paso 5: Escribir de vuelta en ServiceNow el ID del caso de Salesforce
Este paso cierra la sincronización bidireccional. Una vez que existe un caso en Salesforce, su ID debe almacenarse en el incidente de ServiceNow de origen. Esto permite a los agentes de soporte ver de un vistazo si existe un caso, sin necesidad de acceder a Salesforce. Añade el módulo ServiceNow > Update a Record y configúralo así: | Campo | Valor | | --- | --- | | Table | incident' | | Record 'sys_id' | Asignado desde el paquete del paso 1 | | Custom field | u_salesforce_case_id' | | Custom field value | Id del caso de Salesforce del paso 4 | El campo 'u_salesforce_case_id' debe crearse en ServiceNow antes de que este paso funcione. Un administrador de ServiceNow puede añadirlo mediante Studio o System Dictionary. El prefijo 'u_' es la convención de nomenclatura de ServiceNow para campos personalizados; cualquier campo que cree tu org llevará automáticamente este prefijo. Una vez hecho esto, cada incidente que pase por el escenario llevará una referencia directa a su equivalente en Salesforce. Los agentes de soporte verán el ID del caso en el registro del incidente; sin búsquedas cruzadas entre plataformas ni idas y venidas entre equipos preguntando si se ha abierto un caso.Paso 6: Notificar al propietario de la cuenta de Salesforce
Una vez que exista el caso en Salesforce, el propietario de la cuenta necesita saberlo. Hay tres formas de gestionar esta notificación: | Método | Mejor para | | --- | --- | | Tarea de Salesforce (recomendada) | Equipos que trabajan en Salesforce; mantiene la acción registrada en la cuenta | | Mensaje de Slack | Organizaciones en las que los equipos de cuentas responden más rápido en Slack que en Salesforce | | Correo electrónico de Gmail o Outlook | Equipos sin Slack o cuando el correo sea el canal de escalado preferido | El enfoque recomendado es un módulo Salesforce > Create a Record configurado con el objeto 'Task'. Mapea los campos así: | Campo de la tarea | Valor | | --- | --- | | Subject' | Nuevo incidente de ServiceNow: ' + 'number' del paquete del paso 1 | | WhatId' | Id de la cuenta del paso 3 | | OwnerId' | OwnerId de la cuenta del paso 3 | | ActivityDate' | Hoy + 1 día laborable | Un aspecto que debes confirmar antes de probar: el campo 'OwnerId' debe devolverse explícitamente en tu consulta Search Records del paso 3. Si no se incluye en los campos que devuelve tu consulta SOQL, no estará disponible en el paquete y la asignación fallará en silencio.Paso 7: Activar, probar y programar el escenario
Antes de habilitar el escenario en producción, valídalo de extremo a extremo con un incidente conocido. En el Scenario Builder de Make, haz clic en ‘Run Once’ y desencadena el escenario usando un incidente real de una instancia de staging de ServiceNow conectada a un sandbox de Salesforce. Esto te permite seguir cada paquete a través de cada módulo sin escribir datos en sistemas de producción. Cuando termine la ejecución, abre el panel de ‘Execution History’ y revisa cada módulo para comprobar: * Indicadores de estado verdes que confirmen una ejecución correcta * Salida del paquete en cada etapa para verificar que los mapeos de campos se han rellenado correctamente * Cualquier descarte por filtro en el paso 2 que pueda estar excluyendo registros de forma inesperadaUna vez validado, configura tu programación de polling. Cada 15 minutos es una cadencia inicial razonable para la mayoría de los equipos; redúcela si tus requisitos de SLA exigen una respuesta más rápida, o amplíala si el volumen de incidentes es bajo y los costes operativos son una preocupación. Para activarlo, cambia el escenario a On y configura los correos electrónicos de notificación de errores integrados de Make en los ajustes del escenario. Así recibirás alertas cuando una ejecución falle, de modo que los problemas no pasen desapercibidos entre ciclos de polling. La guía completa sobre programación y gestión de errores está en la .
Casos de uso comunes para la integración de ServiceNow con Salesforce
El escenario de incidente a caso que has creado en los pasos anteriores es la base. La misma arquitectura —vigilar un registro de ServiceNow, buscar una cuenta de Salesforce, crear o actualizar un registro y notificar a un miembro del equipo— se aplica a una amplia variedad de modelos de negocio y estructuras de equipo. Los dos casos de uso siguientes muestran cómo pequeños cambios en las condiciones del disparador y en los módulos de salida producen resultados notablemente distintos.Caso de uso 1: alertas de escalado de SLA para cuentas empresariales
Una gran empresa de SaaS gestiona decenas de cuentas estratégicas, cada una con un CSM dedicado. Cuando se abre un incidente de prioridad 1 contra una de esas cuentas en ServiceNow, el CSM necesita saberlo en cuestión de minutos, no al final de una reunión diaria. El escenario filtra por 'priority' = '1' y por un campo personalizado del nivel de la cuenta que identifica las cuentas estratégicas. Cuando se cumplen ambas condiciones, crea una tarea de Salesforce de alta prioridad asignada al CSM, envía un mensaje directo de Slack con los detalles del incidente y registra una publicación de Chatter en el registro de la cuenta. El CSM recibe todo el contexto en las herramientas que ya utiliza, sin necesidad de acceso a ServiceNow.Caso de uso 2: vinculación de activos de TI con oportunidades para renovaciones
Un equipo de operaciones de TI hace seguimiento en ServiceNow de elementos de configuración de hardware y software (CI), incluidas sus fechas de fin de vida útil. El equipo de ventas no tiene visibilidad de estos datos, así que el contacto para renovaciones es, como mucho, reactivo. El escenario vigila los registros de CI en los que se ha establecido la marca de fin de vida útil, busca la cuenta de Salesforce correspondiente y crea una oportunidad de renovación con el nombre del activo, el tipo y la fecha de caducidad prevista ya rellenados. El account executive recibe una tarea para iniciar el contacto antes de que el cliente empiece a evaluar alternativas.Buenas prácticas para la integración de ServiceNow con Salesforce
Una integración que opera entre dos plataformas empresariales conlleva un riesgo operativo real. La corrupción de datos, las ejecuciones desbocadas y los incidentes perdidos son modos de fallo previsibles, no casos excepcionales. Las dos prácticas siguientes son los pasos de mayor impacto que puedes dar para diseñar resiliencia desde el principio.Consejo 1: Usa IDs externos para evitar registros duplicados
Los escenarios basados en polling pueden procesar el mismo incidente más de una vez si una ejecución programada se solapa con una ejecución lenta. Para evitarlo, sigue estos pasos: * Crea un campo de ID externo personalizado en el objeto case de Salesforce, por ejemplo 'ServiceNow_Incident_ID__c' * Complétalo con el 'sys_id' de ServiceNow cada vez que se cree o actualice un caso * Usa Salesforce > Upsert a Record en lugar de Create a RecordLa lógica de upsert comprueba si ya existe un registro con ese ID externo antes de escribir: si existe, lo actualiza; si no existe, lo crea. Ejecutar la misma operación dos veces produce el mismo resultado que ejecutarla una vez, así que nunca se crean casos duplicados.