En agosto, el equipo de Vantegrate grabó una masterclass con una pregunta concreta. ¿Se puede meter React dentro de Experience Cloud y que corra en los servidores de Salesforce?
La respuesta es sí, y no es un truco de laboratorio. La clase se filmó el 20 de agosto y la pueden ver completa en YouTube.
El título original jugaba con dos significados de Aura. Por un lado era el framework viejo de componentes de Salesforce y por el otro "farmear aura" es verse bien haciendo algo que hasta hace poco parecía imposible.
Los arquitectos Francisco Morales y Josué Mendoza (con Esti en el tramo de templates) lo probaron en una org real. El equipo de Vantegrate lo dejó andando y lo mostró paso a paso.
Qué es Experience Cloud (sin misterio)
Piensen en Salesforce como un edificio interno. Quien vende, quien atiende y quien opera entran con llave.
Experience Cloud es la puerta de afuera de ese edificio. Es la forma de publicar un portal para gente que no es empleada de su empresa.
Esa gente puede ser un cliente, un partner, un proveedor o un técnico tercerizado. Entra, ve solo lo que ustedes le habiliten y trabaja sobre los mismos registros.
Si no existiera este producto, tendrían que armar un sitio aparte. Después tendrían que inventar login, permisos, pantallas e integración para que los datos vayan y vuelvan.
Experience Cloud nació hace más de una década con otro nombre (Community Cloud, y antes como portales de cliente y de partner). En sus primeros años era tosco (lento, rígido, difícil de mirar).
Hace varios años se estabilizó. Hace poco, con la apertura Headless 360 y el soporte multi-framework, el producto volvió a ponerse interesante.
Por qué duele menos que un portal hecho de cero
La ventaja no es "tener una web". La ventaja es no reinventar tres capas que ya existen.
Primera capa: objetos, campos y automatizaciones. Un Flow, un Lightning Web Component, una clase Apex o incluso un agente de Agentforce pueden publicarse hacia afuera.
Segunda capa: el Experience Builder. Es un lienzo de arrastrar y soltar (parecido a armar una página con bloques) donde montan layouts, flujos y componentes.
Tercera capa (la que más pesa): seguridad ya resuelta. Perfiles, Permission Sets, sharing rules y object security viajan con el portal.
Lo que un Flow respeta adentro, lo respeta afuera. Lo que un perfil no puede ver en la org no debería verlo en el site.
Comparen eso con un sitio externo que ustedes tienen que construir, auditar y mantener. Cada permiso nuevo es un ticket y cada objeto nuevo es otra integración.
Si su equipo ya vive en el CRM de Salesforce, el portal no es otro sistema. Es la misma org con otra cara.
Para qué se usa (casos que sí se vieron)
Autogestión de clientes
El caso clásico es un portal donde el cliente se atiende solo. Entra, ve lo suyo y ejecuta un trámite sin llamar a un operador.
En seguros, eso fue ver pólizas, reclamar un siniestro o cambiar un método de pago. El CRM sigue siendo la fuente y el cliente deja de pedir por mail lo que ya está en el registro.
En salud el patrón es el mismo. Catálogo de médicos, cobertura, turnos y consulta de turnos ya dados.
El uso más repetido (el que casi todas las orgs terminan tocando) es el portal de casos. Alguien entra, carga un reclamo y sigue el estado.
Partners, franquicias y pedidos B2B
Un partner no es empleado. Igual necesita cargar oportunidades, ver documentos y seguir un proceso de venta.
Salesforce usa esa idea para su propia red de partners. Ustedes pueden usar la misma idea para franquicias, revendedores o una red de B2B SaaS.
En automotriz el ejemplo es cristalino: la marca tiene el proceso de venta en Salesforce. Quien vende el auto es el concesionario de cada provincia, que no es la misma empresa.
El portal segmenta clientes y negociación para que cada concesionario vea lo suyo. No hay que clonar el CRM: hay que abrir la puerta correcta.
Los portales B2B de pedidos siguen esa lógica, con más reglas. Cada empresa compradora puede tener listas, precios y condiciones propias.
Field Service, contractors y sitios públicos
Si tienen técnicos tercerizados, Field Service se apoya en Experience Cloud. Los contractors entran al portal, toman trabajo y no necesitan una licencia interna clásica.
Después están los sitios públicos o microsites. Landings de campaña, registro a un evento, una URL que muestra un QR a partir de un parámetro.
Eso último es potente y delicado. Pueden publicar algo sin asignar licencia, y también pueden publicar de más.
Lo que no hay que hacer (aunque sea más barato)
En la clase aparecieron atajos. Algunos duraron años y ninguno se banca una auditoría con la cara limpia.
El primero: usar licencias de community para el proceso interno de ventas porque "salen más baratas". Se arman decenas de reglas de colaboración y se evita comprar el asiento interno.
El segundo: un site público con un componente que recibe parámetros por URL. La persona "aprueba" o "ve stock" sin loguearse.
El tercero: un sitio público "bien hecho" de cara al usuario, inseguro por detrás. Muestra stock, pedidos u otros datos sensibles a quien tenga el link.
La tentación existe por una sola razón. Experience Cloud está pensado para ser más barato que una licencia interna.
Cómo se licencia (nombre y apellido, o login)
Salesforce cobra de dos maneras grandes. Usuario nombrado o paquete de logins.
Usuario nombrado es una licencia con nombre y apellido. Esa persona entra todas las veces que quiera y pagan esa persona, mes a mes.
Login es otra lógica: pagan un volumen de ingresos al portal, da igual quién entre. Sirve cuando hay una masa enorme de personas que quizá nunca se logueen.
Hay tres mundos de producto. Customer (clientes y casos), Partner (oportunidades, campañas, venta) y External app o guest user (sitios más abiertos, a veces mezclados con otras nubes).
Las partner suelen ser las más caras porque dan más objetos de venta. Tiene sentido: están más cerca de un usuario interno.
Dentro de community para clientes hay escalones, de Commerce Portal (hasta 100 usuarios sin costo en ciertos contratos) a Customer Community Plus. Plus permite crear y administrar reportes y dashboards, no solo consumirlos.
También existe el autoregistro: la persona se crea la cuenta en el portal y recibe un perfil estándar. Si necesitan más permiso, lo configuran después (o con lógica).
Hace poco, en contratos específicos y a través de algunos partners, el modelo de logins empezó a asomar también para usuarios internos. La idea es mezclar asientos diarios con gente que entra una vez al mes.
Habilitar Digital Experiences no exige licencia, pero asignar usuarios sí. Esa diferencia es exactamente donde empiezan los atajos feos.
Si quieren ver cómo queda un portal bien armado sobre su org, pidan una demo. Sirve más que un recorte de diapositiva.
Aura, LWR y React: tres caminos, no un reemplazo
Acá entra el "farmeo". No todo portal necesita React y la mayoría no lo necesita.
Durante años el camino fue Aura. Aura es un framework propio de Salesforce, con sus etiquetas, su ciclo de vida y su forma de hablar con el servidor.
Un dato de color de la clase: cuando LWC llegó a communities, algunos componentes de carga no andaban. La receta oficial fue meter un Aura dentro de un LWC (doloroso, y real).
Después llegaron los sitios LWR (Lightning Web Runtime). Nacieron más pelados, aceptan Lightning Web Components y usan el mismo runtime que Salesforce usa en su propia documentación.
LWR pide más personalización. A cambio, el cliente refina la página como la quiere, con menos plantilla rígida.
El Builder con templates de Salesforce sigue siendo la primera parada. Point and click, componentes de caja, Flows.
Si eso no alcanza, el siguiente escalón son Lightning Web Components. Es el camino nativo para quien ya labura en la plataforma.
Recién cuando el Builder y LWC se quedan cortos (o cuando el equipo ya tiene React en el bolsillo) entra el multi-framework.
No es un paradigma que reemplace a los otros. Es una válvula para un caso puntual (una pantalla muy custom, un producto que ya existe, un equipo que viene del mundo web y no quiere reescribir todo en LWC).
Esa es la tesis de fondo. Salesforce democratiza el ingreso de developers para que un equipo que no conoce LWC no se vaya a otro proveedor.
Los Salesforce developers no desaparecen. Se suman perfiles que antes quedaban afuera del ecosistema.
Cómo metieron React dentro de un Experience Site
La demo fue deliberadamente guiada. Francisco armó una guía paso a paso (con ayuda de un modelo) y la siguió en una org limpia.
El resultado no fue un mock en la notebook. Fue un componente React publicado en servidores de Salesforce.
Qué tiene que estar prendido en la org
El prerrequisito que más se repite es Hyperforce. Es la infraestructura moderna de Salesforce (la org corriendo en nube pública, no en un esquema viejo).
En Company Information lo chequean por el formato del Instance ID. Si ven un patrón de letras más un número, están bien.
Después habilitan Digital Experiences. El interruptor existe aunque todavía no hayan comprado licencias de community.
Luego, multi-framework. En orgs nuevas suele venir prendido y en otras hay que activarlo a mano.
My Domain y la configuración de Network completan el piso. Sin eso, el site no tiene dirección propia dentro de la org.
Un detalle de empaquetado: esto no se empaqueta como un paquete clásico. Si el plan era armarlo una vez y venderlo en AppExchange, este camino no es ese producto.
Cómo habla React con los datos (sin @wire)
La diferencia de verdad no es el botón lindo. Es cómo el componente pide información.
En LWC, el reflejo es @wire contra Apex o un adapter. En React dentro de Salesforce, ese reflejo no aplica.
El puente es un SDK oficial. Desde React consultan datos con GraphQL (y Apex cuando haga falta).
GraphQL se explica fácil. En vez de armar tres servicios ("dame cuentas", "dame contactos", "dame estos campos"), hacen una pregunta con forma de árbol y el servidor responde justo eso.
Salesforce publica recetas listas. El primer deploy de la clase fue un componente tonto: pedís un nombre de cuenta, busca en la org y la muestra.
Esa receta sirve de molde. Después replicaron un Lightning Web Component que ya tenían, archivo por archivo, pero en React.
Para que el asistente de código no "piense en LWC", cargaron reglas distintas. Nada de wire: sí GraphQL y el SDK.
También sumaron (opcional) el MCP de Salesforce DX en Cursor. No es obligatorio y ayuda a que el agente consulte la org sin inventar comandos.
Trabajaron en una carpeta limpia. Dos comandos crean la estructura del componente React y la configuración de Digital Experience.
En local levantaron Vite y vieron el componente como cualquier app web. Vite es el servidor de desarrollo que recarga la pantalla cada vez que cambian un archivo.
El paso que importa es el deploy a la org. Ahí el site aparece en All Sites, se activa, y React pasa a correr adentro de Experience Cloud.
Josué mostró otro site. Detrás no había un LWC disfrazado, sino React puro: componentes que llaman componentes, estado, interacciones.
Incluso armaron una landing interactiva de Trazzo (el producto de planificación visual del equipo) en menos de una hora. El agente instaló dependencias, conectó la org y publicó.
Eso es el "aura". No es magia: es un stack que el mercado ya conoce, corriendo donde viven los datos.
Guest user, permisos y la parte que no se ve en la demo
Hacerlo público es un check. No es un atajo de seguridad.
Cuando el deploy crea el site, lo activan y en preferencias habilitan el guest user. Ese perfil es el visitante sin login.
Si el componente toca Accounts o Products, hay que dar acceso a ese perfil. La seguridad acá es la de siempre: object security, field security, sharing.
Si hay usuarios logueados, el SDK expone métodos para saber quién es. En la demo, para ir rápido, el componente partió mockeado y público.
Un site típico de Experience se hace público con un check de administración. Este camino también puede tener login: público es una elección, no un destino.
La regla es simple: el framework cambió. El modelo de permisos no.
Piensen en el guest como alguien que entra al hall del edificio. Ve el cartel y no debería ver el archivo de sueldos.
Agentes, Cursor y Agentforce Vibes
La clase no se ejecutó "a mano en la terminal" como hace un lustro. Francisco le pedía al agente que corriera cada comando.
Agentforce Vibes trae una opción para crear sitios React de fábrica. En Dreamforce había un stand que lo mostraba: dos o tres prompts, un portal de ventas, código apareciendo en vivo.
El mensaje para el equipo de agentes de IA es doble. Pueden ir muy rápido y pueden armar un desastre igual de rápido.
Usen el agente para scaffolding, deploy y traducción de un LWC a React. No le pidan que invente el modelo de licencias.
Qué se llevan (y qué hacer el lunes)
Empiecen por el caso de uso, no por el framework. Un portal de casos, un concesionario, un contractor o una landing pública no piden la misma receta.
Después elijan licencia con honestidad (nombrada o login, Customer o partner). Guest solo cuando el contenido puede ser público de verdad.
Tercer paso: Builder y LWC. Si con eso cierran, cierren; React entra cuando hay una pantalla que se escapa o un equipo que ya trae el código.
Si van por React, verifiquen Hyperforce, Digital Experiences y multi-framework. Clonen una receta, cambien el puente de datos, desplieguen y recién ahí personalicen.
El SDK no perdona un permiso mal dado. Lo respeta, y eso es una buena noticia.
La masterclass del 20 de agosto no vende un framework de moda. Muestra que Salesforce abrió la puerta del portal a la forma en que el mundo ya construye interfaces.
Aura sigue existiendo y LWR sigue siendo el camino nativo. React ahora puede vivir en el mismo techo.
Eso, si lo usan bien, es el aura. Si lo usan para ahorrar licencias, es el atajo que ya vimos (y que no conviene repetir).
