One of the key features of our IronCloud technology is to the ability to take data in various forms and formats, structure it, setup refresh mechanisms, and then surface it as a normalized Web services XML API. This resultant API is then ready for integration and use into various applications, Websites, and devices.
The beauty of the hosted API model is that access to the API can be controlled and measured, and then easily made available for use by a broad range of internal and external applications over broad geographies with complete usage analytics and without the traditional software and hardware infrastructure investments and the time it would otherwise take to pull it off internally.
Once the API is available, sometimes the integration step into other applications can be simple and straight-forward, such as into an online shopping cart that utilizes sales tax rates and verifies shipping addresses. In other scenarios however, perhaps there is a requirement (or desire) to add additional business logic and capabilities around the integration of the API product.
An example of this is Salesforce.com and utilizing its Force.com cloud development platform. Here you might not only want to add integration to an internal or external data source, but you might want to have some business rules and user interface additions in support of that integration.
This is what we did with our Federal Do Not Call list data. Not only did we integrate it and make it available for use within Salesforce.com, but we also added visible green check marks to a contact record that had been verified as callable according to the data. We also recorded the last time the check was performed to ensure that compliance with the various Do Not Call rules was maintained. All of this adds to the usability of the integration, but none of it would be possible, or at least practical, without the underlying standards-based API that delivers the right data to the application when requested.
Other examples that we did this with using IronCloud-hosted APIs and Salesforce.com include US address verification, global address verification, and checking validity of email addresses.
This same concept could be applied to any data (or API-driven business process) where desire exists to incorporate that data into Salesforce.com for employee use. For example, if there are various data sources available within the organization that might be useful when viewed next to a contact record in Salesforce (such as previous transaction data, notes from other systems, internal trend data, etc.), that data could be hosted utilizing IronCloud. The API could then be generated, access rules created, and the same integration mechanism into Salesforce.com could be utilized. This is all pretty much turn-key with the technology we now have in place. Then of course there might be some user interface tweaks to provide the desired effect within Salesforce on top of the data. But pretty quickly, it can be done, and the selling and customer service process can be uniquely and considerably enhanced.
So of course, this ability to integrate data into Salesforce via a third party needs a name. How about SFIAAS, or Salesforce-integration-as-a-service? Because we all need another acronym.
Comments