The Daily Parker

Politics, Weather, Photography, and the Dog

Managing multiple CRM connections with one Azure application

We've published Part 3 of my series of blog posts about integrating Holden International's Azure-based sales training app with multiple customer-relationship management (CRM) applications. The combined parts 1 and 2 went up mid-August. Part 4 should come out within 10 days.

Here's the complete post:

In my last blog post, I outlined the code architecture enabling us to let Holden International’s Azure-based efox 5.0 application connect with multiple, arbitrary CRM applications. In this post, I’ll show you what it looks like to the end user using our SalesForce connector.

Users whose accounts are integrated with SalesForce can enter efox in one of two ways: either by going directly to efox, or by clicking a “launch” button from a SalesForce Opportunity record.

Going through the front door is simple enough. The user can go directly to efox, or the user can navigate to a saved URL that takes advantage of efox’s RESTful ASP.NET MVC interface. In either case the user may not have already logged into SalesForce.

Some customers haven’t set up SSO with SalesForce yet, because the SalesForce Professional edition doesn’t support it. We’re trying to get everyone using efox to upgrade, because the user experience without SSO is sub-optimal: it’s DSO (double sign-on), requiring users to keep track of two different sets of credentials (one for efox, one for SalesForce). I’ll cover that mess next time.

For now, let’s look just at the SSO user experience.

Because efox has to support non-SSO users, just going to without being signed in to SalesForce takes you to the efox login page:

efox SignIn page

That’s not helpful to SSO users, because (a) they don’t have an efox login and (b) efox doesn’t know which SSO provider they’re using. To solve this problem, we use a RESTful URL that looks like{CustomerCode}, where CustomerCode is unique tag identifying the customer.

Note how this URL lets the SSO controller not care what CRM system the customer is using. When the user navigates to their company’s efox SSO URL, efox looks up the customer and sends the user to the correct login page. So a SalesForce-integrated user gets passed to the SalesForce login page, with a SAML request under the hood telling SalesForce to send the user back to efox:

SalesForce login page

When the user logs in to SalesForce, the SAML magic happens, and they get back to their efox landing page:

Winning Sales Plan landing page

More commonly, though, users launch efox from their CRM systems. When we set up a customer to use efox, they add a “launch” button to their CRM’s Opportunity page:

SalesForce opportunity page with efox launch button

In SalesForce, the button is actually just a VisualForce link button; other systems just use a basic hyperlink. This is because it only needs to let users navigate to a link that follows the format{CRM Opportunity ID}/{User Name}. Navigating to that link takes the user to the SSOController class in efox, which starts the login process (if required) or sends the user to the next step (if she’s already logged in).

Again, through the miracle of MVC RESTful URLs, the link will work not only with SalesForce but with any other CRM provider. The SSO controller uses the user name to find out what customer to use, from which it finds out which SSO provider to use, to which it sends the user’s login request. The return path of the login request connects to the SalesPlanController class, which actually performs the import. (If the user is already logged in, the SSOController sends the user directly to the SalesPlanController.)

I won’t go over the specifics of how the controller pulls information from the CRM system, except to refer back to the discussion last time about the ICrmIntegration interface from last time.

I’ve used SalesForce for the artwork in this post, but the flow and user experience would be the same for any other CRM provider. Users get to move seamlessly between efox and their CRM system, and efox doesn’t care whether it’s connecting to SalesForce, Siebel, or a squirrel.

In my next post, I’ll talk about some of the problems we had to solve in order to let people use efox without SSO.

Comments are closed