By David Braverman
In the past few weeks I’ve written about how 10th Magnitude integrated the Holden International Microsoft Azure Cloud Service application with multiple CRM services. I discussed the problem space, how our architecture supports a provider model for CRM integration, and how we implemented single sign-on (SSO) against any arbitrary identity providers (IDPs).
This final installment in the series will explain how the user’s experience and the application’s experience are completely different. I will also explain how the limitations some customers face that prevent them from upgrading to SSO are proving frustrating.
Basically, the application communicates with the CRM provider independently of the end-user. This is true whether or not the user has SSO enabled or not. Once again, the easiest way to see how this works is with SalesForce. Here’s the general sequence:
The SalesForce SOAP API requires authentication. All API requests have to come from a SalesForce user. Right now, there is no way to pass the UI user through to the API, which is a limitation of SalesForce and not of Azure. (I won’t go into why we used the SOAP API instead of the REST API, except to say that the REST API actually makes this problem harder to solve.)
Generally, customers supply us with a single API user per account. (Some customers have different accounts because they break up their sales teams.) efox uses that account to talk to the API. The upside—especially for SSO users—is that everything works seamlessly. The downside is that all their changes to SalesForce opportunity records appear to come from one user, which makes auditing harder.
Sometimes, though, a customer will run out of licenses. For example, a 10-person company will probably use 10 SalesForce licenses, leaving none for the efox API. In this case, we have to collect each user’s SalesForce credentials and store them securely. We’ve got them on a hair-trigger self-destruct, and they’re encrypted using the best encryption available, but users still need to give them to us every so often.
The worst situation is when an organization uses SalesForce Professional. That means they don’t have SSO, and very likely they can’t spare the API license. Now their users have to log into SalesForce, then log into efox using completely different credentials, then supply their SalesForce credentials to efox so they can use the API.
Users connected with CRM systems that don’t have a dedicated API user see this:
It’s not ideal, obviously. We don’t want to store their credentials, and often they don’t want to provide them. Fortunately, most customers see the benefits of SSO or a single API user and upgrade.
If you’d like to learn more about how we built efox’s CRM integration, come to the Downtown Chicago Azure Meet-Up tomorrow night (10/9/2013) where I’ll be showing live code.