M02 — Descubrir roles y caminos Salesforce
Una de las trampas al empezar es pensar que “trabajar en Salesforce” significa una sola cosa. No es así.
Hay perfiles más funcionales, más técnicos, más analíticos, más comerciales, más orientados a procesos, más cercanos a cliente y más cercanos a código. Cada uno pide habilidades distintas.
Si vienes de otro sector, esto importa mucho. Tu experiencia anterior puede darte pistas sobre dónde encajas mejor, pero necesitas conocer las opciones antes de elegir tu primera puerta.
No elijas por moda. Elige por encaje.
Hay una diferencia importante que conviene entender pronto: una cosa es el rol profesional que desempeñas y otra cosa es la certificación que tienes.
La certificación te da base para defender conversaciones. El rol depende del proyecto, de la empresa, de tu experiencia y de las responsabilidades que acabes asumiendo.
En una empresa grande, todo puede estar más separado: administrador por un lado, business analyst por otro, consultor, project manager, developer, arquitecto… En una consultora media, en cambio, es habitual que una misma persona sea bastante multirol. Puede tocar análisis, configuración, reuniones con cliente, documentación, pruebas, formación y seguimiento.
Eso no significa improvisar. Significa que tu base debe ser sólida.
Y para una persona reconvertida, la base más realista suele ser Admin.
Salesforce Administrator
El Admin configura y mantiene la plataforma: usuarios, permisos, objetos, campos, layouts, reports, dashboards y automatizaciones.
Desde fuera puede parecer un rol de botones. Desde dentro se ve distinto.
Crear un campo es fácil. Saber si ese campo debe existir, quién lo debe ver, cómo afecta al dato, al reporting, a la seguridad, al proceso y al mantenimiento… ahí empieza el criterio.
Esa frase separa bastante bien a alguien que solo sabe tocar la herramienta de alguien que empieza a pensar como consultor.
Lo más probable, si vienes de fuera del sector, es que tu primera oportunidad esté cerca de administrar, mantener o mejorar organizaciones ya existentes. No suena épico, pero es una entrada muy real. Y una buena escuela.
Functional Consultant
El consultor funcional conecta necesidad de negocio con solución Salesforce.
Escucha, pregunta, ordena, detecta huecos, traduce conversaciones a requisitos y ayuda a convertirlos en configuración, procesos o diseño funcional.
No es un rol “menos técnico”. Es técnico de otra manera. Requiere entender la plataforma, pero también entender negocio, personas, prioridades, restricciones, adopción y política interna. Sí, política. Esa también viene en el paquete, aunque nadie la ponga en Trailhead.
Si vienes de ventas, operaciones, consultoría, proyectos, account management o trato con cliente, aquí puedes tener ventaja.
Business Analyst
El Business Analyst ayuda a que el equipo entienda mejor el problema antes de construir nada.
Documenta procesos, recoge requisitos, detecta fricciones, ordena conversaciones y convierte caos en claridad.
Puede sonar menos “Salesforce” desde fuera, pero en proyectos reales es una pieza enorme. Construir algo incorrecto con mucha seguridad sigue siendo construir algo incorrecto.
Un buen BA evita que el equipo fabrique tonterías con confianza.
Y eso, aunque suene gracioso, ahorra dinero.
Developer
El Developer trabaja con código: Apex, Lightning Web Components, integraciones y lógica personalizada.
Es un camino fuerte si vienes de software o quieres ir deliberadamente hacia programación. Pero no es obligatorio para entrar en Salesforce.
Moverte hacia tecnología no significa convertirte automáticamente en developer.
Si eres un perfil senior reconvertido desde negocio, probablemente no sea tu guerra inicial. No porque no puedas aprender, sino porque competirías contra gente que ya viene de IT, con años de base técnica y mucha más tracción en ese terreno.
No compitas donde eres débil por orgullo. Entra por donde puedes hacerte fuerte.
Solution Architect
El arquitecto diseña soluciones completas: productos, datos, seguridad, integraciones, escalabilidad y decisiones de alto impacto.
Es una referencia interesante para entender hacia dónde puede crecer una carrera, pero no suele ser un punto de entrada.
Arquitectura queda lejos. Developer queda en otra acera si no vienes de código. Tu foco inicial debería ser construir base, criterio y credibilidad.
Roles y certificaciones no son lo mismo
Esta idea es importante:
Puedes tener la certificación Admin y acabar haciendo tareas de Admin, BA, consultor funcional o incluso coordinación de proyecto según tu experiencia y el contexto.
La certificación no decide todo. Te da lenguaje, base y legitimidad inicial.
La experiencia y el proyecto deciden el papel real que vas ocupando.
Por eso no conviene obsesionarse con la etiqueta perfecta. Conviene entender qué problemas resuelve cada rol y dónde puedes aportar más valor.
Mapa rápido
| Rol | Foco | Si vienes de… | Riesgo común |
|---|---|---|---|
| Administrator | Configuración, operación y mantenimiento de la plataforma | Administración, soporte, operaciones, negocio | Pensar que son solo botones |
| Functional Consultant | Traducción negocio-Salesforce | Ventas, consultoría, proyectos, operaciones | Creer que es “menos técnico” |
| Business Analyst | Claridad de procesos y requisitos | Gestión, formación, análisis, cliente | Pensar que no es rol Salesforce |
| Developer | Código, componentes e integraciones | IT, software, programación | Creer que todo el mundo debe empezar aquí |
| Solution Architect | Diseño completo de solución | Experiencia senior en proyectos | Tratarlo como objetivo de entrada |
Antes de seguir
Elige dos roles que te resulten cercanos y lee dos ofertas reales de cada uno.
Apunta:
- habilidades que se repiten;
- problemas de negocio que aparecen;
- partes que conectan con tu experiencia;
- partes que aún te quedan lejos.
La pregunta no es “qué rol suena más importante”.
La pregunta buena es: “qué primer rol puedo defender con más credibilidad”.