Il servizio clienti è, molto probabilmente,la componente maggiormente coinvolta nel disegno dei flussi di lavoro.
Molto spesso, le aziende, dispongono di una grande quantità di procedure operative che devono essere mappate tramite i flussi di lavoro del CRM.
A mio avviso l'attuale sistema di workflow di Microsoft Dynamics CRM è tanto flessibile, quanto inutile. O meglio è una bellissima scatola, ma purtroppo vuota.
Fin quando restiamo nell'ambito della classiche attività (poco più che sufficienti per una demo) come ad esempio: inviare una email, creare un record, ecc.. possiamo anche cavarcela con le entità standard, ma sicuramente, prima o poi arriverà il momento d'iniziare a fare sul serio.
Ecco dunque la necessità d'iniziare a creare una struttura che possa effettivamente rappresentare un valido strumento di lavoro.
Alla base di tutto c'è il CASO (incident) ovvero, quella entità, da cui in genere vengono scatenati i vari flussi di lavoro.
Nell'implementazione OOB del CRM ad ogni CASO è possibile associare una o più ATTIVITA'.
La mia idea, invece, consiste nell'inserire una ulteriore entità che chiameremo AZIONE.
Ciascun caso può essere associato a più AZIONI, così come ciascuna AZIONE può essere collegata ad una o più ATTIVITA'.
Lo schema delle entità è quello riportato nella figura sottostante.
In questo modo otteniamo la possibilità di associare una serie di AZIONI al caso.
L'entità AZIONE è da intendersi come la rappresentazione di un'azione da intraprendere da parte di uno specifico utente.
A questo punto abbiamo già fatto un notevole passo in avanti, ovvero, abbiamo la possibilità d'iniziare a creare, sulla base delle caratteristiche del caso, una serie di AZIONI e di assegnarle a specifici utenti.
L'entità azione dispone di un livello di proprietà di tipo "User Owned" ed i suoi attributi principali sono (oltre a quelli di sistema) i seguenti:
| Nome | Nome visualizzato | tipo | lunghezza | Obbligatorio | Valori | Entità referenziata |
| new_name | Title | nvarchar | 100 | Si | | |
| new_description | Description | ntext | 2000 | No | | |
| owner | Owner | Lookup | | Si | | systemuser |
| new_isanapprovalrequest | Requires approval | bit | | Si | Yes/No | |
| new_approvalstatus | Approval status | picklist | | No | 1-Appoved 2-Rejected | |
| new_duedate | Due date | date | | No | | |
| new_caseid | Case | Lookup | | Si | | incident |
Di seguito una breve descrizione degli attributi:
Title: è il titolo dell'azione da intraprendere. Potrebbe essere molto utile far precedere il titolo da un numero di sequenza, in modo tale da fornire una traccia all'utente.
Description: si tratta della descrizione dettagliata dell'azione da intraprendere. Questo attributo, in genere, può essere utilizzato per inserire la guida per l'utente prelevando il testo dalla procedura operativa.
Owner: è il proprietario dell'azione, ovvero, chi effettivamente è incaricato del suo completamento.
Requires approval: indica se l'AZIONE rappresenta una richiesta d'approvazione. In questo caso il proprietario dell'azione è colui il quale deve effettivamente approvare. In genere se questo attributo è impostato su Yes, l'azione non dovrebbe poter essere completata senza aver indicato prima l'esito dell'approvazione.
Approval status: è una picklist legata all'attributo precedente. Se l'AZIONE rappresenta una richiesta di approvazione, questo attributo ne specifica l'esito.
Due date: è un attributo di servizio che può essere utilizzato per indicare la data entro cui l'azione deve essere intrapresa.
Case: è ovviamente il caso al quale è colleata l'azione.
A questo punto non resta che implementare il tutto.
Possiamo ad esempio creare un flusso di lavoro che alla creazione di un nuovo caso generi una serie di AZIONI per uno o più utenti. Tale flusso potrebbe restare in attesa del completamento delle azioni, per chiudere il caso o per crearne delle ulteriori.
Le azioni potrebbero rappresentare delle approvazioni, ed il flusso potrebbe restare in restare dell'esito per procedere.