SkyPlanner 
Cuando un administrador de Salesforce presenta su renuncia, la org sigue funcionando. Nada se rompe el primer día, y justamente ese es el problema. El traspaso suele tener dos semanas y un documento, y ese documento casi siempre describe la configuración.
Salesforce ya registra la configuración. Lo que no registra es lo que sabía el administrador. Eso es lo que se pierde, y aparece meses después, cuando alguien necesita cambiar algo y nadie puede explicar por qué está hecho así.
Esto es lo que dejamos por escrito en su lugar, cómo lo hacemos entrar en un preaviso de dos semanas y qué hacemos cuando no hay nadie que lo reemplace.
La org ya documenta el qué
Setup te dice qué es cada campo personalizado, cada flujo, cada regla de validación y cada permission set. Los campos tienen descripción y una vista de dónde se usan. Los flujos guardan sus versiones. El historial de auditoría de configuración (Setup Audit Trail) registra quién cambió qué y cuándo, más o menos durante los últimos seis meses. Un traspaso que copia todo esto en un documento produce algo largo, desactualizado en pocas semanas y que nadie lee.
Lo que nada de eso registra es el motivo. El historial puede decirte que una regla de validación cambió en marzo. No puede decirte que cambió porque finanzas dejó de aceptar cotizaciones sin número de orden de compra, ni que el cambio solo debía durar hasta el cierre del trimestre.
Por eso la regla con la que trabajamos es simple: si Salesforce te lo puede decir, no lo escribas. Escribe lo que solo te puede decir la persona que se va.
Cinco cosas que solo sabe el administrador
1. Por qué se tomaron las decisiones, incluidas las que se descartaron. Por qué existe el campo personalizado cuando parece que uno estándar alcanzaría. Por qué las oportunidades se dividen como se dividen. Por qué un equipo tiene su propio tipo de registro. Y, sobre todo, las opciones que se evaluaron y se dejaron de lado. Nadie las escribe, y son las que la siguiente persona redescubre de la forma cara: tres semanas construyendo la solución obvia antes de enterarse de por qué aquí nunca se usó.
2. Qué supone cada automatización. Cada flujo lleva incorporada una creencia sobre cómo funciona el negocio. Que cada cuenta tiene un responsable en el territorio correcto. Que los descuentos por encima de cierto nivel siempre van al mismo aprobador. Que las renovaciones se crean una cantidad fija de días antes del vencimiento. Cuando la creencia deja de ser cierta, el flujo sigue funcionando igual y nada da error. El administrador suele saber cuáles de esas suposiciones ya están flojas. Escribe esas primero.
3. Qué depende de cosas fuera de Salesforce. Las integraciones y los usuarios con los que se ejecutan. A quién llamar en cada proveedor cuando una sincronización se detiene. Los trabajos programados y las exportaciones de las que alguien depende sin haberlas visto nunca. Dónde se guardan las credenciales: un lugar, nunca las credenciales mismas en el documento. Si necesitas una lista para empezar, los usuarios de integración y las conexiones por API que revisamos en las actualizaciones de Winter ’27 que deciden la preparación para la IA suelen ser casi todo.
4. El calendario. El trabajo que ocurre solo unas pocas veces al año, que es justamente por qué nadie más sabe que existe. Las actualizaciones de versión, tres veces al año, cada una con cambios que se imponen en una fecha. Las actualizaciones de sandbox y lo que hay que arreglar después antes de que alguien pueda volver a probar. Los certificados, las contraseñas de integración y los secretos de connected apps que vencen sin avisar. Las personas que se van, cuyos registros, reportes programados y paneles siguen apuntando a ellas. La renovación, con su cantidad de licencias y los complementos que nadie usa. Cada una de estas cosas es invisible hasta que es tarde.
5. Las personas y los atajos. Quién pide qué y por qué canal, porque la cola real de pedidos casi nunca es la oficial. Qué tres reportes abre de verdad la dirección. Qué equipo usa un campo para algo para lo que nunca se diseñó. La planilla que convive con el proceso oficial y que, sin decirlo, es el proceso. Casi todos los equipos tienen dos versiones de cada proceso, la documentada y la real, y el administrador suele ser el único que conoce las dos.
Un traspaso es una prueba, no un documento. La única forma de saber que funcionó es que otra persona haga el trabajo a partir de él.
Un formato que mantiene cada entrada corta
Los documentos de traspaso largos fallan porque nadie encuentra en ellos lo que necesita. Cada entrada del traspaso de un administrador de Salesforce puede seguir las mismas cinco líneas cortas, y una entrada que no entra en cinco líneas suele ser dos entradas.
Qué: el campo, flujo, integración o tarea, con el nombre que tiene en Setup.
Por qué: el motivo por el que existe, en una o dos frases.
Descartado: qué más se probó o se evaluó, y por qué aquí no funcionó.
Responsable: el rol que decide si cambia.
Atención a: la suposición que lo volvería incorrecto, o la fecha en que necesita revisarse.
La última línea es la que se gana su lugar. «Atención a: supone que cada cuenta tiene un responsable de territorio» le dice a la siguiente persona exactamente qué reorganización va a romper el flujo. «Atención a: el certificado vence en marzo» pone la entrada directo en el calendario.
Cómo hacemos un traspaso en un preaviso de dos semanas
Dos semanas alcanzan, siempre que nadie las gaste reescribiendo lo que Setup ya muestra. Esta es la forma que usamos.
Días uno y dos: el inventario. Siéntate con la persona que se va y armen juntos la lista de lo que entra en cada uno de los cinco temas. Para cada punto, anota dos cosas: qué tan frágil es y quién será responsable después. Escribe el responsable como un rol, no como un nombre. «Operaciones de ventas» sobrevive a la siguiente renuncia; una persona no, que es la misma razón por la que recomendamos nombrar a los responsables de los campos como roles al revisar si tus datos están listos para IA.
Días tres a ocho: recorridos grabados. Una sesión por tema, de treinta a cuarenta y cinco minutos, con la pantalla grabada y con quien lo reemplaza, o quien vaya a cubrir el puesto, presente. Grabar es más barato que escribir y conserva los motivos en las palabras de quien tomó las decisiones. El documento se convierte en un índice: una línea por punto, el responsable y un enlace al minuto de la grabación donde se explica.
Días nueve y diez: la prueba. El sucesor hace una tarea real y rutinaria de cada tema usando solo lo que quedó escrito y grabado, mientras la persona que se va mira y no dice nada hasta que termina. Agregar un valor a una lista de selección y seguirlo por cada flujo, reporte e integración que toca. Desactivar limpiamente un usuario de prueba. Leer las actualizaciones de la próxima versión y decir cuáles aplican. Cada lugar donde el sucesor se traba es el próximo párrafo a escribir, y todavía hay tiempo para escribirlo.
El último día: los accesos. Asegúrate de que al menos otra persona ya tenga acceso completo de administrador bastante antes del último día, no ese mismo día. Después congela la cuenta del administrador que se va en lugar de borrar nada, reasigna lo que le pertenece y desactívala cuando los trabajos programados, reportes y aprobaciones que dependían de ella ya se hayan movido.
¿Todavía no hay sucesor?
Un soporte continuo puede cubrir el calendario y los pedidos del día a día mientras contratas, y el traspaso se convierte en el brief para quien llegue después.
Cuando no hay sucesor
En muchas empresas medianas hay un solo administrador de Salesforce, y cuando se va, el puesto queda vacante durante meses. El traspaso entonces no tiene a quién entregarse, y el riesgo no es la primera semana. Es la deriva lenta que viene después.
Cuatro cosas mantienen esa deriva bajo control. Decide quién tiene acceso de administrador mientras tanto, y que sean dos personas, para que nada dependa de un solo usuario. Limita los cambios de configuración a lo verdaderamente urgente, para que nadie improvise en una org que no conoce. Pasa el calendario a un calendario compartido con un rol en cada entrada, para que las actualizaciones de versión y las credenciales que vencen sigan recibiendo atención. Y lleva un registro de cada pregunta que alguien hace y nadie sabe responder. Después de un mes, ese registro es la descripción de puesto más precisa que vas a escribir, y el mejor brief para un nuevo administrador o para un partner.
Dónde debería vivir
No en una wiki que nadie actualiza. Un solo documento compartido, guardado donde la gente ya mira, con las grabaciones enlazadas. El significado de cada campo va más cerca del trabajo, en el texto de ayuda del campo, donde lo ve quien completa el campo y también quien lo lea después.
Y necesita un momento para revisarse, o se deteriora como todo lo demás. El momento natural ya está en el calendario: tres versiones de Salesforce al año. Cuando alguien lee las actualizaciones de versión para tu org, alguien también abre el documento de traspaso y corrige lo que dejó de ser cierto. Lleva una hora, y hace que el próximo traspaso empiece con un documento que todavía es correcto.
Por qué importa más allá de la próxima renuncia
Todo lo anterior es trabajo de administración común y nada depende de la IA. Vale la pena notar, sin embargo, que la misma brecha aparece cuando se conecta un asistente a la org. Puede leer la configuración en segundos. No puede leer los motivos, porque nunca se escribieron en ningún lado. Una org donde los motivos están por escrito es más fácil para el próximo administrador, para un partner que llega sin contexto y para cualquier herramienta que tenga que trabajar con lo que realmente quedó registrado.
Nuestra opinión
Los traspasos rara vez fallan de forma ruidosa. Fallan con cortesía: un documento largo, una última semana amable y un problema que llega cuatro meses después para alguien que no estaba en la sala. El traspaso de un administrador de Salesforce no necesita más páginas para evitarlo. Necesita menos, enfocadas en lo que solo sabe la persona que se va, y una prueba honesta antes del último día.
Si haces una sola cosa de este artículo, que sea la prueba. Elige una tarea rutinaria, dale al sucesor lo que quedó escrito y mira dónde se detiene. Eso es el traspaso, y es la parte a la que la mayoría de los equipos nunca llega.
