Acciones Dependientes del Tiempo – Parte 2 – Process Builder

En la publicación de esta semana, continuaremos con la implementación de acciones dependientes del tiempo. La semana anterior aprendimos cómo usar las reglas de flujo de trabajo, para lograrlo. Ahora veremos cómo hacerlo usando el Process Builder.

robot automatización fábrica industria máquina equipo Ingenieria trabajo Robótico tecnología producción mecánico fabricar metal proceso Tecnología taller dispositivo línea fuente ilustración arquitectura clipart diseño gráfico personaje de ficción gráficos animación casa art

El poder usar Acciones dependientes del tiempo nos tomará más de un click a la hora de hacerlo en el Process Builder, ya que la opción de activarlo está un poco oculta, pero al final del artículo tendremos claro que pasos seguir.

Process Builder (Generador de Procesos)

Empezamos dirigiendonos a

Configuración > Automatización de Procesos > Process Builder.

En algunas instancias lo encontraremos como Generador de Procesos.

Al darle click se nos presentará la pantalla de inicio.

A diferencia de la mayoría de herramientas que puede usar un Administrador. Al Seleccionar Process Builder, perdemos el menu de opciones de configuración de la izquierda y cuando necesitemos volver a ella debemos dar click en el botón de la esquina superior derecha Volver a Configuración

Damos click en el botón Nueva, de la esquina superior derecha

y nos aparece un formulario donde debemos ingresar

  • Nombre del proceso (Nombre descriptivo)
  • Nombre de la API (se llena automáticamente)
  • Descripción (Siempre llenarlo como buena práctica)
  • El proceso se inicia cuando * (veremos qué opción escoger a conitnuación)

¿Cuantos Process Builder crear?

A diferencia de las reglas de flujo de trabajo, donde creamos una nueva cada vez que deseamos cubrir un nuevo requerimiento. Las buenas practicas de los Process Builder nos indican que debemos crear un solo Process Builder por cada tipo de Objeto. En nuestro ejemplo, el objeto Caso.

Si a posteriori queremos agregar una nueva funcionalidad a Casos a través de Process Builder, debería seguir existiendo solo un Process Builder.

Si empezamos creando un Process Builder que tiene un nombre como Notifica caso abierto; Cuando necesitemos agregar otra función, lo más seguro es que vayamos directo a crear otro Process Builder, ya que si por ejemplo queremos Cerrar un caso, que esta función se realice en el Process Builder Notifica caso abierto empezará a ser confuso. Por eso vamos a empezar creando un Process Builder Maestro, que se inicie cuando Un registro cambia.

Nota: A pesar de que tenemos nuestra instancia en Español, los botones de Guardar o Cancelar estan en Inglés. Al parecer es una mejora que hay que sugerir a Salesforce.

Después de dar click en Save accedemos al lienzo del Process Builder

Debemos seleccionar el objeto cuyos cambios dispararán las acciones.

Damos Click en +Agregar objeto

Aparece un formulario en la parte derecha, en el cual buscamos Caso y lo seleccionamos.

Debido a que este es un Process Builder Maestro, en Iniciar el proceso* seleccionamos cuando se crea o se modifica un registro.

La opción solo cuando se crea el registro, limitaría los registros que entren al Process Builder y a este deberían entrar todos los registros nuevos o que se actualicen.

Nota: De requerir que las acciones se ejecuten sólo cuando se crea un registro, podemos usar la función ISNEW() en la condición que se evalúa, en los rombos de decisión (que se configuraran a continuación)

Damos Click en Guardar

Nuestro lienzo se ve de esta forma

Configurar las acciones

Es hora de validar las condiciones que se deben dar para que se ejecuten nuestras acciones. Y determinar si la acción se ejecute inmediatamente o en un tiempo posterior.

Recordemos que en este punto, en el Process Builder, se nos presentaban estas opciones

Podíamos seleccionar dos opciones que nos habilitaban las acciones dependientes del tiempo, y una que no.

En nuestro ejemplo, es como si hubiéramos seleccionado la segunda opción, Es decir, no podemos configurar Acciones dependientes del tiempo. Para activarlas en el Process Builder, debemos activar una casilla que está oculta por defecto. Veamos como se activa.

Empezamos configurando los criterios para que se ejecute nuestra acción.

Damos click en +Agregar criterios y se nos muestra un formulario a la derecha.

Ingresamos un nombre para este criterio.

La buena práctica es que esta sea una pregunta.

Si la respuesta es verdadera, se ejecutarán las acciones que configuremos (inmediatas o programadas)

Si la respuesta es falsa, o, puede detenerse la ejecución o seguir evaluándose las condiciones que sigan en el lienzo.

Llamaremos este criterio:

¿Sigue el caso abierto?

La lógica

En el Process Builder tenemos 3 opciones para especificar cuando el caso sigue abierto,

La más sencilla es Se han cumplido todas las condiciones, dónde linea a linea podemos seleccionar campos del caso y evaluar si es verdadera o falsa la condición. Esta opción es muy poderosa y la recomendada.

Podemos agregar cualquier cantidad de condiciones, donde se pueden cumplir todas (AND), algunas (OR) o unas Si y otras No (Personalizar la logica)

Si seleccionamos La fórmula es verdadera, accederemos a un editor de fórmulas, con una sintaxis similar a las fórmulas de Excel, por lo que será más fácil de usar para los que tienen experiencia ellas o con lenguajes de programación.

Aquí vemos el equivalente de la imagen anterior:

Si no hay condiciones, podemos seleccionar Sin criterios, solo ejecución de acciones. Pero no es nuestro caso.

Nuestro Criterio, se vería si en este momento.

Damos click en Guardar

En este punto, siguiendo las buenas prácticas de solo tener un Process Builder por objeto. No vamos a configurar las acciones directamente en este Process Builder Maestro, es decir no vamos a Crear la acción de Alerta de Correo Electronico aqui, sino que lo que vamos a hacer en otro Process Builder, un Process Builder Invocable que se pueda llamar desde otro Process Builder.

Estamos separando responsabilidades. El Process Bulder Invocable solo tendra la misión de enivar un correo Electronico cuando se cumplan las condiciones que el Proces Builder Matesto, dtermine.

De esta forma logramos dos cosas:

Reutlización: Si aparece otro escenario en el que debamos enviar la Alerta de correo electrónico, podemos invocar el Process Builder, sin tener que configurar todo desde cero.

Rastreo de Errores: Si la alerta deja de enviarse, empezaremos por revisar el Process Builder Invocable ya que es el que tiene esa responsabilidad.

Sin embargo, aún no lo hemos creado y no aparece en el menú de Procesos*, como se ve en la imagen.


Vamos a dejar este Process Builder en este punto y vamos a dar click en el botón Ver todos los procesos, arriba a la derecha

Nota: El Process builder se encuentra guardado, y podemos volver a él después para terminar de editarlo y finalmente activarlo para que empiece a funcionar.

Damos click en Nueva

Esta vez sí vamos a hacer el Process Builder específico, por lo que el nombre que debe indicar lo que va a hacer será Notifica caso abierto, y se disparará cuando Se invoca por otro Proceso

Damos click en Save

Se abre el lienzo del Process Builder. Escogemos de nuevo el objeto Caso

Damos Click en + Agregar criterios. Nuestro criterio siempre se va a cumplir, por lo que escogemos Sin criterios, solo ejecución de acciones. y le damos el nombre de Ejecutar.

El Process Builder Maestro será el que decida cuándo se debe Invocar este Process Builder y se envíe la Alerta de Correo Electrónico

Damos click en Guardar

En acciones inmediatas escogemos Alerta de Correo Electrónico, y seleccionamos la alerta previamente creada (la misma que usamos en la parte I)

Damos click en guardar, y activamos nuestro Process Builder, dando click en el botón Activar de la esquina superior derecha

Volvemos a la vista de todos los procesos, dando click en Ver todos los Procesos

Ahora podemos enlazar nuestro nuevo Process Builder invocable, sin embargo solo vemos la opción de Acciones Inmediatas.

Activar Acciones Programadas

Para activar las acciones dependientes del tiempo debemos dar click en

Sin embargo esta casilla está oculta. Para verla damos click en el Criterio, y a la derecha damos click en Avanzado, de modo que se expande esta sección y accedemos a ella.

Este es el equivalente al creado, y siempre que se modifique para cumplir criterios posteriores de la reglas de flujo de trabajo. Ver imagen

Volviendo al Process Builder. Ahora vemos una caja a la derecha de Acciones Inmediatas, llamada Acciones Programadas

Damos click en Definir programación, y seleccionamos

8 días después de que se cree el caso

Damos click en Guardar

Damos Click en + Agregar acción

y en Seleccionar y definir acción, escogemos Procesos en Tipo de acción

Le damos un Nombre de la acción descriptivo como Notifica caso abierto > 8 días, y en Procesar escogemos el Process Builder Invocable

Nota: Si el Process Builder invocable no aparece en la lista, debemos dar click en Volver a Configuración y volver a entrar a Process Builder desde

Configuración > Automatización de Procesos > Process Builder.

Al seleccionar el Process Builder invocable, nos aparecerá la sección Establecer variables del proceso,

Seleccionaremos el registro Case que inicio el proceso. Es decir le vamos a pasar los datos del caso desde el Process Builder Mestro al Process Builder Invocable.

Damos click en Choose

Damos Click en Guardar

Y Activar

Pruebas

Para verificar que nuestro Process Builder quedó correctamente configurado, Salesforce nos ofrece una herramienta de Supervisión, donde podemos ver las acciones que se ejecutarán en el futuro.

Para ellos vamos a en Lightning Experience a:

Configuración > Automatización de Procesos > Entrevistas de Fluj en Pausa

O en Classic a:

Configuración > Crear > Flujo de Trabajo y Aprobaciones > Flujos > Entrevistas en pausa o en espera

Para ver nuestra acción debemos crear un nuevo Caso o modificar uno existente de modo que empiece a cumplir la condición especificada.

En nuestro ejemplo, usaremos un caso existente, por lo que para que En nuestro ejemplo, usaremos un Caso existente, por lo que para que cumpla la condición, debe pasar de estar Cerrado a Abierto, (recordemos la frase siempre que se modifique para cumplir criterios posteriores)

Nota: En Lightning Experience no hay un botón de cerrar caso, y se debe crear un acción rápida para sustituirlo. Ver Close Case button/page in Lightning Experience

Si vamos a las entrevistas de flujo en pausa, veremos listada la nuestra,

Y si damos click , podemos ver otros detalles

Si comparamos la herramienta equivalente para monitorear reglas de flujo de trabajo, podemos notar que no tenemos mucha información. Esta funcionalidad aún está en desarrollo por lo que los invito a votar la idea Process Builder: Waiting Flow Interviews: Provide Better Information

Finalmente recordemos de la publicación anterior las Consideraciones sobre las acciones dependientes del tiempo y los desencadenadores de tiempo

Acciones Dependientes del Tiempo – Parte 1 – WorkFlow Rules

Download free photo of Stopwatch,time management,time,performance ...

Salesforce nos permite programar acciones para ser ejecutadas determinado tiempo después de que se cumplan ciertas condiciones que especifiquemos. En la entrada de hoy vamos a ver cómo lograrlo en las herramientas funcionales de la plataforma.

  • Workflow Rules (Reglas de flujo de trabajo)
  • Process Builder (Generador de procesos)
  • Flows (Flujos)

El escenario es el siguiente:

Tenemos el requerimiento de enviar un correo electrónico, 8 días después de la fecha apertura de un caso si el caso no se ha cerrado. Este correo notificará al supervisor para que le de seguimiento.

Nota: Esta acción se puede implementar de caja con las Reglas de distribución de casos, que por ser una funcionalidad de caja (OOB = “Out Of the Box”) debe ser nuestra primera opción a considerar. Sin embargo asumimos que no las tenemos disponibles y vamos a reemplazarlas.

Workflow Rules (Reglas de Flujo de Trabajo)

Iniciamos creando la regla de flujo de Trabajo, para esto vamos a

Configuración > Automatización de Procesos > Reglas de flujo de trabajo

Damos Click en Regla Nueva y seleccionamos el objeto, en este ejemplo Caso y damos click en Siguiente

En esta nueva pantalla vamos a definir el comportamiento que nos deja programar un acción que se ejecute en un momento posterior, conocida como Acción dependiente del tiempo.

Iniciamos con el Nombre y la Descripción

Ahora debemos escoger entre 3 opciones para los criterios de selección

Para poder usar acciones dependiente del tiempo. Debemos escoger:

creado, y siempre que se modifique para cumplir criterios posteriores

Ya que como se ve en la imagen si escogieramos la segunda opción, no podríamos asociar este tipo de acciones posteriormente.

Al escoger la opción creado, y siempre que se modifique para cumplir criterios posteriores, no solo accedemos a la opción de usar acciones dependiente del tiempo sino que también podemos usar cierto tipo de funciones avanzadas como:

  • PRIORVALUE: Vuelve el valor anterior de un campo.
  • ISCHANGED: Compara el valor de un campo con el valor anterior y devuelve TRUE si los valores son diferentes. Si los valores son idénticos, esta función devuelve FALSE.

Es así que nuestra regla va quedando de la siguiente forma:

Y debido al criterio de evaluación seleccionado, podemos proceder a relacionar una acción y que se ejecute en un momento en el futuro.

Para esto debemos agregar una acción de flujo de trabajo, que pueden ser de 4 tipos:

  • Crear Tarea
  • Alerta de Correo Electrónico
  • Actualización de Campo, que puede ser un campo del objeto de la regla o de un campo del objeto padre en una relacion Maestro-Detalle
  • Mensaje Saliente, que consiste en hacer un llamado a un sistema externo con un mensaje SOAP. En inglés se llama Outbound Message

Seleccionamos Acción existente

para escoger una Alerta de correo electrónico previamente creada. O podríamos crear una en el mismo momento.

Damos Click en Guardar.

Para especificar en qué momento en el futuro se ejecutara la acción, agregamos un Desencadenador de tiempo de flujo de trabajo

8 días después de que se cree el caso

Nuestra regla de flujo de trabajo, luce ahora así:

Damos Click en Listo

Y finalmente, procedemos a activar la Regla

Pruebas:

Para verificar que nuestra regla de flujo de trabajo quedó correctamente configurada, Salesforce nos ofrece una herramienta de Supervisión, donde podemos ver las acciones que se ejecutarán en el futuro. Para ellos vamos a

Configuración > Entornos > Flujo de trabajo basado en el tiempo

Para ver nuestra acción debemos crear un nuevo Caso o modificar uno existente de modo que empiece a cumplir la condición especificada.

En nuestro ejemplo, usaremos un Caso existente, por lo que para que cumpla la condición, debe pasar de estar Cerrado a Abierto, (recordemos la frase siempre que se modifique para cumplir criterios posteriores)

En nuestra próxima entrada ilustraremos el camino para hacer esto mismo con el Process Builder, la siguiente generación de herramientas para automatización en la mano de los administradores

Nota Final:

Recordemos que para usar Acciones dependientes del tiempo, teníamos dos opciones correctas y una incorrecta.

La mayor diferencia, es que si seleccionamos la segunda, cada vez que se deje de cumplir la condición que programa la acción, en nuestro ejemplo, que el caso se cierre, esta desaparecerá de la cola donde salesforce la mantiene hasta que se cumpla la fecha requerida. En cambio si seleccionamos solo creado, así el caso se hubiera cerrado.

Ver: Consideraciones sobre las acciones dependientes del tiempo y los desencadenadores de tiempo

Los nuevos límites de Salesforce

Resultado de imagen para limits

Una de las características de los últimos releases de Salesforce ha sido que algunos de sus límites ahora son más generosos o han desaparecido o que ahora nos da mas funcionalidades al mismo precio.

En esta entrada he recopilado algunas de ellas. Esperamos que esta tendencia continue en los proximos releases:

API

SOQL

SOSL

Llamados a sistemas externos

Process Builder y Flows

Procesos de Aprobación

Einstein Analytics

Componentes Lightning Web

Tamaño de los archivos de depuración

  • El tamaño de un log era 5 MB por lo que podía fácilmente quedar truncada la información que necesitábamos ver si no escogemos bien los niveles de depuración. Ahora el tamaño máximo es 20 MB por log y el límite máximo para la organización cambio de 250MB a 1.000 MB . Ver Store More and Larger Debug Logs

Autenticación

Comunidades

Traducciones

Permisos personalizados y reglas de validación mas sencillas

El dia de hoy vamos a conocer una funcionalidad un poco subutilizada que nos ofrece la plataforma. Son los Permisos personalizados.

Contexto

Un perfil está compuesto por casillas de seleccion que dan acceso a funcionalidades especificas. Por ejemplo, el permiso API activada

o el permiso Ver todos los datos

Hay situaciones donde quisieramos poder contar con un permiso como Modificar fecha de cierre de la oportunidad, y asignarselo solo a los usuarios indicados.

Normalmente este requirimiento de negocio, se aborda con una regla de validación como la siguiente

Vemos que se valida si el campo ya estaba lleno y si se está modificando

NOT(ISBLANK(PRIORVALUE(CloseDate))) && ISCHANGED(CloseDate) 

Y se pregunta si el perfil del usuario realizando la acción se llama Administrador del sistema

$Profile.Name <> 'Administrador del sistema'

Está es una solución completamente valida, pero empieza a presentar algunos incovenientes.

  • Qué pasa si se deben autorizar mas perfiles o usuarios especificos
  • Qué pasa si la instancia es multilenguaje.

Si se van a agregar mas perfiles, la regla podria terminar viendose así:

NOT(ISBLANK(PRIORVALUE(CloseDate)))&&
ISCHANGED(CloseDate) &&
$Profile.Name <> 'Administrador del sistema' &&
$Profile.Name <> 'Administrador del contrato' &&
$Profile.Name <> 'Administrador de soluciones' &&
$Profile.Name <> 'Custom: Support Profile' &&
$Profile.Name <> 'Gold Partner User' &&
$Profile.Name <> 'Partner Community User'

Y que al pasar el tiempo, podría crecer en longitud acercandose al límite de 5000 caracteres.

Si la instancia es multilenguaje, el nombre de los perfiles estándar se traduce al cambiar el idioma de la instancia, algo que no debería ocurrir con frecuencia, pero que al poder presentarse haría que Administrador del sistema se convierta en System Administrator y la regla de validación deje de funcionar.

Cómo usar permisos personalizados

En esta entrada proponemos una solución que tiene en cuenta estos escenarios y permite ser escalable facilmente.

Empezamos creando el permiso personalizado.

Vamos a configuración, y escribimos en busqueda rápida, Permisos personalizados

Seleccionamos y damos click en nuevo

Asignamos una valor en Etiqueta que sea corto y descriptivo y en el campo descripción explicamos su uso. Podemos seguir el ejemplo que vimos con el permiso API Activada .

Damos guardar.

Ya contamos con un permiso que podemos usar en la regla de validación.

Al volver a la regla, y dar click en insertar campo, en la sección Permission, vamos a encontrar nuestro permiso personalizado.

Y nuestra fórmula va a quedar así

NOT(ISBLANK(PRIORVALUE(CloseDate)))&&
ISCHANGED(CloseDate) &&
NOT($Permission.Modificar_Fecha_Cierre_Oportunidad)

Ahora solo nos resta, asignar este permiso a los perfiles que necesitemos. Es aqui donde vemos el poder de los permisos personalizados.

Para esto vamos al perfil, y damos click en Permisos personalizados, como se ve en la imagen

Para asignarlo, damos click en modificar y lo pasamos de la sección de Permisos personalizados disponibles a la de Permisos personalizados activados

Ahora nuestra sencilla expresión

$Permission.Modificar_Fecha_Cierre_Oportunidad

Devolvera verdadero si el perfil del usuario tiene este permiso y falso de lo contrario.

Podemos asignar este permiso a cuanto perfil deseamos, y automaticamente los usuarios con este perfil podrán, en este caso, cambiar la fecha de cierre de las oportunidades y nuestra regla de validación no tuvo que ser modificada.

Notas

  • Si deseamos asignar el permiso a un usuario específico y no a todos los de un perfil, podemos crear un conjunto de permisos y agregar de la misma manera que vimos con el perfil, el permiso al conjunto de permisos, y luego asignar el conjunto de permisos al usuario en particular.
  • Podemos validar permisos personalizados tambien a nivel de visualforce usando el campo de combinación global $Permission seguido del nombre API del permiso.
<apex:pageBlock rendered="{!$Permission.nombre_api_permiso}">
   <!-- Sección que solo se mostrará a los usuarios con el permiso adecuado-->
</apex:pageBlock>
  • Podemos validar permisos a nivel de Apex, usando el método FeatureManagement.checkPermission y pasando el nombre API del permiso
Boolean tienePermiso = FeatureManagement.checkPermission('<nombre_api_permiso>');

if (tienePermiso) {
    // Ejecutar código
}

Actualización Crítica de Lightning Experience – 07 Enero 2020

Desde el 7 de Enero y durante 72 horas se empezará a activar la actualiación crítica de Lightning Experience.

Está actualización busca que todas las instancias de Salesforce tengan activada la interfaz de usuario de Lightning Experience.

Durante varios años Salesforce ha incentivado el paso a Lightning Experience de manera gradual.

En este momento la experience de usuario se activará automaticamente,

sin embargo esto no implica que ya no se pueda usar Salesforce Classic o que todos los usuarios tengan que usar Lightning Experience. Esto es una decisión que deben tomar los administradores y Salesforce está incentivando a que la tomen pronto

Recomendamos seguir cada uno de los pasos del Asistente de transicion de Lightning Experience lo más pronto posible para empezar la migración a Lightning Experience si aún no lo han hecho

A continuación Salesforce nos explica detalladamente lo que hay que saber sobre esta actualización critica. Disponible con subtitulos en español.

Como anecdota, antes de la versión de Salesforce Classic que conocemos existia la versión de Salesforce Classic 2010. Aún es posible hoy en día activarla y volver en el tiempo.

Una prueba de que Salesforce Classic no se apagará inmediatamente pero también de que en cuestion de Interfaz de Usuario es mejor seguir evolucionando.

Componentes Lightning Web – Parte 2

Paso a Paso de como crear Componentes Lightning Web

Demo 0 – Crear scratch org

  1. Activar Dev Hub
  2. Clonar Repositorio
  3. Auth Dev Hub
  4. Crear scratch Org bear-tracking
  5. Hacer Push
  6. Asignar perm set
    • sfdx force:user:permset:assign -n Ursus_Park_User
  7. Importar datos
    • sfdx force:data:tree:import -p data/plan.json
  8. Abrir scratch org

Demo 1 – Hello World

helloWebComponent

Demo 2 – Registro Único

bearLocation
bearSupervisor

Demo 3 – Lista de registros

bearList

Imperative Apex

Wired Apex

Pasando parametros

Demo 4 – Comunicandose entre componentes

¿Cómo crear un Id Externo en Salesforce?

un Id externo es un identificador de un registro en salesforce que nos permite realizar cargues o actualizaciones desde sistemas externos.

Para crear un Id externo la solución mas sencilla es usar reglas de flujo de trabajo.

Primero creamos nuestro campo que utilizaremos como Id externo, debe ser de tipo número, texto o email

y debemos marcar la casilla Id. Externo

También podemos marcar la casilla Exclusiva

la cual nos serviría para evitar registros duplicados

Luego creamos la regla de flujo de trabajo

Se usa la opción creado, y cada vez que se modifica y se evalúa cuando se cree el registro o cuando se cambien las cuentas seleccionadas.

Luego se actualiza el campo

en este caso se llenará el campo con los Ids de salesforce de cada registro, concatenandolos con el operador & y utilizando la función CASESAFEID que nos permite usar el id de 18 caracteres que no distingue entre mayúsculas y minúsculas.

 CASESAFEID(Cuenta_1__c) &  CASESAFEID(Cuenta_2__c)

Asi cuando se cree o modifique el registro. El Id externo se llenara o actualizará cada vez.

y si se intenta insertar un registro con las mismas cuentas, aparecerá un error de Id duplicado