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

Alertas de seguridad del usuario invitado

Resultado de imagen para open door

Salesforce lleva algunos meses invitándonos a alinearnos a las actualizaciones de seguridad del usuario invitado para sitios públicos (sites, portales y comunidades).

Una vez se activen las nuevas reglas, los sitios publicos deberan seguir las siguientes politicas:

  • El módelo de seguridad para usuarios invitados será Privado
  • Los usuarios invitados solo podran tener máximo permiso de Leer y Crear en cualquier objeto
  • Las nuevas reglas de colaboración para usuarios invitados serán los únicos mecanismos para dar acceso a registros y el permiso será máximo de Lectura.
  • El usuario invitado no podrá ser el propietario de ningun registro
  • El usuario invitado no tendrá permisos de Actualizar ni Borrar en ningún objeto
  • El usuario invitado ya no podrá tener el permiso “Ver todos los Usuarios
  • El usuario invitado ya no podrá tener el permiso “Ver todos los datos” ni “Modificar todos los datos

¿Cuándo entrarán en vigencia los cambios?

Para Marzo de 2020 ya se deben haber tenido en cuenta todas las indicaciones y haber tomado acción. En este mes empezaran a vencerse las fechas máximas y posterior al release Spring’20, las nuevas características no se podrán deshabilitar.

Hasta tanto se podrá mantener desactivado el permiso Proteger acceso de registro de usuario invitado, disponible en Configuración de colaboración

¿Como prepararse?

  • Seguir los pasos que se indican en las Alertas de Seguridad

Más información en el siguiente link Guest User Access Report – Managed

¿Qué son las reglas de colaboración de usuario invitado?

Para cada usuario invitado (existe uno por cada site, portal o comunidad) se deberan crear reglas de colaboración que permitean dar el permiso de lectura por cada objeto que se requiera.

Esta es una nueva funcionalidad disponible con está actualización

¿Como permitir al usuario invitado Actalizar y Borrar?

En este caso la solución parece sencilla. Para que desde un site publico, se puedan seguir Actualizando y Eliminando registros, lo que se debe hacer es ejecutar el codigo de Apex en modo del sistema es decir con la palabra reservada “without sharing”.

Con with sharing la clase no podra realizar actualizaciones ni eliminaciones

Al ser invocada por un usuario invitado, la recomendación es usar without sharing

¿Cómo reasignar propietario a los registros cuando los crea el Usuario Invitado?

Si hablamos de comunidad, desde Winter’20 existe la opción de reasignar los registros del usuario invitado al usuario por defecto de la Comunidad

después de activar está nueva opción, en la administración de la comunidad en Preferencias veremos la opción de relacionar el usuario por defecto que será el propietario de los registros de la comunidad

Para sites, está opción no existe y por lo tanto se debe actualizar la lógica de creación para asignar un propietario teniendo en cuenta que este usuario no se vaya a desactivar nunca, o empezaría a fallar la creación de registros.

¿Cómo validar?

Las alertas de seguridad se pueden activar/desactivar en un ambiente de sandbox a voluntad hasta antes de la fecha limite en Marzo.

En el siguinte link se puede ver un plan de pruebas (en inglés)

Plan de pruebas – Seguridad del Usuario Invitado

¿Donde encontrar más ayuda?

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

Como modificar un batch que se encuentra programado sin detener la programación

Aquellos que han hecho un batch en Apex y lo han programado saben que al momento de querer modificarlo en producción, por ejemplo a través de un conjunto de cambios, siempre nos encontramos con el mensaje

This Apex class has batch or future jobs pending or in progress

o en español

Esta clase programable tiene trabajos pendientes o en curso

La solucion rápida es desprogramar el trabajo. Implementar el conjunto de cambios y volver a reprogramar. Tan solo que algunas veces no sabemos que clase especificamente es la que está programada o se nos olvida revisar la configuración exacta que tenia la programación antes de eliminarla. Problemas que se solucionan con un poco de paciencia y cuidado.

Image result for patience free image"

Aunque desde el release Winter ’15 existe la opción de poder implementar clases que tengan trabajos pendientes o en curso

Ir a Configuración -> Ajustes de implementación

Si queremos tener mas control sobre que clases pueden implementarse cuando hay programaciones en curso, podemos utilizar otro enfoque, uno que en sus días fue explicado por Dan Appleman y hace uso entre otros del concepto de Reflexión en Apex.

Ver: Intriguing Design Pattern for Scheduled APEX

Reflexión en Apex

La capacidad de un programa de modificar su estructura de manera dinámica es conocido en otros lenguajes como Reflexión. En Apex contamos con la clase Type pero en otros lenguajes hay mas herramientas.

La solución explicada por Dan consiste en crear una clase programable (que no se va a modificar posteriormente)

Esta clase que implementa Schedulable declara su propia interfaz que es igual en su definición a la de una clase programable.

El secreto está en el uso de la clase Type que con su método forName, nos permite crear una instancia de nuestra clase Batch (o cualquier otra que deseemos programar) en tiempo de ejecución, por lo que la clase programable no sabrá que clase es, hasta que se ejecute.

Así podremos modificar nuestra clase posterior a que se encuentre programada

La clase que vamos a programar sería asi

Simplemente implementa la interfaz que definimos dentro de nuestra clase programable.

Para mas información de la clase Type ver Apex Developer Guide: Type Class

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.