Gareth Tucker: SMS and Fax Integration for Microsoft CRM 2011

[Blog bot]

Источник: http://gtcrm.wordpress.com/2012/06/2...soft-crm-2011/
==============

Recently my colleagues and I have been experimenting with different integration approaches for enabling the SMS and Fax channels for communications from Microsoft CRM.   Here’s a run down on  some of the approaches we explored.

 

SMS Integration

 

A very common request in RFP’s these days is the ability to send SMS alerts to customers/users from CRM.  When facing this requirement you need to first determine whether the customer has an SMS gateway service/provider that they wish you to use or not.  Each service/provider can be different so your approach and estimate may vary. 

The 2 common SMS integration approaches you’ll come across are:

  1. Email-to-SMS Services

  2. Web Services



Email-to-SMS Services

With Email-to-SMS services you send your SMS to a unique email address and it gets converted and sent on your behalf.  I’ve seen two flavours of this.  One where the email address is fixed and you provide the recipient’s mobile number in the body of the email with a delimiter, splitting apart multiple recipients and the message.  The other flavour is where you include the recipient’s mobile number in the email address – e.g. 97845899@smsprovider.com.

When it come to CRM, the advantage of the Email-to-SMS service approach  is you can potentially utilise this without having to wheel in a developer.   This is certainly the case when your SMS recipient is fixed.  e.g. suppose you want to SMS the IT helpdesk when a high priority Case is logged in CRM.  You could create a dummy Contact or User in CRM with an email address like 97845899@smsprovider.com and then just create a CRM workflow that emails that Contact/User when the triggering conditions occur.   Also, those Email-to-SMS services that take the recipient’s mobile number as a value in the body of the email message can easily be utilised with OOTB workflows.

If your service requires the recipient’s mobile number to be embedded in the email address then you can’t always get away with a no-code solution.  Your Customer records will typically have a real email address and you will have this set as their primary so that CRM email integration works.  Yes you could store their mobile number in one of their secondary email address fields but CRM workflows will always use the primary email address.   Unfortunately, when defining an email in workflow you have to chose a CRM record to email to.  And in CRM workflow you can’t you just construct an email address out of say the Contact’s mobile number and a hardcoded suffix:



Web Services

To utilise an SMS provider’s web services you definitely need to summon a developer out of the basement.  Good news though is the development is often quite minimal and rather than coding for one specific requirement we can easily code up a generic SMS capability that you can use in a number of ways.   Here’s 2 approaches we have played with:

Custom Workflow Assembly: Send SMS

Here, the idea is to create a custom workflow action that is similar in nature to the OOTB “Send Email” workflow action – so that your workflow designers can  easily add SMS sends to any workflow or dialog they author:



You define the workflow assembly to accept at least 2 input parameters:  “CRM Contact” and “Message” (you also might want to cater for “CRM User” as an alternative recipient type):



Your clever little CRM developer’s assembly will read these parameters, retrieve the mobile number from the Contact specified and call the SMS Web Service to send that Message to that Mobile Number.

You could also define a custom “SMS”  entity in CRM and have your developer extend their workflow assembly to record an SMS entity record for each SMS sent, to provide an audit trail of that communication (just like you get for emails). 



If this appeals, best bet is to define this custom entity as a custom activity and make sure your CRM developer codes it up so this record is flagged as completed/sent – so that it appear under Closed Activities:



 

SMS Activity Type + Plugin

With this approach we flip things around.  We ditch the custom workflow assembly and place our logic in a plugin instead.  Here we definitely need a custom SMS entity added to CRM and defining it is as a Activity Type again makes sense.  The idea behind this approach is to put the SMS delivery logic into a plugin that will fire as an SMS activity record is saved.

The cool thing about this approach – in addition to opening up SMS as a new channel for CRM workflows – is we give our users the ability to manually send SMS’s in CRM, in a way similar to how they would send an email from CRM.     They can go to a Contact, Case or Opportunity (any entity that is enabled for Activities) and do a New –> SMS, then enter their message and then hit Save.  SMS sent.   Nice!

The plugin fires on save (pre or post create/update – you pick).  The plugin context provides the Contact and Message from the SMS activity record.  The plugin retrieves the Contact’s mobile number and then calls the SMS Web Service to send the message.  Optionally, it could write a success/failure response onto the SMS activity record.  Lastly, it should mark the activity as complete.

Another advantage of this approach over the custom workflow assembly approach is you can easily add “Resend” functionality.  I’d do this by adding a “Resend” ribbon button to the SMS Activity form which would force a status change to the SMS activity record – which in turn would trigger the plugin to send the SMS.

 

Fax Integration

 

We looked at Microsoft CRM Fax integration for a customer this week whilst shaping a solution for their outbound call centre.  Their main use case had the sending of Faxes occurring from CRM Dialogs (when certain prompts and responses lead to the need to send the Case details to an external party).  The volume of Cases was low and the need for Fax integration was fairly minimal.  Some of their business processes required communication of Case details to an external party via Fax.  The external parties were known and fixed and there were only a handful of them.

The customer hadn’t been able to share much about their existing infrastructure and wanted to scope this project as a pilot.  We decided to go with an online Fax provider, rather than introduce any dependencies on unknown internal systems.    eFax.com was the logical choice, we signed up for a 30 day trial and started experimenting in our lab. 



eFax offers an online email-to-fax service, similar in nature to the email-to-SMS service I discussed earlier.  Differences exist of course, with fax you are sending documents rather than short text messages.  eFax gives you an email address to use and ask you to prefix the recipient’s fax number to that email address.  The document to be faxed should be attached to the email, and the body of the email becomes the fax cover sheet.  Simple enough concept – score 1 for eFax!

As always, there were several ways we could design the interface.  I wanted to architect a solution that was consistent with the SMS plugin interface and shared the positive characteristics of that approach.  The solution needed to support the sending of Faxes from workflows/dialogs or manually through the CRM UI.  It needed to support resends and there should be a CRM activity record recorded for each Fax sent.  The Fax document itself needed to be configurable and I wanted to be able to send different documents in different scenarios.  The recipients could be established in advance as special CRM Contact records – the solution just needed to be configurable to allow selecting of the relevant Contact in each scenario.

Here’s what we came up with…

We created the Dialog and at the relevant points added ‘Create Fax’ actions:



We specify the Sender and Recipient on the Fax record, provide a Subject and specify the name of the SSRS report we want faxed:



After creating the Fax record the next action the Dialog performs is the updating of the Fax Status to “Pending Send” (this is a trigger we will make use of in a bit):



The Contact we are faxing is a system Contact record we have added into CRM, it is on this record that our destination fax number is stored – in the email address format required by eFax:



The Fax Report Name that we specified on the Fax record refers to an SSRS report we uploaded directly into SSRS:



The SSRS report requires a Case ID parameter, from which it retrieves records from the Case and Contact entities displaying these as a formatted Case report:



So the Fax record is created with all of the necessary input parameters we need populated into its fields:

 

I mentioned before the Dialog sets the Status of the Fax record to “Pending Send” – that is the trigger we hang our Plugin off of. 

So, the Plugin, this is where the good stuff resides.  Here’s what the Plugin does:

1. Generates the named SSRS report via the SSRS web service, passing in the Case ID from the Fax’s Regarding field as a parameter and requesting the formatting of the report output to be PDF.
2. Creates an Attachment record against the Fax record, attaching the PDF output from step 1.
3. Generates a CRM Email Activity record based on the Fax record (same From, To, Subject, Message Body, Regarding and Attachment).  We also have a custom Fax lookup field on our Email form and we populate that to link the 2 records.
4. Submits the CRM Email Activity for Sending

That Email Activity record will now be eligible for delivery and either the CRM Outlook Client or Email Router will pick it up and send it out.  The email will go to the Contact we specified back in the Dialog who has their fax number embedded in their email address:  6563380933@efaxsend.com.



eFax will receive that email, generate an actual Fax to that number (6563380933) sending the SSRS PDF report it finds attached to the email.

There’s one last bit to this solution.  The one thing that looks a little wrong at this point is we have this Fax communication essentially stored in CRM twice:  once as a Fax record (good) and then again as an Email record (bad!):



We address this with a small Plugin that fires on status change of the Email record. When the Email status changes to “Sent” our Plugin marks the Fax as “Sent” and then deletes the Email record leaving our Case record with a nice clean History record:



We could have avoided the need for this extra Plugin by having the first Plugin send an email directly to an SMTP service instead of creating a CRM email activity record.  We would have to write that SMTP integration code though and store those connection details somewhere.  I like the CRM Email Activity record solution more, there is an elegance in not needing to know the details of any other system – all the coding, is just ‘normal’ CRM coding.

For resends, we can follow the same approach we put in place for SMS and add a custom ribbon button to the Fax form which updates the Fax Status back to “Pending Send” to trigger the plugin to run again.

The solution supports adhoc sending of Faxes by CRM users as well.  They just need to create a CRM Fax Activity record, chose one of the system Contacts to send to and enter the name of the SSRS report to be faxed.  They can initiate the Send via the custom Ribbon button or by manually changing the Status field on the form (you might want to have a “Send” button in addition to the “Resend” button to smarten this up a little).   

There’s plenty more you can do to harden this solution further but hopefully this gives you an idea of what is possible.  Should you need to integrate to a Fax web service in a different way from what I have shown here most of this solution can still apply you just change what the Plugin does – e.g. have it call a web service rather than create a CRM Email Activity record.

We got the above solution working in next to no time.  And the main reason for that was this wee code snippet that took care of the SSRS report generation and attachment steps for us:  http://ekoncis.blogspot.sg/2012/01/c...df-report.html

HTH




Источник: http://gtcrm.wordpress.com/2012/06/2...soft-crm-2011/