Perfil híbrido
Donde Salesforce y la infraestructura son una sola cabeza, no dos
No soy una desarrolladora Salesforce que sabe de servidores, ni una administradora de sistemas que sabe Salesforce. Resuelvo problemas transversales que un especialista solo — de un lado o del otro — abordaría más despacio, peor o directamente no abordaría: las decisiones de ambas capas se toman a la vez, por la misma persona, antes de que empiece el habitual ida y vuelta entre equipos. Las pruebas citadas a continuación proceden de proyectos de formación y proyectos personales; cada página indica su naturaleza y su periodo.
Tres casos donde la combinación cambia el resultado
- 01
Migración de datos Heroku ↔ Salesforce, con una app móvil de campo
El problema — Una aseguradora adquiere a un competidor: los datos del CRM adquirido deben pasar a Salesforce (en un solo sentido), y los agentes de campo necesitan una app móvil que lee y escribe en la misma org.
Un único especialista
Un perfil Salesforce se detiene en la capa Apex REST y delega la infraestructura de Heroku — las decisiones de integración se toman sin conocer las restricciones del otro lado. Un perfil de infraestructura despliega la app de Heroku, pero no diseña ni el trigger Apex de External ID ni la Matching Rule que frenan los duplicados en el origen.
Lo que entrego
Ambas cosas: los endpoints Apex REST, la app Node.js/PostgreSQL que los consume, Heroku Connect configurado objeto por objeto, dos entornos aislados unidos por un pipeline, hasta el runbook de despliegue. El entorno de staging existía antes de escribir la primera línea de Apex — no después.
Dónde importa — Seguros y finanzas: reconciliar dos carteras de clientes donde un duplicado no es una molestia sino un expediente huérfano y un riesgo de incumplimiento.
- 02
Disciplina DevOps aplicada a las releases de Salesforce
El problema — Entregar cambios de Salesforce de forma repetida sin romper producción, con una trazabilidad auditable en cada puesta en producción.
Un único especialista
Un perfil Salesforce sabe programar la funcionalidad, pero despliega con Change Set manual, sin procedimiento de rollback documentado. Un perfil DevOps sabe construir un pipeline, pero no conoce las trampas del despliegue de metadatos de Salesforce — sin deshacer nativo, orden de dependencia entre componentes.
Lo que entrego
Una disciplina DevOps real — validación automatizada de cada Pull Request contra la org, autenticación servidor a servidor JWT Bearer, clave privada eliminada del runner tras cada ejecución, procedimiento de rollback SFDX documentado — aplicada a cómo se entregan las releases de Salesforce, no solo a cómo se programan.
Dónde importa — Cualquier sector regulado — salud, energía, finanzas: cada cambio en producción debe ser trazable y reversible, no solo funcional.
- 03
El control de acceso de una integración, diseñado del lado de Salesforce
El problema — Una integración Salesforce expone endpoints REST: qué usuario los llama, con qué permisos y a qué datos puede acceder.
Un único especialista
Un desarrollador Salesforce entrega el endpoint apoyándose en un perfil existente demasiado permisivo. Un equipo de infraestructura configura la autenticación del lado del servidor — pero no sabe qué Permission Set, qué verificación CRUD/FLS o qué Sharing Rule limita realmente el acceso del lado de Salesforce.
Lo que entrego
Diseño los permisos de la integración del lado de Salesforce — usuario de integración dedicado, Permission Set explícito, verificaciones CRUD/FLS, WITH SECURITY_ENFORCED — junto con la autenticación del lado del servidor, en el mismo sprint. Los accesos quedan acotados antes de la puesta en producción, no tres tickets después.
Dónde importa — Salud y lujo: integraciones que hacen transitar datos de pacientes o de procedencia de producto — donde un acceso mal acotado no es un detalle técnico sino una pérdida de confianza.
Lo que elimina la combinación
- El ida y vuelta entre el equipo de Salesforce y el equipo de infra/DevOps en cada decisión de integración.
- Decisiones tomadas de un lado sin conocer las restricciones del otro — un trigger diseñado sin saber cómo lo solicita la infraestructura, un pipeline diseñado sin conocer los límites de despliegue de Salesforce.
- El desfase entre «la API está auditada» y «el control está en marcha»: ambas cosas ocurren en el mismo sprint.
¿Tienes un puesto transversal por cubrir?
Si el puesto toca a la vez Salesforce e infraestructura — integración, migración, puesta en producción trazable, automatización de despliegues — es exactamente el terreno donde este perfil ahorra tiempo a un equipo.