Resumen

  • Al borrar un campo personalizado, Salesforce elimina sus atributos de unicidad y obligatoriedad. Tras restaurarlo, hay que volver a configurarlos si siguen siendo necesarios.
  • Las fórmulas recuperadas permanecen desactivadas hasta que se editan y guardan. Algunas dependencias y disposiciones de pantalla también requieren intervención.
  • El campo y sus datos se pueden recuperar hasta el borrado permanente o hasta que pasen quince días, lo que ocurra primero. La presión por liberar capacidad puede acortar ese margen.

Hay un resultado poco vistoso que conviene celebrar después de una recuperación: un mensaje que impide guardar un dato. Si ese dato debía estar prohibido, el rechazo puede demostrar más que una pantalla llena de valores antiguos.

Salesforce ofrece una buena razón para hacer esa prueba. Su documentación sobre restauración manual de atributos explica que borrar un campo personalizado retira los atributos que lo hacen único y obligatorio. Cuando se recupera el campo, esos atributos deben restablecerse si hacen falta.

El objeto visible vuelve. Parte de las reglas que le daban utilidad espera al siguiente operador. Es una frontera pequeña en la interfaz y considerable en el reparto del trabajo.

Lo que el campo sabía decir que no

Imaginemos un campo que guarda la referencia de un pedido. Es un ejemplo hipotético basado en el funcionamiento documentado. Si la empresa dependía de su atributo de unicidad para impedir dos referencias iguales, recuperar las referencias anteriores deja pendiente la restauración de ese atributo. Pueden existir otras validaciones, pero hay que saber cuál era el trabajo concreto de la que se retiró.

Lo mismo ocurre con un valor obligatorio. Encontrar las fichas antiguas completas no demuestra que una nueva ficha incompleta vaya a ser rechazada. Una prueba recorre el pasado; la otra examina el comportamiento que tendrá el sistema en el siguiente turno.

La diferencia importa porque una regla puede sostener una rutina mucho mayor. Alguien usa la referencia para conciliar pedidos, buscar una excepción o enlazar trabajo posterior. Si ese control queda pendiente, el coste puede aparecer como revisión de datos, aclaración entre departamentos o limpieza de duplicados. El incidente original ya estará cerrado y el trabajo seguirá cobrando horas con otro nombre.

Por eso el responsable del proceso tiene que participar en la recepción. El administrador sabe cómo recuperar el campo. Quien trabaja con él sabe por qué no admitía vacíos o repeticiones. Hacer que una sola persona adivine ambas cosas es una forma poco elegante de ahorrar una conversación.

Una recepción útil combina tres resultados: se ven los valores anteriores, pasa un valor nuevo correcto y se rechaza una entrada que la regla debía impedir. La tercera prueba suele ser la que falta en la fotografía del éxito.

La fórmula está en casa, pero todavía no trabaja

La guía de campos eliminados señala que las fórmulas restauradas quedan desactivadas. En lugar del resultado muestran #Error! hasta que se editan y guardan. Al guardar se comprueba la sintaxis y deben corregirse los errores que aparezcan.

Esto convierte la recuperación en algo más que devolver columnas. Para quien espera una clasificación, una cantidad calculada o una señal de trabajo, que la fórmula exista es una noticia a medias. Necesita que vuelva a calcular lo esperado.

También puede persistir un cambio de nombre. Al borrar un campo, Salesforce añade _del a su nombre de desarrollador, salvo que otro campo eliminado ya tenga ese nombre. El sufijo permanece al restaurarlo. El nombre que reconoce la persona en pantalla y el nombre técnico que debe revisarse en la configuración merecen comprobaciones distintas.

Los resultados de búsqueda añaden una demora propia: el campo restaurado y sus datos pueden tardar un poco en aparecer. No conviene usar la búsqueda como certificado único de recuperación. Ver, calcular y validar son estados diferentes.

La lista de trabajos manuales se extiende a lo que cambió mientras el campo estaba borrado. Hay que añadirlo a las disposiciones de página que se modificaron durante ese intervalo. Si informes y disposiciones no se editaron, el campo restaurado permanece en ellos. Las dependencias retiradas deben definirse de nuevo. Para devolver una relación a maestro-detalle, los registros correspondientes deben tener los datos necesarios.

El entorno al que vuelve el campo, por tanto, puede haber seguido avanzando. La promesa de volver atrás se vuelve cara cuando nadie anotó qué se movió durante la ausencia.

La lista de usos tiene ventanas cerradas

Antes de borrar, la función « Where is this used? » permite examinar referencias como fórmulas, disposiciones, Apex, reglas de validación activas e informes. Ayuda a localizar trabajo afectado. Salesforce también publica qué queda fuera de esa vista.

No aparecen ciertas referencias de informes que usan el campo a través de una relación de clave externa. Tampoco se devuelven informes a los que no tiene acceso la persona que consulta, y los informes unidos no están soportados. En una organización suscriptora se excluyen las referencias que ya vienen dentro de un paquete gestionado; sí pueden aparecer referencias nuevas creadas localmente después de instalarlo. La lista se limita a las primeras 2.000 entradas, ordenadas por tipo.

Un resultado vacío es un resultado de esa búsqueda, con ese alcance y esos permisos. Convertirlo en la firma de que nadie necesita el campo traslada la investigación al peor momento: cuando alguien lo eche en falta.

La regla de borrado mantiene sus propios límites. No se puede eliminar un campo referenciado por otro campo, una actualización de campo o Apex. Un proceso en segundo plano que lo esté actualizando también puede impedir la operación. Esos controles detienen determinados conflictos conocidos. La organización sigue necesitando un inventario de sus usos y de las reglas que considera valiosas.

Quince días y un proyecto con prisa

Salesforce conserva el campo eliminado y sus datos hasta que la organización los borra permanentemente o transcurren quince días, lo que llegue antes. Ese margen sirve para recuperar. No reconstruye por sí solo los requisitos del negocio.

A la vez, el campo sigue contando en el límite de campos personalizados hasta que acaba el borrado definitivo; también cuenta para el límite aplicable a su tipo. Una empresa que necesita crear campos para un nuevo proyecto puede sentir la tentación de acelerar la limpieza. Lo que un equipo ve como espacio pendiente de liberar, otro puede verlo como la última oportunidad de recuperar una regla antigua.

La función Purge envía los campos preparados al proceso de borrado definitivo. Iniciar ese proceso y terminarlo son cosas distintas. El tiempo depende de la demanda del sistema y se puede seguir en los trabajos en segundo plano. Ni siquiera el sacrificio de la recuperación convierte el botón en capacidad instantánea.

Si después de borrar permanentemente persisten los errores de acceso o falta de columnas limpias, el procedimiento oficial de soporte pide identificar la organización, indicar si es producción o un entorno de pruebas y autorizar el borrado físico. Aclara que ese borrado físico de campos personalizados no se puede limitar a un solo objeto: su alcance es toda la organización. Un problema local puede acabar requiriendo una decisión de limpieza más amplia.

Para determinar qué protección falta en una organización concreta se necesitan sus definiciones guardadas, sus dependencias y los resultados de la recepción del negocio. El criterio se puede fijar antes: devolver un campo es el comienzo; devolver su capacidad de hacer cumplir la regla es el resultado que hay que comprar.