Claude para Salesforce Service Cloud: todas las rutas de conexión en 2026

Resumen

Salesforce y Anthropic anunciaron el 14 de octubre de 2025 que Claude sería un modelo fundacional preferido en Agentforce para sectores regulados. Casi todo el mundo lo interpretó como «Service Cloud ahora funciona con Claude». No es así. La propia página de configuración de Salesforce enumera tres opciones de modelo y sigue recomendando la que ejecuta GPT-4.1, y la opción de Claude ofrece actualmente Haiku 4.5, no Opus.

La ruta que realmente mejoró en 2026 es la dirección contraria. Los servidores MCP alojados llegaron a disponibilidad general el 29 de abril de 2026, Salesforce publicó una guía de configuración para Claude paso a paso cinco semanas después, y ahora se puede hacer que Claude lea, consulte y actualice casos en una org de producción con sus propios permisos aplicados a cada llamada.

Lo que ninguna ruta hace es enviar la respuesta. No hay ninguna herramienta sendEmail, postCaseComment ni replyToCase en todo el catálogo. Cada camino se detiene en «redactado, registrado, listo» y devuelve el envío a una persona o a código Apex personalizado que usted mismo escribe. Esa brecha es exactamente la razón por la que construí la integración con Salesforce de eesel como lo hice: se conecta con Service Cloud, se entrena con sus casos cerrados y realmente puede enviar por 0,40 $ por caso gestionado.

Por qué me importa esto más que a la mayoría

Construyo agentes de IA en eesel, y Salesforce fue la integración que me pidieron antes incluso de lanzarla. Dos de las derrotas más claras en nuestro historial de ventas fueron equipos de soporte del segmento medio que les gustaba el producto y aun así se fueron, porque en ese momento no podíamos conectarnos con su org de Service Cloud. Uno de ellos gestionaba unos 900 casos al mes y nos dijo con franqueza que la falta de soporte nativo para Salesforce era determinante. No se olvidan los tratos que se pierden por falta de un conector.

Así que cuando digo que las rutas de abajo se quedan cortas antes de enviar una respuesta, no es una pulla a la competencia. Es la misma pared con la que pasé meses. Conseguir que una IA lea Salesforce es cosa de un martes cualquiera. Conseguir que cierre el ciclo de un correo dirigido al cliente, dentro del sistema de tickets de Salesforce y sus límites de gobernador, es la parte difícil, y es la parte que casi todo artículo de «conecte Claude a su CRM» se salta.

Primero, lo que ninguna de estas rutas hace

Empiece por aquí, porque esto enmarca todo lo que sigue.

El catálogo MCP alojado de Salesforce está bien construido. El servidor SObject Reads incluye seis herramientas, el servidor SObject All incluye once, y los casos están explícitamente dentro del alcance: los propios ejemplos de prompts de Salesforce incluyen «Dame un resumen de todos los casos abiertos en los últimos 7 días para cuentas del sector de servicios financieros».

Sin embargo, si busca en ese catálogo una forma de responder al cliente, no encuentra nada construido a propósito. Nada de sendEmail. Nada de postCaseComment. Nada de replyToCase. Lo que se obtiene es el genérico createSobjectRecord, que acepta cualquier nombre de objeto y un conjunto de valores de campo. Así que la vía de respuesta es: crear un registro CaseComment o EmailMessage, y esperar que la automatización de su propia org lo detecte y despache algo.

Normalmente no lo hará, y el motivo es una peculiaridad del objeto EmailMessage que sorprende constantemente a la gente.

Crear un EmailMessage registra que existe un correo. No envía ninguno. El campo Status es de solo lectura excepto para la transición de New a Read, así que no puede cambiarlo a «enviado» y darlo por hecho. El envío real es una segunda llamada separada: la acción estándar emailSimple mediante REST, o Messaging.SingleEmailMessage en Apex. Dos llamadas, dos modos de fallo, y logEmailOnSend viene por defecto en false, así que lo que acaba de enviar puede que ni siquiera aparezca en el caso.

Todas las rutas de abajo se detienen en el lado izquierdo de esa brecha. Solo el Apex personalizado o un Flow que usted mismo escriba la cruza.

Las cinco rutas, una junto a otra

Ninguna de estas es un producto «Claude para Service Cloud», porque Salesforce nunca ha lanzado uno. Claude llega a sus casos a través de una de estas cinco puertas, y elegir la equivocada cuesta un trimestre. Si aún está decidiendo si usar la pila nativa siquiera, nuestro resumen de la mejor IA para Service Cloud cubre las opciones ajenas a Salesforce junto a estas.

Ruta 1: cambiar Agentforce a Claude

Esta es la que la gente quiere decir cuando dice «estamos usando Claude en Salesforce», y es un único ajuste para toda la org.

Se encuentra en Setup, bajo Quick Find en Audit, Analytics, and Monitoring, luego Einstein Audit, Analytics, and Monitoring Setup, y luego «Select the Model for Agentforce». La página de Salesforce Select Agentforce Model Option enumera exactamente tres opciones:

• Salesforce Default, que Salesforce recomienda, ejecuta GPT-4.1 para los agentes creados en el nuevo Agentforce Builder y GPT-4o para los antiguos
• AWS-Hosted, que es Anthropic Claude Haiku 4.5 en Amazon Bedrock
• Google Gemini, que es Gemini 3.5 Flash en Vertex AI

Vale la pena detenerse en tres cosas de esa lista. Claude es una opción, no el predeterminado, y la propia recomendación de Salesforce sigue siendo la respaldada por OpenAI. La elección es para toda la org, así que se aplica a todos sus agentes de Agentforce, de Service y de otros tipos, a menos que la anule por agente en Agent Script. Y el modelo detrás de ese interruptor es el pequeño: la opción AWS-Hosted pasó de Claude Sonnet 4 a Haiku 4.5 la semana del 18 de mayo de 2026.

Salesforce es refrescantemente directo sobre el coste de migración de cambiar. De la misma página: «Compared to OpenAI, Anthropic tends to be more sensitive to the nuances in the input payload. Anthropic returns more accurate and reliable responses if the prompts are clear, concise, and thorough.» Incluso enlaza a la documentación de ingeniería de prompts de Anthropic. Léalo tal cual es: sus plantillas de prompt existentes necesitarán volver a probarse, y un cambio de modelo no es un ajuste de configuración que se hace un viernes cualquiera.

Otra advertencia del propio texto de Salesforce, que importa si cambia por motivos de cumplimiento: incluso después de elegir una opción de modelo, tareas específicas como la clasificación de subagentes o las citas pueden seguir usando modelos propiedad de Salesforce. El interruptor no es un cierre hermético, y es una de las limitaciones de IA de Service Cloud que conviene plantear en una revisión de seguridad en lugar de descubrirla después.

Lo que realmente gana

El argumento honesto a favor de esta ruta no es la calidad del modelo, sino el límite de confianza. Anthropic afirma ser el primer proveedor de LLM totalmente integrado dentro del límite de confianza de Salesforce, y la propia documentación de Salesforce lo respalda: en la página Supported Models, solo los modelos de Anthropic y Amazon Nova llevan esa marca. Ningún modelo de OpenAI ni de Google en la lista la lleva.

En concreto, Salesforce afirma que el tráfico permanece dentro de su propia nube privada virtual, va cifrado con TLS 1.2 como mínimo, se conecta a Bedrock mediante AWS PrivateLink, y que los proveedores de modelos no pueden acceder a los datos del cliente y que nada se almacena en Bedrock. Si su revisión de seguridad es la razón por la que la IA está estancada en su org, ese párrafo es la razón para mirar a Claude. Es un argumento mucho más sólido que cualquier benchmark, y hace más por una aprobación de gobernanza de IA que cualquier clasificación de modelos.

Y lo que le cuesta

Las orgs de Government Cloud deberían dejar de leer aquí: la tabla de disponibilidad de Government Cloud enumera Claude Haiku 4.5 y Claude Opus 4.5 como no disponibles.

Ruta 2: elegir un modelo específico de Claude en Prompt Builder, Apex o la Models API

El interruptor de Agentforce le da un modelo. Esta ruta le da ocho, y es la que hay que usar cuando una tarea concreta de gestión de casos merece un cerebro más grande que Haiku.

La nota de Salesforce en la página de configuración explica la vía de escape: aunque Agentforce está limitado a unas pocas opciones de modelo, una acción personalizada que use una plantilla de prompt, Apex o la Models API puede hacer referencia a cualquier modelo gestionado por Salesforce o traído por usted.

Así que una plantilla en Prompt Builder puede ejecutar Opus mientras el propio agente ejecuta Haiku. Esa es la forma sensata de invertir en un modelo más grande: en el puñado de tareas donde la calidad del razonamiento se nota en el resultado, en lugar de en cada turno de cada conversación. Escribir resúmenes de casos es el candidato obvio.

Tres nombres antiguos se han redirigido en lugar de eliminarse. Claude3Haiku ahora apunta a Haiku 4.5, Claude37Sonnet a Sonnet 4.5 desde el 26 de febrero de 2026, y Claude4Sonnet a Sonnet 4.6. Si fijó un nombre de API hace un año, hoy está usando en silencio un modelo distinto.

También hay una vía de traer su propio modelo, disponible en Enterprise, Performance o Unlimited con un complemento Einstein for Sales, Platform o Service. Admite exactamente cuatro proveedores: Amazon Bedrock, Azure OpenAI, OpenAI y Vertex AI. No hay un conector directo de Anthropic, así que traer su propio Claude significa traer su propia cuenta de Bedrock. El incentivo para hacerlo es real: según Salesforce, los modelos BYO consumen un 30 % menos de Einstein Requests que los gestionados.

El límite que atrapa a todos

Aquí está la única cosa que pondría en una nota adhesiva antes de que nadie en su org prometa un resumidor de casos con Claude.

Con el enmascaramiento de datos activado en el Einstein Trust Layer, cada modelo queda limitado a 65.536 tokens de contexto. La ventana de un millón de tokens de Opus 4.8 se reduce a aproximadamente el seis por ciento de sí misma. Para recuperar la ventana completa hay que desactivar el enmascaramiento, que es exactamente la función por la que activó Claude en primer lugar.

Para una carga de trabajo de soporte, eso es un mordisco real. Un caso escalado largo con una docena de intercambios de correo, historial citado y un par de archivos adjuntos superará esos 65k tokens, y el modelo verá en silencio menos del hilo de lo que usted cree. También vale la pena revisar los límites de velocidad por modelo: Haiku 4.5 es el más estricto con 250 solicitudes por minuto, mientras que los Sonnet y Opus 4.6 en adelante tienen 1.000. Para ver la gama de modelos más amplia y lo que cuesta cada nivel fuera de Salesforce, consulte nuestro desglose de precios de Claude.

Ruta 3: servidores MCP alojados, la ruta para la que Salesforce escribió una guía de Claude

Esta es la ruta más nueva y con la que realmente empezaría, porque Salesforce hizo el trabajo de integración por usted y luego escribió las instrucciones.

Los servidores MCP alojados llegaron a GA el 29 de abril de 2026, disponibles para orgs Developer, Enterprise, Performance y Unlimited. El planteamiento de la publicación de GA nombra a Claude directamente: «Whether your users live in Slack, Claude, ChatGPT, or something else entirely, MCP means they can work with Salesforce without switching contexts.» Cinco semanas después, Salesforce publicó su propia guía de configuración de Claude, un auténtico paso a paso para Claude Desktop y Claude Code.

Hay cuatro servidores estándar de SObject, todos desactivados por defecto, y un administrador tiene que activar uno:

Las herramientas del servidor de lectura son getObjectSchema, soqlQuery, find, getUserInfo, listRecentSobjectRecords y getRelatedRecords. El servidor de mutaciones añade createSobjectRecord, updateSobjectRecord y updateRelatedRecord. El propio consejo de Salesforce, que yo seguiría, es empezar con el servidor de solo lectura en un sandbox: «It's read-only, risk-free, and immediately useful.»

Ese servidor de solo lectura ya es suficiente para hacer trabajo útil. Pídale a Claude qué cuentas tienen más casos abiertos esta semana, que extraiga los contactos y oportunidades relacionados, que detecte el patrón detrás de un pico. Es el mismo tipo de valor que una integración de Claude con cualquier otro sistema de registro, salvo que el modelo de permisos es el propio de Salesforce.

El modelo de seguridad es lo mejor

Cada transacción se ejecuta como el usuario autenticado, sin cuentas de servicio anónimas. Se aplican las reglas de CRUD, seguridad a nivel de campo y de uso compartido, y, como dice la publicación de GA, si el agente actualiza un registro, el nombre de esa persona aparece en el registro de auditoría. Existe un scope de OAuth dedicado, mcp_api, que otorga acceso MCP sin conceder las APIs REST existentes.

Salesforce también es honesto sobre dónde terminan las barreras de protección. Las herramientas de la plataforma llevan anotaciones readOnlyHint y destructiveHint, pero la página de mejores prácticas dice llanamente: «Annotations are hints, not enforcement. Not all clients read or respect them.» Las herramientas personalizadas de Flow y Apex son potencialmente destructivas por defecto salvo que usted mismo configure las anotaciones. Ese es el tipo de advertencia que la mayoría de los proveedores esconde, y aprecio que esté en la documentación.

Configurarlo

La lista completa, de la guía Configure Claude de Salesforce:

1. Activar el servidor. Setup, buscar MCP Servers, pestaña Salesforce Servers, elegir un servidor, Activate. Copiar el nombre de API y la URL del servidor.
2. Crear una External Client App. Salesforce es tajante aquí: «Connected Apps aren't supported.» Esto sorprende a quienes llevan una década construyendo en la plataforma.
3. Configurar la URL de callback como https://claude.ai/api/mcp/auth_callback para Claude web y Desktop, o http://localhost:38000/callback para Claude Code.
4. Configurar los scopes de OAuth como mcp_api más refresh_token u offline_access. El scope genérico api es el incorrecto.
5. Marcar Require PKCE y «Issue JWT-based access tokens for named users». Desmarcar las dos casillas de «require secret».
6. Esperar hasta 30 minutos para que la app se propague. Esto está documentado y es real.

Sandbox y producción solo se diferencian por un segmento de URL, /v1/<server> frente a /v1/sandbox/<server>.

En el lado de Claude no hay una tarjeta propia de Salesforce en el directorio de conectores para hacer clic. Salesforce solo aparece ahí dentro de agregadores externos, así que la vía documentada es Añadir conector personalizado, pegar la URL del servidor, pegar la clave de consumidor de la External Client App en OAuth Client ID bajo Advanced settings, conectar. Slack, en cambio, sí tiene una tarjeta propia, lo que dice algo sobre en qué punto de su ciclo de vida está cada integración. El lado de la app de escritorio de esto se cubre en nuestro artículo integración de Claude Cowork con Salesforce.

Espere algo de fricción en el primer intento. Un issue abierto en el repositorio MCP de Anthropic hace seguimiento de un fallo donde OAuth se completa, Salesforce confirma que el token fue emitido, y la primera llamada a la herramienta aun así devuelve «Authorization with the MCP server failed». Varios comentaristas lo reproducen contra orgs de Enterprise en producción. La solución de la comunidad es recortar la sección de seguridad de la External Client App a solo PKCE más JWT para usuarios nombrados, y comprobar que el servidor realmente estaba Activated en API Catalog, en lugar de simplemente presente. Como dice un comentarista: «not a bug, it's a missing setting.»

Agentes de Agentforce como herramientas de Claude

Hay un paso adicional que Salesforce documenta: exponer los agentes de Agentforce como herramientas MCP, de modo que Claude pueda delegar en un agente que ya conoce su org. El propio ejemplo de la documentación es un agente de triaje de soporte que analiza la descripción de un caso, determina su gravedad, sugiere pasos de resolución de problemas e identifica el equipo de enrutamiento. Encaja muy bien con el trabajo de triaje de tickets, y está cerca de lo que el enrutamiento de bots nativo ya intenta hacer.

Dos cosas moderan mi entusiasmo. Solo se admiten los agentes construidos con el nuevo Agent Script Builder, así que los agentes antiguos primero necesitan actualizarse, lo cual es un proyecto propio además de su implementación de Agentforce. Y el tiempo verbal es inconsistente entre las propias páginas de Salesforce: la publicación de GA de abril dice «soon, you'll be able to open up even more possibilities by invoking Agentforce agents via MCP», mientras que la documentación de la herramienta se lee como si ya estuviera en vivo. Trate esta ruta como más nueva y menos estable que los servidores SObject.

Ruta 4: el servidor MCP de DX, que no es el que quiere

Busque «Salesforce MCP server» y aterrizará primero en @salesforce/mcp en GitHub, porque es más antiguo y tiene estrellas. No es la ruta para un proyecto de Service Cloud.

Se ejecuta localmente sobre stdio contra orgs que ya haya autorizado en su portátil, incluye más de 60 herramientas, y Claude Code es un cliente de primera clase documentado con un bloque de configuración para copiar y pegar en el README. Todo bien. El problema es lo que son esas 60 herramientas.

Todo el conjunto de herramientas data es una sola herramienta, run_soql_query, y es de solo lectura. No hay ninguna herramienta para crear registros, ninguna para actualizarlos, ninguna herramienta de Case en ninguna parte. El resto es desplegar y recuperar metadatos, ejecutar pruebas de Apex, asignar conjuntos de permisos, doce herramientas de DevOps Center, y una larga cola de herramientas de orientación de LWC, Aura y móvil que devuelven documentación en lugar de datos de la org.

Así que el servidor DX puede leer datos de producción con SOQL si apunta --orgs a producción, y ese es el techo. No puede crear un caso, publicar un comentario ni enviar nada. Es una herramienta de desarrollo que resulta hablar MCP, y sigue marcada como Beta. Un detalle afilado que conviene conocer si aun así lo usa: DEFAULT_TARGET_ORG se resuelve en cada llamada a herramienta en lugar de fijarse al inicio, así que cambiar su org por defecto altera en silencio a qué org puede acceder el servidor.

Ruta 5: construirlo usted mismo sobre la API

Si nada de lo anterior encaja, lo escribe usted. Esta es la única ruta que cruza la línea de envío, y vale la pena entender la forma del muro antes de dedicarle un ingeniero.

El patrón es: suscribirse a casos nuevos, leer el caso, llamar a Claude, escribir la respuesta, enviarla. Cuatro de esos cinco pasos tienen un límite asociado.

Lectura y disparo. Las lecturas de casos cuentan contra su asignación diaria de API. Enterprise recibe 100.000 llamadas más 1.000 por licencia, así que el propio ejemplo trabajado de Salesforce con una org Enterprise de 15 puestos llega a 115.000 al día. Unlimited y Performance reciben 5.000 por licencia en su lugar. Para el disparador, Platform Events y Change Data Capture comparten un mismo pool de entrega: 25.000 eventos por 24 horas en Enterprise, 50.000 en Unlimited.

Y Change Data Capture le limita a cinco entidades seleccionables para toda la org. Case, EmailMessage, CaseComment, Contact y Account son toda la asignación, sin nada que quede para cualquier otra cosa que su empresa quiera transmitir. Si además estaba planeando automatización de casos sobre el mismo flujo de eventos, ese presupuesto ya está gastado.

Llamar a Claude. Desde Apex tiene 100 callouts por transacción y un presupuesto acumulado de callout de 120 segundos, que se suma en cada llamada dentro de la transacción. El razonamiento agéntico de varios pasos no cabe dentro de una transacción síncrona, así que enseguida pasa a métodos queueable o future.

La que más muerde es la regla de orden. No se puede hacer un callout después de una operación DML pendiente. El diseño obvio, marcar el caso como en progreso, llamar a Claude, escribir la respuesta, es ilegal en Apex. Se reestructura alrededor de esto, pero solo después de haberlo chocado.

Envío. De vuelta al problema de las dos llamadas del principio de este artículo. Crear el EmailMessage para el registro, luego disparar emailSimple para enviar de verdad, limitado a 150 destinatarios y 4.000 bytes por campo de destinatario. El threading es opcional mediante addThreadingTokenToSubject y addThreadingTokenToBody, y sin ello, la respuesta del cliente abre un caso completamente nuevo en lugar de continuar el anterior. Ese es un bug de moral del equipo de soporte, no técnico.

Hay una versión sin código. Flow HTTP Callout más External Services más un Named Credential permite a un administrador llamar a la API de Claude sin Apex, y funciona. Su techo es que las devoluciones de llamada asíncronas son solo de Apex, así que cualquier cosa de larga duración le devuelve al código.

Lo que cuesta realmente

Claude no tiene una partida separada en Salesforce, porque se factura a través del medidor de Agentforce. Y el medidor de Agentforce tiene dos configuraciones que no se parecen en nada.

Salesforce publica ambas: 2 $ por conversación, plano sin importar la complejidad, o Flex Credits a 20 créditos por acción, lo que equivale a 0,10 $ por acción, vendidos en paquetes de 100.000 créditos por 500 $. La propia tabla comparativa de Salesforce sitúa una interacción de gestión de casos en tres acciones.

Lea esa tabla con atención, porque Salesforce está argumentando contra su propia tarificación por conversación. Un intercambio de gestión de casos cuesta 2,00 $ en un medidor y 0,30 $ en el otro. Si está en facturación por conversación para trabajo de soporte, está pagando aproximadamente siete veces lo que cuesta el mismo trabajo con créditos.

Introduzca sus números reales:

Dos cifras que el widget asume y que debería contrastar con su propio contrato. Las acciones por caso son el asunto central, y tres es el ejemplo ilustrativo de Salesforce, no una promesa sobre su org. Y los 2,5 M de Flex Credits incluidos en Agentforce 1 Service a 550 $ por usuario al mes equivalen a 125.000 acciones al año, lo que a 1.200 casos al mes y tres acciones cada uno es algo menos de tres años de margen. A seis acciones cada uno, es menos de un año y medio.

Si está construyendo el caso de negocio y no solo la integración, nuestro desglose de precios de Agentforce y el artículo más largo sobre si Agentforce merece la pena profundizan más en las cuentas de puesto más consumo de lo que haré aquí.

Los precios de puesto subyacen a todo esto

Cada línea lleva la coletilla «precio de partida, se aplican tarifas por transacción», y todo desde Pro Suite hacia arriba se factura anualmente. La opción de Claude necesita Enterprise o superior con Foundations o Agentforce 1, así que el punto de entrada real más barato para Claude en Agentforce es de 175 $ por usuario al mes antes de que se mida una sola acción de IA. La escalera completa de ediciones está en nuestro artículo sobre precios de Salesforce, y el lado de la configuración en coste de configuración de Agentforce.

Con qué se topan realmente los operadores

La documentación le dice qué es posible. Los foros le dicen qué ocurre.

En cuanto al precio, la reacción a la facturación por conversación ha sido constante desde su lanzamiento:

«I just cannot stomach the pricing model. Sure, $2.40 for agent might beat $15 for a human interaction, but it's much, much more expensive than the $.05 - $.10 you'd pay to make the API calls to OpenAI to do the same thing.»

u/Exotic-Sale-3003, Reddit

Ese comentario es anterior al cambio a Flex Credits, y los créditos son la respuesta de Salesforce a exactamente esa objeción. Pero los créditos trajeron su propio problema, que es que el consumo no tiene techo:

«There are currently no native hard caps, circuit breakers, or real-time consumption alerts to automatically halt credit drain. The system prioritizes operational continuity for their servers, leaving the customer exposed to un-capped financial liability.»

Agentforce & Digital Wallet lack hard caps for async loops, Reddit

Vale la pena conocer la mecánica antes de firmar: un comentarista con experiencia en producción explica que «1 action = 20 flex credits in production. Sandboxes are 80% consumption, so in sandboxes, 1 action = 16 flex credits», un buen detalle para quien esté presupuestando a partir de un piloto en sandbox.

En cuanto a fiabilidad, el hilo más agudo que encontré es uno en el que un agente de Agentforce en una cola en vivo hizo lo incorrecto con total confianza:

«The Agent accessed a internal only knowledge article and shared internal instructions on how to cancel the service. Instead of passing to a real human agent to attempt to resolve the issue, and prevent churn.»

u/Interesting_Button60, Reddit

La causa raíz fue una plantilla de prompt que usaba el recuperador predeterminado con acceso a todos los artículos de Knowledge. Eso no es un problema de Claude ni de OpenAI, es un problema de alcance del conocimiento, y es con diferencia la forma más común en que falla un despliegue de IA de soporte. También es la razón por la que no lanzaría un agente a una cola en vivo sin antes hacerlo correr en seco contra casos históricos reales, la misma disciplina que hace segura la automatización de la clasificación de tickets.

El coste de construcción también aparece en las reseñas, y es justo, no demoledor:

«The learning curve is definitely real. It's a powerful platform, but getting a new agent or admin fully comfortable takes time, and the deeper configuration really benefits from someone who already knows the system well. Licensing costs can climb quickly once you start layering on additional features.»

Parth S., Senior Software Engineer, Small-Business, G2

Y de un desarrollador que pasó cinco años en el ecosistema, sobre las restricciones de la plataforma que hacen dolorosa la Ruta 5: «platform limits are silly in 2025 - 6 meg max heap size for a backend transaction?????» (zdware, Hacker News). Describe los mismos límites de gobernador que hacen incómodo un callout de IA de varios pasos dentro de Apex.

Cómo decidiría yo realmente

Cuatro situaciones, cuatro respuestas.

Ya tiene licencias de Agentforce y quiere Claude por motivos de cumplimiento. Active el interruptor AWS-Hosted y vuelva a probar sus plantillas de prompt. La afirmación del límite de confianza es real y concreta, y es el argumento más sólido de toda la asociación. Presupueste un sprint para volver a probar los prompts, no una tarde.

Quiere que Claude ayude a su equipo a trabajar los casos, no a responder a los clientes. Servidores MCP alojados, platform/sobject-reads, en un sandbox. Menos de 30 minutos de configuración, sin acciones medidas, y cada llamada lleva los permisos propios del usuario. Es el mayor valor por hora de cualquier ruta de este artículo, y la que probaría primero un viernes por la tarde. También le dirá más sobre la mezcla real de intenciones de su cola de lo que le diría un panel de control.

Quiere un agente autónomo que cierre los casos de nivel uno de principio a fin. Ninguna de estas rutas le lleva ahí por sí sola, porque ninguna envía la respuesta. O bien construye código Apex personalizado detrás de una herramienta MCP, o compra algo que ya haya cruzado ese muro. El artículo sobre alternativas a Agentforce es el repaso honesto de esa segunda opción, la nuestra incluida.

Es una org de Government Cloud. Claude Haiku 4.5 y Opus 4.5 no están disponibles para usted. Planifique en torno a la opción Salesforce Default, o mire lo que ya cubre la superficie nativa del chatbot de Salesforce.

Un patrón en el que insistiría independientemente de la ruta: empezar en modo borrador. En las llamadas de demostración a las que asisto, los equipos que triunfan casi siempre son los que dejan que la IA actúe como copiloto redactando respuestas sugeridas durante unas semanas, observan qué falla, y luego pasan a la automatización completa una vez que confían en ella. Los que activan todo de golpe son los que terminan en un hilo de Reddit sobre un agente que le pega a un cliente instrucciones internas de cancelación.

eesel AI para Salesforce Service Cloud

Seré directo sobre por qué existe esta sección. eesel solía perder tratos de Service Cloud por la razón más simple posible: no podíamos conectarnos. Construir la integración con Salesforce fue la solución, y se construyó específicamente para cruzar el muro del que trata todo este artículo.

eesel se conecta con Service Cloud, lee casos, contactos y cuentas, se entrena con su historial de casos cerrados y artículos de conocimiento, y luego hace lo que ninguna herramienta MCP estándar hace: redacta y envía la respuesta dirigida al cliente, añade notas internas, actualiza el estado y la prioridad, y enruta a la cola correcta. La configuración se completa en menos de 30 minutos, y no hay ninguna licencia de Agentforce en la cadena. Es el mismo trabajo que la IA en Service Cloud, sin el recuento de acciones medido.

Dos diferencias que importan frente a los medidores anteriores. La facturación es de 0,40 $ por caso gestionado, y un caso es un caso: cada respuesta, cada seguimiento, cada pregunta aclaratoria está incluida en ese único cargo, así que una conversación difícil no cuesta más que una fácil. Y cada implementación empieza simulando contra sus propios casos históricos, así que ve lo que el agente habría dicho en tickets reales antes de que lo vea nunca un cliente. Empiece gratis con 50 $ de uso y sin tarjeta, en los precios de eesel.

Si ya está inmerso en Agentforce y contento, siga así. Si está mirando un puesto de 175 $, un recuento de acciones medido y una vía de respuesta que aún tiene que escribir usted mismo en Apex, ese es el momento en que eesel merece veinte minutos de su tarde.