Como borrar el valor de un atributo en un Workflow

Muchas veces me han preguntado si existe la posibilidad de borrar el valor de un atributo desde un Workflow.
Esto nos puede servir por ejemplo para hacer validaciones, o en caso de tener 3 campos y queremos que se rellene uno en primer lugar, en caso de rellenar otro, podríamos copiarlo en donde lo deseamos y borrarlo después.
La forma de borrar un campo en un Workflow es muy sencilla, pero aparece en el CRM un poco "escondido".
En una acción de "Actualizar registro" debemos seleccionar el atributo y seleccionar el operador "Borrar" como en lo siguiente:


Espero les sirva!

un saludo

Microsoft Dynamics CRM 2011 beta!

Hola a todos, finalmente el nombre del nuevo CRM será "Microsoft Dynamics CRM 2011".
Se ha anunciado en la Conferencia mundial de partners que la versión beta de la nueva versión estará disponible en septiembre!
Ya queda cada vez menos, y podremos ver como va quedando el nuevo CRM y las nuevas funcionalidades.
Recomiendo dar una vuelta por la siguiente página web y registrarse para estar actualizado de las novedades: https://offers.crmchoice.com/betaofferlanding/
Algunas imágenes que aparecen allí de lo que será en nuevo CRM 2011:

Como saber quién tiene instalado el Cliente de Outlook

A veces necesitamos saber exactamente que usuarios tienen instalado o utilizan el cliente de Outlook para CRM.
Existe una consulta en la base de datos, que puede devolvernos esta información y además decirnos en que ordenador está instalado.
La consulta es la siguiente:

SELECT Subscription.MachineName, SystemUserBase.FullName
FROM Subscription
INNER JOIN SystemUserBase
  ON Subscription.SystemUserId = SystemUserBase.SystemUserId 

Un saludo!

Escalabilidad con xRM

La semana pasada Microsoft publicó un artículo relacionado con la escalabilidad del CRM y pruebas y consejos de como mejorar el rendimiento de una implantación de CRM (o xRM).
El artículo puede descargarse de aquí:
http://blogs.msdn.com/b/crm/archive/2010/06/30/microsoft-dynamics-crm-4-0-xrm-application-scalability-study.aspx
En el blog del equipo de CRM, aparece una descripción del mismo:
http://blogs.msdn.com/b/crm/archive/2010/06/30/microsoft-dynamics-crm-4-0-xrm-application-scalability-study.aspx

Considero que es muy importante estar al día e informado de este tipo de documentos que publica Microsoft, porque también nos da algunas pistas de por donde "tirar" cuando tenemos algunas dudas en una implantación.

El estudio muestra el rendimiento de los servidores, con 3 escenarios diferentes:

1 aplicación para 20.000 usuarios

4 aplicaciones para 5.000 usuarios cada una

20 aplicaciones para 1.000 usuarios cada una

No soy experto en sistemas, pero está claro que el primer "cuello de botella" aparece en los servidores de aplicación, donde está el sitio web con sus web services. Multiplicando estos, se consigue una gran mejora de rendimiento.

Un saludo

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:


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.

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:


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!

Consultado los Workflows desde SQL Server

Los flujos de trabajo se ejecutan con el servicio asíncrono de CRM (AsyncService) y van dejando en el SQL Server registro del estado de los mismos, los pasos y el seguimiento de los mismos.
Como todos sabemos, no esta soportado el acceso a ciertas tablas del SQL Server directamente, pero el CRM nos ofrece unas "FilteredViews" para poder consultar los Workflows para hacer un seguimiento de la ejecución de los mismos.
Las vistas se llaman "FilteredAsyncOperation" y "FilteredWorkflowLog"
La consulta para recoger todas las ejecuciones de workflows es la siguiente:

select asyncoperationid, name,statecodename,statuscodename, createdon 
from FilteredAsyncOperation
WHERE messagename='ExecuteWorkflow'
order by createdon desc

y para recoger el estado de cada uno de los "Steps" (pasos) del workflow:

select stepname,activityname,description, completedon,statusname  
from FilteredWorkflowLog 
where asyncoperationid='8C6D813F-0C73-DF11-955A-000C299E8D82' --(aqui poner un "id" recogido de la consulta anterior)

De esta forma por ejemplo lo que podemos hacer es un monitor de ejecución de flujos de trabajo, de forma muy sencilla con una aplicación de escritorio o web que se vaya actualizando automáticamente.


un saludo