Skip to content

Etiqueta: Correo electrónico

Eliminación definitiva de registros con Salesforce Flow

Eliminación definitiva de registros con Salesforce Flow

Última actualización el 22 de mayo de 2023 por Rakesh Gupta

Gran idea o pregunta duradera:

  • ¿Cómo eliminar registros de Salesforce utilizando Flow?

Objetivos:

Después de leer este blog, podrá:

  • Comprender la anotación @InvocableMethod
  • Más información sobre el método database.emptyRecycleBin
  • Configurar la acción de Apex para eliminar registros de forma permanente de Flow
  • Configurar el flujo de pantalla con el elemento Eliminar registro
  • Y mucho más

¿Qué es la eliminación completa?

La eliminación definitiva es la eliminación permanente de los registros especificados de la Papelera de reciclaje. Cuando los datos se eliminan de forma permanente, es casi imposible recuperarlos. Esto generalmente se logra a través de los métodos Database.EmptyRecycleBin .

Al vaciar los contenedores de reciclaje, tenga en cuenta las siguientes reglas y pautas:

  • Una vez que los registros se eliminan de la Papelera de reciclaje mediante esta llamada, se pueden consultar mediante queryAll() durante algún tiempo. Por lo general, este tiempo es de 24 horas, pero puede ser más corto o más largo.
  • Una vez que los registros se eliminan mediante la llamada Database.EmptyRecycleBin , no se pueden recuperar.

Warren Mason es administrador de sistemas en Gurukul on Cloud (GoC). En GoC están utilizando Salesforce Flow para optimizar los procesos de ventas. Warren tiene un requisito para eliminar clientes potenciales sin correo electrónico. Está construyendo un flujo de pantalla:

  1. Descubra todos los clientes potenciales sin correo electrónico
  2. Eliminar definitivamente tales clientes potenciales

Enfoque de Campeón de Automatización (I-do):

Si bien esto se puede resolver con varias herramientas de automatización como Apex Trigger y otras, usaremos Salesforce Flow y llamaremos a un método de Apex . Para llamar a un método de Apex , agregue el elemento Acción a su Flujo de Salesforce y seleccione una clase de Apex con una anotación @InvocableMethod .

En este artículo, usaremos la llamada clase de base de datos EmptyRecycleBin . Con Database.EmptyRecycleBin es posible borrar los registros de Salesforce. El método EmptyRecycleBin() elimina los registros de la papelera de reciclaje inmediatamente. A partir del lanzamiento de Summer'23 , no es posible acceder directamente al método EmptyRecycleBin desde Flow, por eso estamos usando la clase Apex Invocable.

Antes de discutir la solución, permítame mostrarle un diagrama del proceso a un alto nivel. Dedique unos minutos a revisar el siguiente diagrama de flujo para comprenderlo.

Comencemos a construir este proceso de automatización.

Práctica guiada (nosotros hacemos):

Hay 2 pasos para resolver el requisito comercial de Warren usando Screen Flow . Debemos:

  1. Cree una clase de Apex y una clase de prueba para eliminar registros de forma permanente de la Papelera de reciclaje.
  2. Flujo de fuerza de ventas
    1. Definir propiedades de flujo para el flujo de pantalla
    2. Agregue un elemento Obtener registros para encontrar todos los clientes potenciales sin dirección de correo electrónico
    3. Agregue un elemento de decisión para verificar los clientes potenciales encontrados o no (del paso 2)
    4. Agregue el elemento Eliminar registros para eliminar clientes potenciales
    5. Agregar acción: llame a Empty RecycleBin Invocable Apex Class

Paso 1: Cree una clase de Apex y una clase de prueba

Ahora, tenemos que comprender una nueva anotación de Apex, es decir, @InvocableMethod . Esta anotación nos permite usar un método de Apex como algo que se puede llamar desde Flow y Apex. Los métodos invocables se llaman con la API REST y se usan para invocar un solo método de Apex. Los métodos invocables tienen valores de entrada y salida dinámicos y admiten llamadas de descripción.

La anotación InvocableVariable identifica una variable de clase utilizada como parámetro de entrada o salida para la acción invocable de un método InvocableMethod. Si crea su propia clase personalizada para usarla como entrada o salida de un método invocable, puede anotar variables de miembros de clase individuales para que estén disponibles para el método.

La anotación de variable invocable admite los modificadores que se muestran en este ejemplo.


@InvocableVariable(label='variableLabel' description='variableDescription' requerido=(verdadero | falso))

La clase EmptyRecycleBin contiene dos variables, una para eliminar un solo registro y otra para manejar la eliminación de varios registros. Siéntase libre de pasar el valor a una o ambas variables según sea necesario. Cree la siguiente clase en su organización.


clase pública EmptyRecycleBin { @InvocableMethod(label='Papelera de reciclaje vacía' description='Eliminar permanentemente los registros de la Papelera de reciclaje.' iconName='slds:estándar:record_delete' categoría = 'Acciones de Apex personalizadas') ejecución de vacío estático público (Lista <Solicitudes> lista de solicitudes) { List<SObject> recordstoDelete = New List<SObject>(); para (Solicitudes req: lista de solicitudes) { if(req.obj != null){ recordstoDelete.add(req.obj); } if(req.listofSObjects != null){ recordstoDelete.addAll(req.listofSObjects); } } if(registrosparaEliminar.tamaño()>0){ Database.emptyRecycleBin(registrosparaEliminar); } } Solicitudes de clases públicas{ @InvocableVariable (descripción ='Aceptar un registro de tipo SObject.' requerido=falso) objeto público SObject; @InvocableVariable (descripción ='Aceptar múltiples registros de un tipo SObject.' requerido=falso) public List<SObject> listofSObjects; }
}

Copie el código de GitHub o instálelo usando esta URL .

Paso 2.1: Definir propiedades de flujo

  1. Haga clic en Configuración .
  2. En el cuadro Búsqueda rápida, escriba Flujos .
  3. Seleccione Flujos y luego haga clic en Nuevo flujo .
  4. Seleccione el flujo de pantalla   opción y haga clic en Crear y configurar el flujo.
  5. Se abrirá el diseñador de flujo para usted.

Paso 2.2: Adición de elementos Obtener registros para encontrar clientes potenciales sin correo electrónico

El siguiente paso es usar el objeto Prospecto para encontrar los prospectos sin dirección de correo electrónico.

  1. En Flow Designer, haga clic en el icono + y seleccione el elemento Obtener registros .
  2. Introduzca un nombre en el campo Etiqueta ; el nombre de la API se completará automáticamente.
  3. Seleccione el objeto Prospecto de la lista desplegable.
  4. Seleccione Se cumplen todas las condiciones (Y) .
  5. Establecer condiciones de filtro
    1. Fila 1:
      1. Campo : Correo electrónico
      2. Operador : Igual
      3. Valor : {!$ConstanteGlobal.EmptyString}
  6. Cuántos registros almacenar:
    1. Seleccionar todos los registros
  7. Cómo almacenar datos de registro:
    1. Elija la opción para Almacenar automáticamente todos los campos .

Paso 2.3: uso del elemento de decisión para verificar la variable de recopilación de registros (del paso 2)

Ahora usaremos el elemento Decisión para comprobar la Variable de recopilación de registros del paso 2 para saber si devuelve el cliente potencial o no.

  1. En Flow Designer, haga clic en el icono + y seleccione el elemento Decisión .
  2. Introduzca un nombre en el campo Etiqueta ; el nombre de la API se completará automáticamente.
  3. En Detalles del resultado , ingrese la etiqueta que el nombre de la API se completará automáticamente.
  4. Requisitos de condición para ejecutar el resultado : se cumplen todas las condiciones (Y)
    1. Fila 1:
      1. Recurso: {!Get_Leads}
      2. Operador: es nulo
      3. Valor: {!$ConstanteGlobal.Falso}
    2. Haga clic en Listo .

Paso 2.4: Agregar acción: eliminar registros para eliminar clientes potenciales

El siguiente paso es eliminar los clientes potenciales que encontramos en el Paso 2.2 . Para ello utilizaremos el elemento Eliminar Registros .

  1. En Flow Designer, debajo del nodo , haga clic en el icono + y seleccione el elemento Eliminar registros .
  2. Introduzca un nombre en el campo Etiqueta ; el nombre de la API se completará automáticamente.
  3. Para Cómo encontrar registros para eliminar, seleccione Usar los ID almacenados en una variable de registro o una variable de colección de registros .
  4. Selecciona el   {!Get_Leads} de la lista desplegable.
  5. Haga clic en Listo.

Paso 2.5: Adición de una acción para llamar a una clase de Apex invocable

  1. En Flow Designer, haga clic en el icono + y seleccione el elemento Acción .
  2. Seleccione la clase de Apex invocable EmptyRecycleBin .
  3. Ingrese un nombre en el campo Etiqueta : el nombre de la API se completará automáticamente.
  4. Establecer valores de entrada:
    1. Objeto para “listofSObjects” (Entrada) : Lead
    2. Objeto para "obj" (Entrada) : Plomo
  5. Almacenar valores de entrada
    1. listofSObjects : {!Get_Leads}
  6. Haga clic en Listo .

Al final, Warren's Flow se verá como la siguiente captura de pantalla:

Una vez que todo se vea bien, guarde el flujo.

Prueba de concepto

  1. Creé 201 clientes potenciales sin una dirección de correo electrónico para probar el flujo anterior.
  2. Ahora ejecute el flujo de pantalla y espere a que se complete el flujo.
  3. Vuelva a la Papelera de reciclaje para asegurarse de que los clientes potenciales se hayan eliminado definitivamente.

Evaluación formativa:

¡Quiero saber de ti!

¿Qué es una cosa que aprendiste de esta publicación? ¿Cómo imagina aplicar este nuevo conocimiento en el mundo real? Siéntase libre de compartir en los comentarios a continuación.

Seguir leyendo

Muévete a 2GP Administrado con Migraciones de Paquetes ☁️

Muévete a 2GP Administrado con Migraciones de Paquetes ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

Pasar a 2GP administrado con migraciones de paquetes | Blog de desarrolladores de Salesforce

Han pasado casi cuatro años desde que lanzamos por primera vez el paquete administrado de segunda generación (2GP) , que permite a nuestros socios de AppExchange crear y distribuir soluciones utilizando un modelo de desarrollo basado en CLI, basado en fuente y fácil de automatizar.

Desde entonces, recibimos una gran cantidad de excelentes comentarios de nuestra comunidad de desarrolladores, y continuamos innovando en múltiples áreas relacionadas con la experiencia del desarrollador, el rendimiento, la paridad del tipo de metadatos con el paquete administrado de primera generación (1GP), etc. Cada vez que nos reunimos con desarrolladores de ISV, constantemente escuchamos sobre la necesidad de que Salesforce los ayude a ellos y a sus clientes a pasarse al mundo de 2GP.

¡Hoy, tengo algunas noticias emocionantes para compartir con todos ustedes! Estamos abordando la pregunta n.º 1 de nuestros desarrolladores de ISV al presentar una nueva función: Migraciones de paquetes . En pocas palabras, Package Migrations automatiza por completo el proceso de convertir paquetes 1GP a 2GP y migra sin problemas a los clientes con paquetes instalados a 2GP. Si es un socio ISV que crea paquetes administrados, ¡esta publicación de blog es para usted!

Antes de sumergirnos en los detalles de las migraciones de paquetes, echemos un vistazo a algunos beneficios de usar 2GP para el desarrollo de paquetes.

Beneficios de usar 2GP para el desarrollo de paquetes

En el corazón de 2GP se encuentra un modelo de desarrollo basado en fuente, donde un repositorio de código fuente como Git representa la fuente de la verdad para su paquete. Esto es fundamentalmente diferente del mundo de 1GP, donde utiliza una organización de empaquetado para mantener todos los metadatos que desea empaquetar y distribuir a sus clientes.

Este modelo de desarrollo impulsado por la fuente, impulsado por la CLI de Salesforce , puede aumentar drásticamente la productividad y la colaboración de su equipo. Los desarrolladores pueden usar Dev Hub para activar rápidamente organizaciones temporales , crear una función de forma conjunta y comprometerla con el control de código fuente. Cuando esté listo para distribuir una nueva versión de su 2GP, simplemente extraiga la rama correspondiente a una máquina local y use la CLI para crear su nueva versión del paquete.

Es importante destacar que este enfoque basado en CLI también significa que puede integrar fácilmente su proceso de empaque por completo en CI/CD, lo que facilita la automatización completa de su flujo de trabajo. Puede, por ejemplo, ejecutar automáticamente Salesforce Code Analyzer en una base de código y, siempre que no se encuentren problemas, crear una nueva versión del paquete.

En el mundo de 1GP, estabas atrapado usando un espacio de nombres diferente para cada uno de tus paquetes. En 2GP, todos sus paquetes pueden compartir el mismo espacio de nombres, lo que le permite aprovechar un enfoque verdaderamente modular para el desarrollo de paquetes para mantener sus paquetes bien organizados. También es posible declarar explícitamente dependencias entre paquetes , asegurando que todo funcione en conjunto sin problemas.

Con 2GP, también obtiene un control de versiones flexible, lo que le permite abandonar versiones de paquetes que ya no desea utilizar. En su lugar, puede especificar un ancestro de la versión del paquete y crear efectivamente una nueva rama en la que desee continuar con su desarrollo.

Finalmente, apoyar a los clientes nunca ha sido tan fácil con 2GP. En el mundo de 1GP, los parches solo se pueden crear desde una organización de parches. Con el modelo de desarrollo basado en el código fuente de 2GP, puede simplemente crear una versión del paquete de parches directamente desde la CLI y, siempre que el parche cumpla con los requisitos relacionados con los cambios menores y la ascendencia del paquete, se crea y está listo para instalarse en la organización de su cliente.

Dicho todo esto, 2GP puede agregar mucho valor a su proceso de desarrollo. ¡Ahora, averigüemos cómo las Migraciones de paquetes pueden ayudarlo a llegar al mundo de 2GP!

Introducción a las migraciones de paquetes

Package Migrations amplía la funcionalidad de 2GP con comandos CLI adicionales y capacidades adicionales para ayudar a los desarrolladores de ISV a realizar una transición completa al mundo de 2GP. Actualmente se encuentra en Developer Preview y está abierto para que todos los desarrolladores de ISV lo prueben en sus paquetes 1GP existentes. ¡Siga leyendo para saber cómo participar en la versión preliminar para desarrolladores!

Hay dos elementos para las migraciones de paquetes: conversión de paquetes y migración de paquetes.

La conversión de paquetes se inicia a través del nuevo comando sf package convert . Toma una versión específica de su paquete 1GP existente (Acme v1.0 en este ejemplo) y usa algo de magia detrás de escena para convertirlo en una versión de paquete 2GP correspondiente (Acme v1.0.0.1 usando la numeración de versión 2GP).

Una vez que tenga una versión de paquete 2GP convertida, puede migrar clientes a 2GP. Si tiene un suscriptor con Acme v1.0 instalado, iniciaría el proceso tratándolo como una actualización de paquete normal: a través de la CLI con sf package install (ver documentos ), instalación de URL o actualizaciones automáticas.

Mientras intenta instalar su paquete 2GP convertido v1.0.0.1, que coincide con la versión mayor.menor del paquete 1GP instalado en el suscriptor A, ejecutamos una nueva lógica que inicia el proceso de migración del paquete . Sin cambiar ningún metadato en la organización del cliente, y sin requerir la intervención del usuario si usa actualizaciones automáticas, simplemente cambiamos las referencias del paquete para que apunten al nuevo paquete 2GP.

Una vez que un cliente migre a 2GP, cualquier parche o actualización del paquete de este cliente deberá usar 2GP.

Participación en la versión preliminar para desarrolladores de migraciones de paquetes

Para probar las migraciones de paquetes, debe ser un socio ISV con acceso a la comunidad de socios de Salesforce .

En la Comunidad de socios, encontrará un canal exclusivo para esta versión preliminar para desarrolladores. Le recomendamos que se una a este canal y configure las notificaciones para enviar por correo electrónico cada publicación para recibir las últimas actualizaciones del equipo de Migraciones de paquetes.

En este canal, encontrará una serie de enlaces útiles, incluido un formulario para registrarse en Developer Preview. Necesitaremos algunos detalles, como su ID de organización de empaquetado, para que podamos activar la función Migraciones de paquetes.

Es importante destacar que participar en Developer Preview no tendrá ningún impacto en su paquete de 1GP. Por lo tanto, no se preocupe y participe, ya que sus comentarios son esenciales para ayudarnos a identificar y resolver problemas lo antes posible.

Una vez que esté activado, puede comenzar a probar las migraciones de paquetes.

Probar la conversión de un paquete administrado de primera generación

Muy bien, ¡comencemos! En primer lugar, asegúrese de haber instalado la CLI de Salesforce.

Si lo instaló anteriormente, asegúrese de estar usando la última versión:

sf update

Ahora asegúrese de que está ejecutando dentro del contexto de un proyecto de SalesforceDX. Puedes crear un nuevo proyecto usando:

sf project generate --name <Your project name>

Vincule el espacio de nombres de su 1GP administrado iniciando sesión en su DevHub y siga los pasos .

¡Eso es todo para la configuración! Ahora puede continuar e intentar convertir su paquete.

sf package convert --installation-key mdpTest --package 033xxx --wait 20

Repasemos los parámetros. Estamos utilizando la clave de instalación mdpTest . Será necesario cada vez que intente instalar esta versión del paquete en el futuro. Alternativamente, puede usar --installation-key-bypass para omitir la clave de instalación. Deberá ingresar su ID de paquete 1GP completo comenzando con 033 después de --package . El proceso de conversión puede demorar un poco y, por lo tanto, agregamos la opción --wait para esperar 20 minutos.

A medida que se ejecuta el proceso de conversión, obtendrá una actualización de su estado. Suponiendo que todo salió bien, recibirá un mensaje de éxito con la ID y la URL de instalación para la versión del paquete 2GP recién convertida.

Converting Package... ... Successfully created the package version [08cxxx00000KzFSAA0]. Subscriber Package Version Id: 04txxx00000u1cqAAA
Package Installation URL: https://login.salesforce.com/packaging/installPackage.apexp?p0=04txxx00000u1cqAAA
As an alternative, you can use the "sfdx package:install" command.

¡Felicitaciones, su paquete ahora está convertido a 2GP! Si encontró algún problema en el camino, infórmenos utilizando el formulario en el grupo Comunidad de socios .

Nota: Al momento de escribir esta publicación de blog, este comando convertirá la última versión administrada y lanzada de su paquete. Estamos trabajando para permitirle convertir versiones de paquetes Beta y anteriores. Por otro lado, durante Developer Preview, no es posible promocionar paquetes 2GP convertidos al estado Lanzado.

Ahora que su paquete está convertido, probemos la migración de una organización suscriptora.

Probar la migración de un paquete administrado de primera generación instalado

Para probar la migración de un suscriptor, deberá crear una organización borrador ya que, durante la versión preliminar para desarrolladores, solo admitimos organizaciones borrador. Puede configurar una nueva organización borrador como esta:

sf org create scratch -f project-scratch-def.json -a MyScratchOrg

En el código anterior, -f apunta a su archivo de definición de organización borrador . Debe asegurarse de que su archivo de definición de organización borrador incluya cualquier función de Salesforce de la que pueda depender su paquete. Finalmente, estamos usando MyScratchOrg como el alias de esta organización.

Con la configuración de la organización borrador, continúe e instale la versión del paquete 1GP que convirtió anteriormente utilizando la URL de instalación que obtiene de su organización de empaquetado 1GP. Esta debería ser su última versión administrada y lanzada en este momento.

Puede confirmar que el paquete se instaló correctamente durante la pantalla de instalación. Vea el ejemplo a continuación.

Y consulte la sección Paquetes instalados del menú Configuración.

Ahora que instaló su 1GP en la organización borrador, está listo para la migración.

Inicie el proceso de migración utilizando la URL de instalación que recibió al final del proceso de conversión del paquete:

https://login.salesforce.com/packaging/installPackage.apexp?p0=04txxx00000u1cqAAA

Ahora pasará por el mismo conjunto de pantallas que el anterior, pero esta vez para su paquete 2GP convertido.

Actualmente, la interfaz de usuario muestra que la "instalación" se ha completado. En realidad, lo que hicimos fue una migración de paquetes que se completó con éxito.

Tenga en cuenta que en este ejemplo, he usado la segunda compilación Beta para la versión 1.7, que corresponde a la misma versión mayor.menor que la versión del paquete 1GP instalada anteriormente. Como el 2GP convertido, durante la Vista previa del desarrollador, se crea como una versión Beta, se muestra como tal.

Una vez más, puede confirmar la versión del paquete actualizado en la sección Paquetes instalados del menú Configuración, que también muestra, en este ejemplo, que el número de versión es 1.7 (Beta 2).

Una vez que haya migrado el paquete en su organización borrador, le recomendamos que lo pruebe para asegurarse de que funciona como se esperaba.

También debe aprovechar la oportunidad para verificar si las aplicaciones, como la aplicación de administración de licencias o la aplicación de administración de funciones, muestran la información correcta para su paquete migrado. Si encuentra algo que no está bien, por favor plantéelo como un problema y lo investigaremos.

Mientras tanto …

Se necesitarán algunos lanzamientos para que las migraciones de paquetes estén disponibles de forma general. Su participación en Developer Preview, probando sus paquetes y brindándonos comentarios, es esencial para ayudarnos a identificar y resolver problemas antes.

Mientras tanto, ¿qué más puedes hacer? Le recomendamos que experimente con el uso de paquetes de segunda generación como parte de su modelo de desarrollo actual basado en 1GP. ¿Confundido? Dejame explicar.

Como mencioné a