Comportamiento especial en las implementaciones

Procesos de aprobación

• Si los campos de la página de aprobación incluyen cualquier campo personalizado en objetos estándar, agregue esos campos personalizados manualmente a conjuntos de cambios salientes. La opción Ver/Agregar dependencias para la selección de componentes del conjunto de cambios no incluye esos campos.
• Si el proceso de aprobación hace referencia a cualquier plantilla de publicación que contenga campos personalizados, vuelva a guardar esas plantillas de publicación en la organización de origen antes de agregarlas al conjunto de cambios. Desde Configuración, en el cuadro Búsqueda rápida, ingrese Plantillas de publicación y, a continuación, seleccione Plantillas de publicación. Para cada plantilla de publicación, haga clic en Modificar y luego en Guardar.
• Los conjuntos de cambios no incluyen el orden de procesos de aprobación activos del origen. A veces es necesario volver a ordenar los procesos de aprobación en el destino después de la implementación.
• Si cambia el Nombre exclusivo de un proceso de aprobación que se incluyó anteriormente en un conjunto de cambios e implementado en otra organización y vuelve a enviar el proceso de aprobación a través de un conjunto de cambios, se crea un nuevo proceso de aprobación después de la implementación en la otra organización. No se modifica el proceso de aprobación implementado previamente.

Clases de Apex y desencadenadores de Apex

De forma predeterminada, los cambios en el código Apex que tiene trabajos de Apex pendientes o en curso no se pueden implementar. Para implementar estos cambios, realice uno de los siguientes pasos.

• Cancele los trabajos de Apex antes de implementar los cambios en el código Apex. Vuelva a programar los trabajos después de la implementación.
• Active implementaciones con trabajos de Apex en la interfaz de usuario de Salesforce en la página Ajustes de implementación.

Si se crea un registro en una prueba Apex, el registro de prueba no se marca como visto. Por lo tanto, las pruebas Apex con consultas que filtran por LastViewedDate fallan durante la implementación y pueden causar fallos de cobertura de código. Para marcar un registro como visto en una prueba Apex, utilice primero la cláusula FOR VIEW y luego filtre por LastViewedDate.

Esta prueba Apex de ejemplo utiliza la cláusula FOR VIEW antes de filtrar por LastViewedDate.

@isTest
public class AccountViewTest {

    @testSetup
    static void myTestSetup() {
        Account a = new Account();
        a.Name = 'Test Account';
        insert a;
    }

    @isTest
    static void testMethod1() {
        List<Account> aForView = [Select Id, Name from Account LIMIT 1 FOR VIEW];
        List<Account> a = [Select Id, Name from Account where LastViewedDate = TODAY LIMIT 1];
        System.assertEquals(1, a.size());
    }

}

Campos personalizados

• Para cambiar el tipo de datos de un campo personalizado, puede utilizar conjuntos de cambios. No obstante, la implementación se retrasa a veces con la actualización de tantos registros. Considere cambiar el destino a través de la interfaz de usuario en su lugar.

Objetos personalizados

• Puede encontrar un error si está implementando un conjunto de cambios con un objeto personalizado que cuenta con una relación principal-subordinado sin el campo principal/detalle en el mismo conjunto de cambios. Para resolver este error, incluya el campo personalizado principal/detalle en el conjunto de cambios, incluso si no cambió el valor predeterminado general.
• No es posible insertar un objeto personalizado, actualizar el campo sharingModel de un objeto y agregar una nueva regla de colaboración basada en propietario de forma simultánea. En su lugar, son necesarias tres implementaciones individuales. En primer lugar, implemente el objeto personalizado, luego implemente el sharingModel actualizado del objeto y, a continuación, implemente la nueva regla de colaboración basada en propietario. Puede actualizar el campo sharingModel y agregar una regla de colaboración de usuario invitado o basada en criterios en una sola implementación.

Flujos

• Si piensa implementar un flujo utilizando conjuntos de cambios, considere los límites de la compatibilidad de migración. Asegúrese de que sus flujos únicamente hacen referencia a campos y componentes disponibles en los conjuntos de cambios.
• Solo puede incluir una versión de un flujo en un conjunto de cambios.
• Si el flujo no tiene ninguna versión activa al cargar el conjunto de cambios saliente, se utilizará la versión inactiva más reciente.
• Cuando visualice los componentes dependientes del conjunto de cambios, la página Dependencias de componentes enumerará las dependencias de <i>todas</i> las versiones del flujo. Agregue todos los componentes interdependientes de la versión de flujo relevante al conjunto de cambios saliente.
• Un flujo activo en un conjunto de cambios estará implementado en su destino como inactivo. Active el flujo manualmente después de la implementación.
• La implementación o reimplementación de un flujo utilizando conjuntos de cambios creará una versión del flujo en el destino.
• En organizaciones de producción, puede activar la configuración para implementar una nueva versión activa de un proceso o flujo a través de conjuntos de cambios o API de metadatos. La configuración no aparece en organizaciones no de producción, como borrador, sandbox y organizaciones de desarrollador, porque siempre puede implementar una nueva versión activa.

Permisos

Consulte Conjuntos de permisos y ajustes de perfil en conjuntos de cambios

Formato de página

Las implementaciones que contengan un tipo de registro y perfil, pero no el formato de página asignado para ese tipo de registro, eliminarán la asignación de formato existente del perfil para ese tipo de registro. Incluya siempre todos los formatos de página para todos los tipos de registro necesarios en el conjunto de cambios.

Valores de lista de selección

Los valores de un campo de lista de selección en un destino que no se incluyen en el conjunto de cambios se establecen en inactivos.

Por ejemplo, si la lista de selección de destino incluye un valor activo de 1, y la lista de selección del conjunto de cambios no incluye 1 como valor, 1 cambia de activo a inactivo en el destino.

Colaboración

No se admite la actualización del campo sharingModel para un objeto y agregar una nueva regla de colaboración basada en propietario de forma simultánea. Puede agregar una regla de colaboración basada en propietario cuando el valor predeterminado de general es público, y luego actualizar el sharingModel, lo que da como resultado un nuevo cálculo de colaboración único. Puede implementar una regla de colaboración de usuario invitado o basada en criterios y cambios en el campo sharingModel juntos utilizando componentes del conjunto de cambios.

Clases de Apex y desencadenadores de Apex

De forma predeterminada, los cambios en el código Apex que tiene trabajos de Apex pendientes o en curso no se pueden implementar. Para implementar estos cambios, realice uno de los siguientes pasos.

• Cancele los trabajos de Apex antes de implementar los cambios en el código Apex. Vuelva a programar los trabajos después de la implementación.
• Active implementaciones con trabajos de Apex en la interfaz de usuario de Salesforce en la página Ajustes de implementación.

Si se crea un registro en una prueba Apex, el registro de prueba no se marca como visto. Por lo tanto, las pruebas Apex con consultas que filtran por LastViewedDate fallan durante la implementación y pueden causar fallos de cobertura de código. Para marcar un registro como visto en una prueba Apex, utilice primero la cláusula FOR VIEW y luego filtre por LastViewedDate.

Esta prueba Apex de ejemplo utiliza la cláusula FOR VIEW antes de filtrar por LastViewedDate.

@isTest
public class AccountViewTest {

    @testSetup
    static void myTestSetup() {
        Account a = new Account();
        a.Name = 'Test Account';
        insert a;
    }

    @isTest
    static void testMethod1() {
        List<Account> aForView = [Select Id, Name from Account LIMIT 1 FOR VIEW];
        List<Account> a = [Select Id, Name from Account where LastViewedDate = TODAY LIMIT 1];
        System.assertEquals(1, a.size());
    }

}

Procesos de aprobación

• Para usar los procesos de aprobación de los artículos de Salesforce Knowledge con la API de metadatos es necesario implementar el tipo de artículo. Los tipos de acción compatibles con la versión de artículo (_kav) de los procesos de aprobación son los siguientes: acción de Knowledge, alerta de email, actualización de campo y mensaje saliente.
• Si el proceso de aprobación hace referencia a cualquier plantilla de publicación que contenga campos personalizados, vuelva a guardar esas plantillas de publicación en la organización de origen antes de agregarlas al conjunto de cambios. Desde Configuración, en el cuadro Búsqueda rápida, ingrese Plantillas de publicación y, a continuación, seleccione Plantillas de publicación. Para cada plantilla de publicación, haga clic en Modificar y luego en Guardar.
• Los metadatos no incluyen el orden de los procesos de aprobación activos. Puede ser necesario volver a ordenar los procesos de aprobación en el destino después de la implementación.
• Si cambia el Nombre exclusivo de un proceso de aprobación que se incluyó anteriormente en un conjunto de cambios e implementado en otra organización y vuelve a enviar el proceso de aprobación a través de un conjunto de cambios, se crea un nuevo proceso de aprobación después de la implementación en la otra organización. No se modifica el proceso de aprobación implementado previamente.

Proveedores de autenticación

A partir de noviembre de 2022, si un conjunto de cambios incluye un proveedor de autenticación con un secreto de consumidor definido, el secreto de consumidor se cambia a un valor de marcador de posición. Debe insertar el secreto de consumidor manualmente durante la implementación del conjunto de cambios.

Campos personalizados

Desde la API versión 30.0, al implementar un nuevo campo personalizado, los valores predeterminados de los campos Modificable y Legible en los permisos de campos de perfil son falso. Para sobrescribir los valores predeterminados, incluya permisos de campos para los nuevos campos de sus perfiles.

Objetos personalizados

No es posible insertar un objeto personalizado, actualizar el campo sharingModel de un objeto y agregar una nueva regla de colaboración basada en propietario de forma simultánea. En su lugar, son necesarias tres implementaciones individuales. En primer lugar, implemente el objeto personalizado, luego implemente el sharingModel actualizado del objeto y, a continuación, implemente la nueva regla de colaboración basada en propietario. Puede actualizar el campo sharingModel y agregar una regla de colaboración de usuario invitado o basada en criterios en una sola implementación.

Aplicación conectada

• No puede establecer la consumerKey en la API de metadatos. Se incluye en una operación de recuperación con fines informativos. Si intenta trasladar la aplicación conectada a otra organización deberá eliminar la Clave de consumidor del archivo .zip antes de la implementación en una organización. Se genera una nueva clave en el destino.
• La configuración móvil de las aplicaciones conectadas no es compatible con los conjuntos de cambios y deben migrarse manualmente.

Grupos

Los miembros del grupo público no se migran cuando implementa el tipo de grupo.

Relaciones principal-detalle

Una implementación de la API de metadatos que incluye relaciones principal-detalle elimina todos los registros de detalles en la papelera de reciclaje en estos casos.

• Para una implementación con un nuevo campo principal-detalle, elimine (envíe a la papelera de reciclaje) todos los registros de detalles antes de continuar para implementar el campo principal-detalle, o se producirá un error en la implementación. Durante la implementación, los registros de detalles se eliminan de forma permanente de la papelera de reciclaje y no se pueden recuperar.
• Para una implementación que convierta una relación de campo de búsqueda en una relación principal-detalle, los registros de detalles deben hacer referencia a un registro principal o eliminarse (enviarse a la papelera de reciclaje) para que la implementación se realice correctamente. No obstante, si se realiza una implementación correcta, se eliminan de forma permanente los registros de detalles de la papelera de reciclaje.

Formato de página

Una implementación que contenga asignaciones de formato de página sustituye a todas las asignaciones de formato de página existentes en la organización de destino con las asignaciones especificadas en el archivo .zip. Los formatos de página existentes en la organización desaparecen si no se incluyen en el archivo .zip. Incluya siempre todos los formatos de página para todos los tipos de registro necesarios en el archivo .zip.

Valores de lista de selección

Los valores de un campo de lista de selección en una organización de destino que no se incluyen en el metadatos se establecen como inactivos.

Por ejemplo, si la organización de destino tiene una lista de selección que incluye un valor activo de 1, y los metadatos no incluyen un valor de lista de selección de 1, 1 cambia de activo a inactivo en la organización de destino.

Perfiles

Si un paquete incluye un perfil con un nombre que no exista en el destino, se creará un nuevo perfil con ese nombre. Si el perfil implementado no especifica ningún permiso o configuración, el perfil resultante consta de todos los permisos y configuraciones del Perfil estándar.

Los campos personalizados en el objeto ContentVersion están disponibles para todos los usuarios de perfil. Cuando exporta metadatos de perfil, se exponen todos los campos personalizados.

Colaboración

• Mediante la API versión 29.0, no puede cambiar el sharingModel de un objeto utilizando la API de metadatos. Cambie manualmente el destino a través de la interfaz de usuario.
• Desde la API versión 30.0, puede cambiar el sharingModel de un objeto para usuarios internos utilizando la API de metadatos y la interfaz de usuario.
• No se admite la actualización del campo sharingModel para un objeto y agregar una nueva regla de colaboración basada en propietario en la API de metadatos. Puede agregar una regla de colaboración basada en propietario cuando el valor predeterminado de general es público, y luego actualizar el sharingModel, lo que daría como resultado un nuevo cálculo de colaboración único. Puede implementar una regla de colaboración de usuario invitado o basada en criterios y cambios en el campo sharingModel juntos utilizando la API de metadatos.

Flujo de trabajo

El modo de prueba para desencadenadores de flujo no es compatible en la API de metadatos. Si desea que un desencadenador de flujo ejecute la versión de flujo más reciente cuando un administrador haga que se active la regla de flujo de trabajo, habilite el modo de prueba a través de la interfaz de usuario tras la implementación.