El 28 de mayo, Vantegrate dedicó su masterclass de los jueves a un tema que hace poco sonaba a ciencia ficción: armar integraciones entre Salesforce y otros sistemas hablando en lenguaje natural.
La clase completa está en YouTube. Miren el replay para ver la demo en vivo y las respuestas del chat.
JuanMa condujo junto a Francisco (Fran), Josué (Josu) y Esteban (Esti).
Josu lideró la parte técnica. Fran y Esti aportaron el contraste de proyectos reales y la lectura de roles.
El hilo conductor fue claro. Con MuleSoft Vibes y vibe coding, los equipos pueden bajar tiempos de integración sin armar monstruos difíciles de mantener.
Por qué los proyectos se achicaron
Josu abrió con una reflexión que cruzó toda la clase. Si hace unos años alguien les decía que esto iba a ser posible, muchos hubieran dicho que era mentira.
Los proyectos ya no llegan como implementaciones de un año. Hoy llegan acotados: dos, tres o cuatro meses, con presión de ver algo andando rápido y salir a producción en plazos cortos.
Fran sumó su mirada. En implementaciones clásicas de Salesforce con integración a SAP, un equipo podía estimar ocho a doce meses, con developers de Salesforce, gente de integración y gente de SAP.
Eso no desapareció del todo, pero el patrón que ven es otro. Las empresas esperan hacer más con menos gracias a la IA, y la plataforma de Salesforce empuja fuerte en esa dirección.
Fran aclaró que no todas las plataformas se sienten igual. Salesforce da mucho margen para acelerar; en otros stacks (por ejemplo Oracle) el ritmo puede ser distinto.
Esa conversación deja una pregunta abierta para próximas clases: cuál es el futuro del admin, del developer, del analyst y del arquitecto cuando el coding se acelera tanto.
Qué problema resuelve MuleSoft
Antes de entrar a Vibes, Josu ordenó el concepto de middleware. En casi todo proyecto, Salesforce necesita traer o mandar datos a otros lados.
El ejemplo más frecuente fue SAP: productos (SKUs), precios, descripciones.
A veces llega por IDoc, a veces por REST, a veces por integración nativa. Además puede haber una base de clientes local, con o sin API en el medio.
MuleSoft se coloca al medio. Se conecta con SAP, con bases de datos, con lo que haga falta, y a Salesforce le llegan productos, clientes o novedades de pedidos sin que la org tenga que guardar credenciales para todos lados.
Eso históricamente obligaba a sumar un equipo de MuleSoft. Había developers de Salesforce y, aparte, alguien que uniera los cables.
Si trabajan en el ecosistema de Salesforce, ese patrón les va a resultar familiar. La integración deja de ser un apéndice y pasa a ser parte del entregable en plazos cortos.
De Agentforce Vibes a MuleSoft Vibes
En Dreamforce (el anterior al de la clase) hubo mucho énfasis en los stands de integraciones.
Salesforce ya venía con Agentforce Vibes. Después apareció MuleSoft Vibes.
La promesa es simple de decir y difícil de lograr a mano: le hablás y te construye la API.
Josu lo bajó a tierra con un dolor real de proyectos. SAP manda XML con campos densos.
Salesforce se lleva mejor con JSON (y a veces con CSV para cargas masivas). Ahí nace la fricción.
Entonces aparece la ingeniería de mapeo.
Este campo de SAP es un estándar en Salesforce. Este otro es custom y lleva el sufijo __c.
Este es un lookup y en el JSON tiene una forma especial. Todo eso, a mano, come semanas.
Con vibe coding la idea es otra. Les pasan el XML, les pasan la estructura de Salesforce y piden: resolvéme la integración.
La masterclass no buscó ser hiper técnica. Buscó mostrar cómo hacer integraciones simples y escalables, no un monstruito que funciona una sola vez.
Cómo conectar Salesforce con Anypoint
El primer paso práctico es tener una org de Salesforce con Agentforce habilitado. El segundo es tener una org de MuleSoft (Anypoint) a la cual puedan conectar Salesforce.
Para unir ambos universos necesitan un usuario admin de cada lado. En Setup de Salesforce buscan Anypoint Platform Setup y arrancan la conexión (Complete connection).
Salesforce genera una key (tenant key) que identifica la org. Esa key se pega en Anypoint, en Access Management, sección Salesforce, Add Salesforce.
Del lado MuleSoft aparece el dominio de la org (en la demo, una Developer Edition) y un nombre libre (en el vivo usaron algo del estilo MuleSoft Vibes Demo). Anypoint responde con su propia Anypoint Platform Org Key.
Esa segunda key vuelve a Salesforce. Al conectar, queda habilitada la interoperabilidad entre ambos ecosistemas.
El botón que abre habilidades agénticas
Dentro de esa configuración hay un paso clave: habilitar Agentforce en Anypoint Platform. Josu lo llamó el botoncito mágico.
En la práctica, Salesforce le está convidando a MuleSoft las habilidades agénticas de Agentforce. Y al revés: las APIs publicadas en MuleSoft pueden quedar disponibles para que Salesforce las use como actions.
Eso cambia el juego.
Si tienen una API que busca clientes en una base interna, no hace falta escribir Apex que llame a esa API. La exponen como acción y un agente la usa cuando carga un pedido y el cliente no está.
También mencionó opciones adicionales alrededor de Data 360 y acciones invocables dentro de la org. El mensaje central fue: dejar de reinventar integraciones punto a punto cuando ya tienen la lógica en MuleSoft.
Si están armando agentes sobre esas acciones, en agentes de IA pueden ubicar cómo encaja esa capa en una operación real.
Mantenimiento: MuleSoft versus Apex
Fran empujó una pregunta de arquitecto.
En un escenario Salesforce y SAP (sincronizar Product2 con SKUs), ¿cómo se compara el mantenimiento en MuleSoft frente al mismo flujo en Apex?
¿Uno a diez? ¿Uno a veinte?
Josu, que vive el día a día en MuleSoft, fue directo: el mantenimiento es muy bajo cuando la solución corre en Mule.
MuleSoft escucha actualizaciones de precio o descripción e inyecta en Salesforce. No necesitan un Apex que se despierte cada tanto, vaya a SAP, compare y vuelva.
Lo que suele tocarse después es monitoreo: si se cayó la API, si cambió la conexión con SAP, si rotaron la contraseña del usuario que habla con Salesforce. Si agregan un campo nuevo, tocan la API de Mule con el nombre de cada lado.
¿Puede hacerlo un admin sin ser developer?
Hace poco la respuesta hubiera sido no. Con Vibes, Josu dijo que es más accesible, siempre con conciencia: no tirar a producción lo primero que el agente arma.
Ese equilibrio (velocidad + criterio) es el mismo que venimos discutiendo en Salesforce para desarrolladores.
Roles dentro del universo MuleSoft
El chat preguntó si MuleSoft es solo para developers. Josu aclaró que hay roles distintos.
Los admins suelen estar en configuración sensible: recursos internos, bases con data delicada, políticas de quién entra a SAP. MuleSoft se conecta vía VPCs (VPN desde cloud), rangos de IP y controles de acceso.
Los developers hacen el mapeo y la charla entre sistemas (XML de SAP a JSON de Salesforce, por ejemplo).
En su experiencia, muchas veces es la misma persona. A lo sumo hay arquitectos mirando la solución completa y las buenas prácticas.
Una pregunta útil del chat: ¿con conocimiento básico de APIs y Postman es más sencillo siendo admin? Josu: totalmente.
Anypoint Studio, Code Builder y el canvas
Cuando salió MuleSoft, el IDE clásico fue Anypoint Studio. Josu lo describió sin dramatizar: pesado, lento al abrir, consumiendo recursos al levantar APIs y testear conexiones.
Salesforce sumó otra vía: desarrollar MuleSoft desde Visual Studio Code con la extensión Anypoint Code Builder.
En pantalla se ve un canvas parecido a armar flujos en Salesforce.
Arranca, por ejemplo, con un Listener HTTP. Después hay decision branches (como IFs), conectores y pasos hasta devolver un JSON.
Eso es lo que corre tras bambalinas cuando alguien manda un DNI o un email y recibe el cliente. La idea de la clase no fue asustar con el diagrama: fue vibecodear ese flujo.
Para usar MuleSoft Vibes desde Code Builder hay que iniciar sesión en Anypoint Platform. Josu advirtió un detalle de la demo: el login a veces pide varios try again hasta enganchar.
Otro requisito crítico: la org de MuleSoft tiene que estar conectada a una org de Salesforce con Agentforce. Si no, aparece un cartel de que MuleSoft Vibes no está disponible y hay que contactar al admin.
La demo: buscar un contacto por email
La API de la demo era simple a propósito. Josu le pidió a Vibes: quiero una API que reciba un email, busque un Contact en Salesforce y lo devuelva.
Para darle contexto usó Salesforce Inspector y el describe del objeto Contact.
Copió la definición a un JSON de ejemplo. Ni siquiera lo leyó línea por línea: lo dejó como contexto para el agente.
Ese tip es oro para admins. Si entienden un poco de Postman y de objetos, pueden nutrir al agente con la definición real (incluyendo campos custom) sin escribir la integración a mano.
Después desafió al agente: quiero que la API también devuelva el cumpleaños del contacto. Le indicó que la definición estaba en contact.json.
El agente revisó los XML de la lógica, encontró la query, agregó Birthdate y actualizó el armado de respuesta para devolver contact.birthdate.
En el medio apareció el límite de tokens de una org Developer.
Josu contó que Agentforce Vibes venía camino a arancelarse y que en orgs chicas el tope molesta. La recomendación práctica fue esperar un poco y reintentar; sin inventar tarifas ni fechas de pricing.
Segunda API: actualizar el contacto
Con el tiempo encima, pidió otra API: actualizar el Contact en Salesforce usando el ID como identificador y permitiendo mover el resto de campos.
El agente generó un flujo nuevo con un PUT a contacts. Recibe el contact ID, lee el body JSON, arma un array de registros (buena práctica: trabajar siempre como si vinieran muchos) y manda a Salesforce.
En el canvas se vio el patrón de producción: validar que haya ID (si no, error 400), debug de lo que se va a actualizar, try/catch, status 500 con mensaje limpio si falla, status 200 si sale bien.
Sin stack traces gigantes al consumidor. Eso también es buena práctica de integraciones.
En unos 40 minutos de demo entendieron una API, le sumaron un campo y expusieron otra para modificar contactos. Ese es el ritmo que la clase quería mostrar.
Cursor, skills y buenas prácticas
Alguien preguntó si se puede hacer todo con otras herramientas de coding. Josu fue sincero: él desarrolla mucho MuleSoft con Cursor, en modo automático, y después revisa en Anypoint Code Builder.
Cursor no le muestra el flujo gráfico de la misma manera.
Por detrás, MuleSoft termina en XML. Se puede ir por ahí, pero se pierde el point and click del canvas.
También habló de skills de MuleSoft: instrucciones de buenas prácticas para que el agente no arme funciones innecesarias y deje las APIs simples. Las usa en Cursor y se preguntó si también se las puede dar a MuleSoft Vibes.
Sobre el paquete de Code Builder: al instalar Anypoint Code Builder llegan varias subextensiones. Josu trabaja principalmente con ese paquetito, sin sumar un montón de add-ons extra.
Y un dato que a veces se olvida: MuleSoft puede vivir sin Salesforce.
Se vende como middleware que conecta todo (Dynamics, bases, sheets en la nube, SAP). Salesforce lo compró e integró; no es un plugin exclusivo.
Traducciones, contexto y lo que el admin puede aportar
Josu cerró la parte técnica con el tipo de instrucción que más potencia tiene Vibes. No solo pedir endpoints: nutrir con JSONs de definición.
Ejemplo: en el sistema de origen el género viene como 1, 2, 3 (enteros) y en Salesforce tiene que llegar como texto. Le dicen a MuleSoft Vibes cuál es la traducción y el agente arma el mapeo.
Si integran con SAP, pueden pasar la definición de ambos lados. Muchas veces el agente entiende correspondencias (birthday y date of birth, name y first name, email y contact email) sin que les dicten campo por campo.
Eso baja la ingeniería de mapeo que antes comía semanas. Sigue haciendo falta criterio humano, revisión y monitoreo (temas de seguridad y transparencia de datos incluidos).
Costos, Vanguard y lo que viene
Casi al cierre, Analía preguntó por costos. Josu no inventó números: hace falta una org con Agentforce (con la tarifa que Salesforce esté aplicando) y una org de MuleSoft, que no suele ser lo más barato del stack.
La recomendación del equipo: contactar al ejecutivo de cuenta y pedir cotización. Si quieren ver cómo lo encaramos del lado partner, en precios y en agendar demo pueden empezar esa conversación.
Fran también mostró Vanguard, la plataforma de aprendizaje de Vantegrate, con módulo de MuleSoft Developer (lecciones, ejercicios y preparación a certificación). En la clase liberaron access codes vía chat y WhatsApp a cambio de un resumen del artículo de Pulse con un LLM.
Esti anticipó la línea de próximas clases: más de agentes dentro de Salesforce. JuanMa mencionó novedades en el radar (Agentforce Cowork, Marketing Cloud Next y el movimiento hacia un Marketing Cloud basado en Salesforce Core).
Si quieren seguir el hilo de cada jueves, en Pulse publicamos el material de las masterclass. En recursos hay material descargable para profundizar.
El equipo de Vantegrate armó esta clase para una sola idea: con criterio de arquitecto o de developer, más vibe coding, se pueden entregar integraciones serias en tiempos mucho más cortos.
La pregunta ya no es si MuleSoft Vibes existe. Es quién le da el contexto correcto (definiciones, skills, guardrails) para que la API que sale del canvas sea desplegable de verdad.
