Pàgines

jueves, 6 de diciembre de 2018

Merged & Child cases

A veces pasamos por encima de las diferentes opciones que nos da Out of the box el sistema sin tener muy clara su funcionalidad y no sabiendo como aplicarla en nuestro caso.

En el trato de casos encontramos unas funcionalidades que casi siempre se obvian. Unas de ellas son los casos fusionados (merged cases) y los casos hijos (child cases).


[IMG] Merged cases

En la primera funcionalidad se trata de escenarios donde se abren múltiples casos sobre el mismo problema y se quieren relacionar los casos entre ellos.

Con los merged cases se puede relacionar dos o más casos a un caso que quede activo para trabajar, dejándo el resto como cancelados.

La segunda funcionalidad se puede aplicar cuando existe un caso que debe ser realizado por diversas personas o cuando la incidencia afecta a diferentes clientes.
Para trabajarlo de forma independiente, se crearía un caso hijo que pudiera ser tratado por diferentes agentes o se agruparían, creando una jerarquía de casos que permitiría simplificar las gestiones a realizar. Por ejemplo, se puede definir que cuando se cierre el caso padre se cierren los casos hijos o viceversa.

Adjunto el enlace al post que me ha dado la idea, por si queréis ampliar la información.

https://crmindian.com/2017/04/17/case-merged-vs-child-cases/

martes, 18 de septiembre de 2018

Ejecutar una regla de negocio cuando se crea un registro


Con la aparición de las reglas de negocio se ha conseguido introducir funcionalidades que antes eran complicadas para usuarios no programadores. Ahora, con esta funcionalidad, cualquiera puede crear reglas que permitan ocultar o mostrar campos, indicar la necesidad de un campo o bloquearlo si es necesario según las condiciones que le marcamos.

Son muy útiles para trabajar con formularios y poder establecer como los queremos y en que momento lo queremos.

Un problema que surge es cuando queremos ejecutar una regla de negocio en una entidad, se ejecutará en todos los casos y solo buscamos que se ejecute en un formulario en el momento de su creación, dejando aquellos que ya están creados con las condiciones que tienen.

Este problema surge porque las reglas de negocio se ejecutan en la carga del formulario y en el evento onChange de los campos y se ejecutaría para todas las veces que entrásemos en el formulario.

Un truquito muy interesante para solventar el problema es poder comprobar si el campo Fecha de creación (Created On) está vacío, el cual nos indicará que es un nuevo registro.

Adjunto un artículo donde se puede comprobar el funcionamiento descrito que puede ayudar en este caso y en diferentes casuísticas utilizando las reglas de negocio.

Referencias:

Seguimiento de actividades mediante publicaciones automáticas

Muchas veces encontramos en las escalas de tiempo (o timeline) de los diferentes registros un montón de publicaciones automáticas que o no n...