El 22 de enero, Vantegrate grabó una masterclass de los jueves con un producto que cambia de nombre más rápido que Setup. Experience Cloud (antes Community Cloud, hoy también Digital Experiences) no es un sitio decorativo: es la puerta de afuera de su org.
La clase completa está en YouTube. Juan Manuel Garrido (JuanMa) la condujo con Josué Mendoza (Josu), Francisco Morales (Fran) y Esteban Morales (Esti), con una visita sorpresa de Daniel M
ark.
El equipo de Vantegrate lo dejó claro de entrada. Hoy van a ver qué es un site, cómo se crea, cómo se administra y por qué la mayoría de los problemas viven en Settings.
Esta fue la parte 1 de 2. La promesa: entender el mapa completo antes de jugar en el Builder.
Qué es Experience Cloud (sin el machete de nombres)
Josu arrancó con la pregunta que nadie formula bien. ¿Qué es Experience Cloud si ya no se llama Community?
Es una nube de Salesforce para armar experiencias digitales orientadas a gente que no es usuaria interna de su CRM. Extiende información y funcionalidad de la org sin regalarles una licencia estándar.
El ejemplo de la clase es el home banking. Ustedes son un banco: tienen clientes, cuentas, tarjetas y un mundo entero adentro de Salesforce.
No les dan acceso al User Interface nativo. Les arman un portal donde cada persona entra con su usuario y ve solo lo suyo.
Experience Cloud resuelve ese patrón. Casos, oportunidades, knowledge, objetos custom: lo que habiliten, con el alcance que definan.
JuanMa lo resumió con historia. Nació hace muchísimo tiempo como portal de clientes (y de partners) y hoy, en Setup, lo encuentran como Digital Experiences.
Fran sumó una advertencia de naming. Salesforce cambia tanto los nombres que hasta adentro tienen un machete con veinte alias del mismo producto.
Para esta nota, digamos site. Portal, community o Digital Experience: en la práctica es el sitio que publican hacia afuera.
Por qué no les dan una licencia Sales Cloud a cada cliente
Josu fue directo al bolsillo. Las licencias de Experience Cloud son abrumadoramente más baratas que las licencias estándar de Salesforce.
Fran bajó números de negociación real. Una licencia estándar de Experience puede rondar 10 a 15 dólares por usuario por mes (a veces menos), según el acuerdo con Salesforce.
También existe (o existió con otro nombre) una variante tipo Community Plus que habilita informes y paneles. Ahí el portal deja de ser solo autoservicio y suma un poco de business intelligence.
Hay dos formas clásicas de comprar. Una es por licencia nombrada (una bolsa de usuarios que se registran o que ustedes dan de alta).
La otra es por login: compran un cupo de ingresos mensuales. Sirve cuando el volumen de personas es enorme (piense otra vez en un banco) y no tiene sentido nombrar a cada visitante.
Fran marcó el límite contractual que mucha gente ignora. No pueden usar licencias de Digital Experience para empleados directos de la organización.
Salesforce quiere evitar que Experience canibalice Sales Cloud o Service Cloud. Si en una auditoría aparece el atajo, se complica.
Fran y JuanMa también aclararon el alcance de producto. Experience apunta a autogestión, portales de revendedores y socios comerciales.
No está pensado como e-commerce puro. Para armar un portal de ventas de punta a punta, Salesforce tiene Commerce Cloud (o el nombre que tenga esa semana).
Si su equipo vive en el CRM de Salesforce, el site no es otro sistema inventado. Es la misma org con otra cara y otra licencia.
Un site bien hecho (y por qué a veces no se nota)
JuanMa tiró una observación de calle. Navegando una página de una empresa de primerísima línea, a veces se dan cuenta de que atrás hay Force por la URL o por un detalle de animación.
La potencia de Digital Experiences es el look and feel. Pueden personalizar estilo hasta integrar el portal al resto del sitio web de la marca.
Si el diseño está bien hecho, el visitante no piensa "estoy en una community". Piensa "estoy en el portal de mi proveedor".
Eso no significa un solo molde para todos. Josu explicó la granularidad con dos caminos.
Pueden tener una sola community y cambiar landing pages según perfil. O pueden separar sites distintos según el trabajo que hace cada audiencia.
El ejemplo de salud de la clase es cristalino. Una Experience para que el paciente autogestione su información.
Otra Experience para que el profesional gestione su turnero (disponible / no disponible). Todo converge en el mismo CRM.
Esa lógica aplica a industrias enteras: seguros, salud, partners B2B, postventa. El patrón es el mismo; cambia quién entra y qué ve.
Casos reales: brokers, partners y Agentforce en el portal
Tuvieron un invitado sorpresa: Daniel Mark (Nespon Solutions, Summit Partner). Aprovecharon para hablar de implementaciones serias, no de demos de brochure.
Daniel contó un caso reciente en México. Una aseguradora de transporte de carga abre su Experience a brokers (el canal típico del rubro).
Desde el portal levantan pólizas, denuncian siniestros y consultan condiciones sin fricción. Entran, trabajan y vuelven al negocio.
Ahí también metieron una cuota de Agentforce. En lugar de filtrar a los tumbos, el broker pide por diálogo y el agente ahorra clics.
La clase también repasó por qué Experience y Agentforce se llevan bien. Un centro de ayuda con Knowledge, más un agente que responde, es el combo que Salesforce vende (y que en proyectos reales ya aparece).
Daniel sumó otros casos de su práctica (Field Service, call center, WhatsApp como canal omnipresente). El hilo para esta masterclass fue claro: el portal de partners y canales es uno de los usos más fuertes de Experience Cloud.
Si quieren ver el tono de estas clases, en Pulse y en recursos encuentran el material del ciclo.
Crear el site: Digital Experiences, Sites y My Domain
JuanMa compartió pantalla en una org real. Recomendación de Setup que duele, pero es cierta: no usen Salesforce en español.
El mapeo entre la UI en inglés y la UI en español no es exacto. Termina siendo más confuso que estudiar tres términos.
En Quick Find escriben algo como Digital Experiences y entran a Sites (All Sites). CMS (Content Management System) existe y es potente; en esta clase no lo tocaron.
Antes de crear, un requisito casi olvidado: necesitan My Domain. Sin eso, las communities / experiences no levantan como corresponde.
Todavía hay orgs sin My Domain. Suena imposible, pero en la clase lo marcaron como dato real de campo.
Después viene el clic en New. Aparece el menú de templates y ahí empieza el quilombo lindo.
Templates: Help Center, Customer Portal y construir de cero
JuanMa bajó el entusiasmo un cambio. El template que elijan cambia la funcionalidad de partida.
Tienen un microsite o la opción de construir desde cero. También tienen el famoso centro de ayuda.
En un Help Center exponen Knowledge (artículos de mantenimiento, cuidado, reparación) y, si hace falta, casos. La postventa deja de vivir solo del teléfono.
También pueden meter Agentforce ahí. Preguntan, responden, y el portal deja de ser un PDF con CSS.
Después aparece el Customer Account Portal (pensado más para consumidores finales, tipo home banking). Hay variantes de customer service y más blueprints.
Aura, LWR y el template "pelado"
Esti respondió la diferencia que todos confunden. Aura es la tecnología previa (sitios viejos, componentes Aura, el look que ya se siente de otra época).
LWR (Lightning Web Runtime) es la misma idea de site "de cero", pero con Lightning Web Components. Tecnología top de gama, más moderna, más desarrollo propio.
Los otros templates son pre-build: un blueprint con páginas, tabs y componentes listos. Ustedes adaptan; no inventan la barra de casos desde cero.
Fran y Josu lo dijeron sin drama. Empezar de cero da control; empezar con Customer Service da velocidad.
En la demo eligieron Customer Service, le pusieron un nombre de prueba y crearon el site. Listo el punto de partida.
Para quien construye componentes, el camino natural sigue en Salesforce developers. Acá el foco fue el mapa del producto, no el LWC pixel a pixel.
Administración vs Builder (dos interfaces, un solo site)
JuanMa insistió en una idea que evita mareos. La administración de un site tiene dos interfaces.
Una es Administración: el panel general del site (URL, members, mails, preferencias, activación). La otra es Builder: donde construyen el sitio propiamente dicho.
Recomendación práctica de la clase: dupliquen la pestaña del navegador. En una dejan Administración; en la otra abren Build.
Josu adelantó la regla que duele. El 80% de los problemas de Experiences se arruinan en Settings.
URL, Activate y el site público
En Settings aparece la URL del site dentro del dominio de la org. Es el link que después les pasan a usuarios (o el que cuelgan detrás de un dominio propio tipo www.mipagina.com).
Mientras el site no esté Active, nadie entra (salvo ustedes como admin para probar). Si algún día dan de baja el portal, desactivan y listo.
Josu tiró la frase que JuanMa pidió tatuar. Site público: pueden configurar el site para que no pida credenciales.
Eso abre un abanico enorme (y también riesgos). En la parte 2 profundizan; en esta clase quedó como semilla.
También pueden pedir registro. El visitante no tiene credenciales, se registra, y ustedes controlan el alta.
Sobre seguridad del portal, la clase fue explícita sin alarmismo. Público no es sinónimo de "abro toda la org".
Members: contactos, partners y quién entra
En Members definen quién forma parte del site. No todos los usuarios de la org son miembros del portal.
Los usuarios externos de un site se crean a partir de un Contacto. La administración de accesos se hace desde la record page del contacto.
Además, activan ciertas cuentas como partner para que esos contactos puedan ingresar. El modelo mental no es "creo un User interno barato": es "extiendo el CRM hacia afuera".
JuanMa adelantó el spoiler de la serie. Esta masterclass es la 1 de 2; en la siguiente cierran el ciclo completo de construcción.
Branding del login, copyright y mails que abruman
En apariencia del login pueden poner el logo de la empresa (o de una subdivisión). Cambian colores de fondo, tipografías visuales del formulario y el texto de copyright.
En la demo lo mostraron en vivo: un cambio de color, Save, y el login se transforma. No hace falta un frontender para el primer ajuste.
Después vienen los templates de mail. Cuando alguien se registra o cuando dan de alta un usuario externo desde el contacto, Salesforce manda correos.
JuanMa dejó una buena práctica fuerte. No activen a lo loco el mensaje de bienvenida del site si la org tiene varios Experiences.
¿Por qué? Porque si alguien mete un perfil interno como miembro "para testear", o si crean usuarios en una org con muchos sites, la persona recibe un mail por cada Experience.
Contó una auditoría en un cliente con varios sites: pidió un usuario de prueba en producción y le llegaron el mail estándar de Salesforce más seis correos adicionales. Confuso y abrumador.
La recomendación doble fue clara. Cuiden quién entra en Members, y miren los mails con cariño (olvidé contraseña, cambio de password, bienvenida).
En proyectos propios, el equipo de Vantegrate automatiza el alta de usuarios externos con un Flow. Mail, activación y listo, sin pelearse con la interfaz nativa cada vez.
Eso conecta con cómo cotizan el trabajo. Si están armando el portal con partner, miren precios y pidan una demo con el alcance real (licencias, sites, mails y Builder).
El Builder: páginas, tema y componentes (aperitivo de la parte 2)
Antes de cerrar, JuanMa abrió el Builder para sentar bases. Cuatro zonas que tienen que reconocer de memoria.
Settings (sí, más settings), estructura de páginas, tema y componentes. La próxima clase repasa Settings del Builder con detalle.
Un site está hecho de páginas. No son HTML sueltos de un WordPress: son páginas con comportamiento especial de Experience.
En la estructura ven header, footer y el layout. Si cambian el footer, esa modificación se propaga a las páginas del sitio.
En tema cambian el tema completo, colores, imágenes, logo, header y hasta fonts si quieren ser minuciosos.
Los componentes son los LEGO. Se arrastran a la página, parecido a armar una Lightning page, con tips propios que dejan para el siguiente jueves.
Josu pidió la tarea para casa. En una sandbox o developer org, creen una Community hoy y jueguen un toque.
Así la parte 2 no llega difusa. Van a reconocer el Builder, van a haber roto algo chiquito y van a llegar con preguntas buenas.
Esti cerró con humor: se quedó con la intriga de ver una página terminada. Quedó para la siguiente, junto con ganas (confesas) de meter Agentforce adentro del Experience.
Vantegrate es partner actual de Salesforce y de Oracle. Eso no reemplaza practicar en la org: el producto se aprende haciendo clic con criterio.
Si después miden adopción del portal o del canal, eso es otra capa. Primero el site tiene que existir, activarse y no mandar seis mails de bienvenida.
Mapa de la clase (para no perderse en Setup)
Si se llevan una sola hoja de ruta, que sea esta.
1. Experience Cloud = Digital Experiences = site para gente de afuera.
2. Licencias más baratas, nombradas o por login, con límite contractual sobre empleados.
3. Templates (Help Center, Customer Account Portal, Customer Service) versus Aura / LWR de cero.
4. My Domain obligatorio; Sites en Setup; Administración y Builder como dos mundos.
5. Settings, Members, branding y mails: ahí se rompe o se salva el portal.
6. Builder (páginas, tema, componentes) queda como puente a la masterclass 2 de 2.
La grabación del 22 de enero está en YouTube. Ábranla con Setup al lado, creen el site de prueba y vuelvan a esta nota cuando Settings les tire el primer error raro.
El portal de clientes y partners no es magia de marketing. Es la misma Salesforce org, con otra puerta, otra licencia y mucho Settings por delante.
