<\/p>\n
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.<\/p>\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í.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
1. Por qué se tomaron las decisiones, incluidas las que se descartaron.<\/strong> 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ó.<\/p>\n 2. Qué supone cada automatización.<\/strong> 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.<\/p>\n 3. Qué depende de cosas fuera de Salesforce.<\/strong> 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<\/a> suelen ser casi todo.<\/p>\n 4. El calendario.<\/strong> 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.<\/p>\n 5. Las personas y los atajos.<\/strong> 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<\/a>, y el administrador suele ser el único que conoce las dos.<\/p>\n 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.<\/p>\n<\/div>\n 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.<\/p>\n Qué:<\/strong> el campo, flujo, integración o tarea, con el nombre que tiene en Setup.<\/p>\n Por qué:<\/strong> el motivo por el que existe, en una o dos frases.<\/p>\n Descartado:<\/strong> qué más se probó o se evaluó, y por qué aquí no funcionó.<\/p>\n Responsable:<\/strong> el rol que decide si cambia.<\/p>\n Atención a:<\/strong> la suposición que lo volvería incorrecto, o la fecha en que necesita revisarse.<\/p>\n<\/div>\n La última línea es la que se gana su lugar. \u00abAtención a: supone que cada cuenta tiene un responsable de territorio\u00bb le dice a la siguiente persona exactamente qué reorganización va a romper el flujo. \u00abAtención a: el certificado vence en marzo\u00bb pone la entrada directo en el calendario.<\/p>\n Dos semanas alcanzan, siempre que nadie las gaste reescribiendo lo que Setup ya muestra. Esta es la forma que usamos.<\/p>\n Días uno y dos: el inventario.<\/strong> 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. \u00abOperaciones de ventas\u00bb 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<\/a>.<\/p>\n Días tres a ocho: recorridos grabados.<\/strong> 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.<\/p>\n Días nueve y diez: la prueba.<\/strong> 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.<\/p>\n El último día: los accesos.<\/strong> 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.<\/p>\nUn formato que mantiene cada entrada corta<\/h2>\n
Cómo hacemos un traspaso en un preaviso de dos semanas<\/h2>\n