Mostrando entradas con la etiqueta Email. Mostrar todas las entradas
Mostrando entradas con la etiqueta Email. Mostrar todas las entradas

viernes, 27 de mayo de 2016

Enviar emails a los miembros de un equipo (Workflow Tools)

Muy buenas a todos!

Hoy he añadido una nueva funcionalidad a las tools de Workflows. Muchas veces desde un Workflow es necesario enviar emails a varios usuarios, y estos estos usuarios son dinámicos. El problema es que de forma estándar, debemos entrar al workflow a modificarlo (despublicarlo, modificarlo, y volver a activarlo). Esto es un poco tedioso y difícil de mantener para los usuarios.

Por esto, hoy he añadido otra “tool” para hacer mas fácil la vida de la gente. La idea es que podamos crear un equipo, y de ese equipo añadir en el email de forma dinámica todos los integrantes del mismo como destinatarios.

Como siempre, esta funcionalidad está disponible en Codeplex, con toda la documentación disponible: https://msdyncrmworkflowtools.codeplex.com/

Adicionalmente esta vez he creado dos versiones de la solución para CRM 2016 (8.0) y CRM 2016 Update 1 (8.1).

Explico de forma rápida como funciona:

Primero, seleccionamos la acción que se llama “Email To Team”:

wf1

Luego pasamos los parámetros (Email y equipo):

SNAGHTML16ea89ad

Finalmente al ejecutarlo, en el Email, aparecen todos los destinatarios recogidos del equipo:

wf3

Espero les guste, y sobre todo, que lo veáis útil!

abrazo!

@demian_rasko

miércoles, 30 de junio de 2010

Estados de los Emails

Al crear actividades de tipo Email, las mismas van cambiando de estados. en este artículo intentaré explicar un poco de como es este cambio de estados.
El flujo sería mas o menos el siguiente:
Flujo de estados de emails

Pongamos por ejemplo que planificamos un envío de un Email, simplemente lo creamos.
En este momento los valores serían:
StateCode=0 (Abierto)
StatusCode=1 (Borrador)

Ahora bien, supongamos que le damos el botón de "Enviar". Al hacer eso, el CRM simplemente marcará el correo electrónico para reaizar el envío. Los estados ahora serían:
StateCode=1 (Completado)
StatusCode=6 (Envío pendiente)

Luego lo que ocurre es que el servicio asíncrono de CRM (CRMAsyncService) ejecutará el evento "BackgroundSendEmail" que lo que hace es buscar todos los emails en "Envío pendiente" (statuscode=6) para marcarlos para que el Email Router haga efectivo el envío. Despues de ejecutar este evento los estados serían:
StateCode=1 (Completado)
StatusCode=7 (Enviando)

Lo que ocurre ahora es que el Email Router busca todos esos correos electrónico en estado "Enviando" para intentar entregar los mismos al servidor que tenga configurado. En caso de fallar, volverá al estado "Envío pendiente" para intentarlo enviar de nuevo. En caso de ir correctamente el estado quedaría así:
StateCode=1 (Completado)
StatusCode=3 (Enviado)

Espero les sirva, cuando le damos al "Enviar" desde el CRM ocurren muchas cosas por detrás...

abrazo.

miércoles, 23 de junio de 2010

Correos electrónicos enviados varias veces por el Email router

Existe algunos casos en los cuales el Email Router envia un correo electrónico mas de una vez, y en este post intentaré dar respuesta a la pregunta de por qué este servicio del CRM realiza esta operación de forma tan "inesperada".
Imaginense que creo un correo electrónico normal de CRM como el siguiente:
Correo electrónico

En donde "Prueba 1" y "Prueba 2" son contactos de la empresa y por lo tanto tienen correos electrónicos de dentro del dominio, pero uno de los dos contactos tiene el correo incorrectamente en el CRM (por un error al crear el mismo).

Al enviar este E-mail, el Email Router intentará entregar este correo electrónico al Exchange, pero este devolverá un error de "User unknown" ya que una de las direcciones del dominio no existe. Esto en realidad no significa que el correo electrónico no haya salido, sino simplemente que no se ha podido entregar a uno de los destinatarios, pero al resto de destinatarios sí que le llegará correctamente.

Este error devuelto por el Exchange provoca que el E-mail en CRM quede marcado como con error, por lo que intentará realizar el envio de nuevo.

Es por esto que a los destinatarios de este correo electrónico les podrá llegar este E-mail mas veces.

Para solucionar esto, se debe introducir correctamente la dirección de correo electrónico o revisar los parámetros del Email Router en relación con las repeticiones ante errores.

Para la configuración del Email Router, recomiendo la SDK en el artículo "Outbound Provider Configuration Settings":
http://msdn.microsoft.com/en-us/library/cc906239.aspx

Un saludo!

martes, 18 de agosto de 2009

Direcciones de envío de los Emails

Muchas veces enviamos emails desde el propio MSCRM (no mediante el Outlook), que como saben son enviados a la dirección que tenga predefinida el "Customer" o Usuario, como "emailaddress1".
Ahora bien, una vez que se pincha en "enviar" desde MSCRM, se marca como para enviar, pero es posible que quede en estado "pendiente", hasta que el proceso asíncrono de EmailRouter haga efectivamente el envío, o que se quede pendiente de sincronizar con un cliente de Outlook.
Entre un momento y otro, puede pasar un tiempo, y es posible que por ejemplo el email de la Cuenta haya sido modificado.
Entonces, ¿a que dirección se enviará el Email?, para esto habría dos opciones:
1) Que se envie a la dirección que tenía al momento de crear el email.
2) Que se envíe a la dirección que tiene al momento efectivo de realizar el envío.

Bueno, la respuesta es que antes del Rollup 4 de MSCRM 4.0, ocurría lo primero, y a partir del Rollup 4, ocurre lo segundo.

¿Como funciona entonces?
Al crear un Email, se crea un registro en la tabla "ActivityParty", con el campo "addressused" con el valor que tenga en ese momento.
Esto se puede comprobar fácilmente realizando la siguiente consulta:

SELECT addressused FROM FilteredActivityParty

Una vez que se actualiza el Email del registro en cuestión (por ejemplo una Cuenta), se actualiza tambien en cascada en la tabla "ActivityParty" en campo "addressused".

Los Rollups, muchas veces resulven temas, añaden funcionalidad y otras tantas cambian cosas, que pueden no estar documentadas, por esto mucho cuidado al instalar Rollups y probar todos los desarrollos previamente en un entorno que no sea de producción para así evitarse posibles dolores de cabeza.