Experience Cloud es la forma de publicar un portal de clientes, partners o un sitio público sin un servidor extra y sin rehacer logins, seguridad ni integraciones. Tu empresa expone hacia afuera lo que ya vive en la Org: objetos, Flows, Apex y Permission Sets.
En EGA Futura construimos sobre esa misma plataforma: el ERP es nativo, potenciado por Salesforce. Esta masterclass recorre el producto de punta a punta: de dónde viene, para qué se usa, cómo se licencia, cuándo conviene Aura o LWR, y cómo publicar una app React adentro de Salesforce.
Abajo está el video. Después, el mapa de la clase: qué es Experience Cloud, licencias, templates y la demo de React. Al final, las preguntas frecuentes y la transcripción completa, sin editar.
De dónde sale Experience Cloud y por qué importa ahora?
Experience Cloud no es un producto nuevo. Nació como Community Cloud, pensado para comunidades de usuarios, y durante años fue incómodo de usar. Hacia 2018 se estabilizó. Hoy Salesforce abre la plataforma (Headless, Multi-Framework, React) y el mismo producto cubre portales, microsites y experiencias que antes pedían un sitio aparte.
De Community Cloud a Experience Cloud
Al principio había Customer Portal y Partner Portal, con una distinción B2C y B2B. Después se unificó en Community Cloud y más tarde en Experience Cloud. Los Sites siguen existiendo como pieza, no como el producto entero.
Esa historia sirve para leer un proyecto viejo: si alguien habla de «Communities», es el mismo producto con otro nombre. El licenciamiento y los templates sí cambiaron, y ahí está el riesgo de copiar recetas de 2016 en una Org de hoy.
Qué problema resuelve para tu empresa
Salesforce, por defecto, es un sistema interno. Experience Cloud es la puerta de afuera: el cliente, el partner, el proveedor o el técnico tercerizado entra a un portal y opera sobre los mismos datos.
Sin Experience Cloud, tu empresa arma un sitio, inventa logins, copia seguridad y conecta datos ida y vuelta. Con Experience Cloud, el modelo de datos ya está. Un Flow, un Lightning Web Component o una aprobación de Agentforce se pueden publicar hacia afuera, con la misma capa de perfiles y Permission Sets.
Experience Builder es el lienzo: drag and drop de componentes, layouts y Flows, parecido a armar una página con point and click. Lo más valioso no es el lienzo. Es que la seguridad ya está resuelta.
Consejo: si el proyecto empieza con «hacemos un portal aparte y después lo integramos», paremos ahí. Casi siempre Experience Cloud cubre el caso con menos piezas móviles.
Para qué se usa Experience Cloud en un proyecto real?
Se usa para exponer un proceso de negocio a gente que no es usuario interno. Esa gente suele ser mucha más que el equipo que opera el CRM.
Portal de autogestión de clientes
Es el caso más frecuente. El cliente entra, ve sus casos, sus pedidos, su póliza o sus turnos, y se autogestiona. En la clase se recorrió el ejemplo de una aseguradora: el asegurado gestiona la póliza, declara un siniestro y cambia el método de pago. El de salud es el mismo patrón: catálogo de médicos, turnos, cobertura.
Cuando alguien abre un caso en el portal de Salesforce, está usando exactamente esta idea. No es un sitio de marketing. Es el proceso de tu empresa, publicado.
Partners, franquicias y B2B
El portal de partners es para quien revende, opera una franquicia o carga oportunidades que no son de tu nómina. En la clase se usó el ejemplo de una automotriz: el proceso de venta vive en Salesforce, el concesionario se loguea, ve solo sus clientes y avanza la negociación.
El B2B de pedidos se parece, con reglas por cuenta. Help Center y Knowledge entran cuando tu empresa quiere publicar procesos, preguntas frecuentes y artículos, a veces como parte de otro portal y no como un site suelto.
Técnicos, Field Service y sitios públicos
Field Service se enlaza con Experience Cloud para técnicos contratistas: no son empleados, entran al portal, y el licenciamiento suele ser nombrado, con o sin autoregistro.
Los sitios públicos o microsites cubren landings, registro a eventos y piezas que no deberían consumir licencia: un QR, una página que recibe un Id y muestra un dato. Ahí hay que ser estrictos con Guest User. Un site público que muestra stock o pedidos «porque es más barato» es el atajo que más se ve, y el que más duele en una auditoría.
Consejo: escribamos en una hoja quién entra (cliente, partner, técnico, anónimo) y qué objeto toca. Esa hoja decide la licencia, el template y si hace falta login.
Cómo se licencia Experience Cloud sin pagar de más ni quedar fuera de contrato?
La licencia externa es más barata que un usuario interno. Por eso aparecen recetas que mezclan ahorro con incumplimiento.
Usuario nombrado o logins
Salesforce licencia de dos maneras. Una: una persona con nombre y apellido, mes a mes. Otra: un paquete de logins, da igual quién entre.
Si tu empresa tiene veinte partners que entran todas las semanas, la licencia nombrada es la lectura natural. Si tiene cientos de miles de clientes y la mayoría no entra nunca, pagar por login suele alinear mejor el costo con el uso.
También existe, en algunos contratos, un modelo de logins para usuarios internos esporádicos. No es el default. Hay que leer el papel, no copiar el rumor.
Customer, Partner, External Apps y Guest User
En B2C aparecen tres escalones. En ciertas instancias hay hasta 100 licencias de un tipo de portal sin costo. Arriba, Customer Community, la de toda la vida para casos y autogestión. Arriba de eso, Customer Community Plus: calendario, tareas, eventos y, lo menos intuitivo, informes y paneles. No solo ejecutarlos: crearlos y administrarlos.
Partner Community cubre oportunidades y campañas: quien vende. Suele ser la más cara. External Apps y Guest User cubren el sitio público y algunos cruces con otras nubes (Field Service, y en algunos casos Revenue Cloud). Autoregistro asigna un perfil estándar; los permisos extra se configuran después.
Prácticas que no convienen
En la clase se habló con claridad de atajos que se ven en el mercado. Uno: mover todo el equipo de ventas a Community «porque sale menos» y resolver visibilidad con decenas de reglas. Contractualmente no está permitido. Puede pasar años. Una auditoría lo cae.
Otro: un site público con un componente que recibe parámetros, para que alguien «apruebe» o vea datos sensibles sin licencia. Hoy, con más superficie de ataque, ese camino es peor que hace diez años.
Digital Experience se habilita sin comprar licencias. Eso no autoriza a publicar datos internos en un site anónimo. Habilitar la nube es el primer paso. Asignar quién ve qué es el trabajo de verdad.
Consejo: si el argumento de diseño es «así no pagamos licencias», volvamos al objeto y al perfil. El ahorro que no sobrevive una auditoría no es ahorro.
A mitad de camino: las aplicaciones de EGA Futura ERP corren en la misma Org. Un portal mal abierto no rompe solo Experience Cloud. Rompe la idea de una sola plataforma.
Aura o LWR: qué template conviene en un proyecto nuevo?
El template decide qué componentes salen de caja, qué puede hacer el front y cuánto hay que construir.
Aura: el runtime viejo, todavía en producción
Aura (Aura Components) es la tecnología específica de Salesforce que muchos proyectos arrastran. Tiene más piezas listas. También es el pasado. Un desarrollador front que no vive en el ecosistema no la trae puesta.
Hubo un momento, cuando salieron los LWC para comunidades, en que los componentes de carga de datos no funcionaban y la receta era meter Aura dentro de un Lightning Web Component. Eso es deuda. No es un patrón para copiar hoy.
LWR: el presente
LWR (Lightning Web Runtime) nació como sitio «pelado»: vos ponés Lightning Web Components y customizás. Salesforce usa LWR en su propia documentación de developers. Menos out of the box, más control. Con IA, construir LWC desde cero es más rápido que hace cinco años. Sin IA, un LWR era un proyecto grande.
Build Your Own y Microsite son las variantes que más se mencionan. LWR es el presente y el futuro del producto. Aura sigue donde ya está en producción.
Qué se pierde al ir a LWR
En la clase la respuesta honesta fue: no hay una pérdida de negocio automática. Se cambia de tecnología. Quien viene de Salesforce se siente más cómodo con Lightning Web Components. Quien viene de React se siente más cómodo en React. El criterio no es «LWR es menos producto». Es «qué equipo va a mantener esto en dos años».
Consejo: proyecto nuevo, LWR y Experience Builder. Aura solo si el portal ya existe y el costo de migrar no se justifica.
Cómo se publica React adentro de Salesforce?
Se puede. No es el primer camino. Es el camino para cuando Builder y LWC no alcanzan, o cuando tu empresa ya tiene una app React y no quiere reescribirla.
El orden de decisión
Primero, template y Builder. Segundo, Lightning Web Components. Tercero, React. Ese orden evita un portal «hermoso» que nadie del equipo Salesforce puede mantener, y evita también un LWC forzado cuando el equipo front ya entrega en React.
Hay dos formas técnicas. La clásica, que hoy corre en producción: compilar la app, subirla como static resource y embeberla, con Apex de ida y vuelta. La nueva: Salesforce Multi-Framework, presentada en TDX y en open beta en el momento de la clase. Una app React nativa (Vite, Tailwind, shadcn) como External App, publicada por un sitio de Experience Cloud, consumiendo datos con GraphQL y Apex a través del SDK, con autenticación de la plataforma.
Qué hay que tener en la Org antes de la demo
La Org tiene que estar en Hyperforce. En Company Information, la instancia se ve con un patrón de letras y número (incluido un solo dígito). Digital Experience se habilita en Setup, sin licencia extra. Multi-Framework, en las Orgs de la demo, ya venía activo. My Domain y la red del sitio también tienen que estar.
Después vienen CLI, Node, plugins, autorizar la Org y, si se quiere, reglas para que el agente no trate el código React como un LWC con wire. El MCP de Salesforce DX en Cursor es opcional. Los dos comandos que crean la estructura React y la configuración de Digital Experience sí son el corazón del flujo. Se puede hacer en un proyecto Salesforce ya existente. En la clase recomendaron un folder limpio, para ver qué se crea.
Deploy, Guest User y seguridad
El deploy crea un site. Hay que activarlo. En preferencias se habilita Guest User y se configura el perfil: cuentas, productos, lo que sea visible para anónimo. Si hay usuarios logueados, se usan los métodos del SDK y los Permission Sets de siempre.
Hacerlo público es un check. No es «se publicó, listo». Guest User ve lo que el perfil le da. Si el componente pide Accounts y el perfil guest no las tiene, no hay magia de React que lo salve. La seguridad sigue siendo Salesforce.
Multi-Framework, en la beta de la clase, tenía límites: sandboxes y scratch orgs, Org en inglés, sin producción. Eso hay que releer en la documentación del día, porque las betas se mueven.
Agentforce Vibes ya trae la opción de crear sitios React. El mensaje de la clase no es «tiren prompts y a producción». Es: se puede ir muy rápido, y igual hay que usar bien Experience Cloud.
Consejo: si el equipo ya tiene la app en React, este camino evita rehacerla en LWC. Si el equipo es admin y consultor funcional, quedémonos en Builder. React no es un premio. Es una herramienta para un problema puntual.
La mirada de EGA Futura
En EGA Futura el ERP es de EGA Futura, potenciado por Salesforce. La IA de EGA Futura, potenciada por Agentforce, vive en la misma Org. Un portal de clientes, un portal de proveedores o un microsite no son «otro sistema». Son la misma plataforma, publicada hacia afuera.
Por eso esta clase importa para quien ya opera en Salesforce y para quien llega por el camino de Salesforce y recibe el ERP instalado en su propia Org. El error de licencia, el site público mal abierto o el React sin perfil guest no son temas de «la nube de comunidades». Son temas de si tu empresa consolida el negocio o lo vuelve a fragmentar.
Agenda una demo. Dura 30 a 45 minutos, es sin compromiso y la da una persona del equipo. Empezá por egafutura.com.
Preguntas frecuentes sobre Experience Cloud
Hace falta un servidor aparte para el portal de clientes?
No. Experience Cloud publica el portal sobre la misma Org. Tu empresa evita el sitio externo, el login paralelo y la integración de datos.
Customer Community y Community Plus son lo mismo?
No. Plus suma calendario, tareas, eventos e informes. Si el cliente externo solo autogestiona casos o pedidos, Customer Community alcanza. Plus entra cuando ese usuario necesita una experiencia más cercana a un usuario interno, sin serlo.
Conviene Aura o LWR para un proyecto nuevo?
LWR. Aura sigue en portales que ya están en producción. LWR es el runtime actual, el que Salesforce usa en su documentación, y el que mejor encaja con Lightning Web Components.
React reemplaza a Lightning Web Components?
No. React entra cuando el Builder y LWC no alcanzan, o cuando el equipo ya trae una app hecha. La primera opción sigue siendo Experience Builder más LWC. Multi-Framework es el tercer escalón, no el default.
Guest User sirve para no pagar licencias?
Sirve para un sitio público con un alcance chico y controlado. No sirve para esconder usuarios internos ni para mostrar datos sensibles por URL. La seguridad la define el perfil guest, no el framework del front.
Se puede mezclar un portal de partners con usuarios internos en Community?
No es el diseño del producto ni del contrato. Community es para usuarios externos. El equipo interno va por licencias de Salesforce. Ahorrar cambiando de tipo de usuario es el atajo que una auditoría no perdona.