AADI Enterprise Integration
Last week while exhibiting at the Gartner Application Architecture, Development and Integration conference, I was reminded of a presentation I sat in on earlier this year on the topic of integration of file transfer and management capabilities into Salesforce. I estimate there were several hundred IT professionals including CIOs, IT Managers and Enterprise Architects in attendance as the company presented their solution. The presentation included lots of interesting facts about how many files and users were in the system, the types of files, and the vast amounts of highly sensitive data that was in the system. During the Q&A period, some astute audience member asked, and I am paraphrasing:
“How are access rights maintained between the Salesforce and the file management system? Of course, if a Salesforce user cannot access a particular lead or contact, they should not be able to access the files related to that particular lead or contact. How were you able to solve that problem?”
At this point the presenters became very uncomfortable. In a very shaky manner, they explained that these access rights were not yet implemented, but that they planned to so in the future.
There were no access controls on the files. All of these sensitive files were wide open for any Salesforce user to access. The crowd was suddenly disillusioned. What seemed like a solid solution that would solve a huge problem actually presented a bigger problem than it solved.
Enterprise Integration? Maybe not?
All the company did to integrate was insert an iframe of their application into Salesforce. There was no true integration between the two systems. The only benefit provided by this iframe was the ability to send a file or folder without having to open another application, but they were essentially two completely separate applications.
While failure to maintain secure access continuity is a big enough headache, there are at least two other negative consequences resulting from the short-cut iframe approach.
First, the reason any company uses a CRM is to track all communications between a company and its current and potential customers, which gives insight into that relationship. Decoupling file transaction data or to put it in another application blurs the relationship making consolidated reporting and access painful.
Using iframes leaves you in the dark as to whether your company ever sent the files and whether the customer ever received them. Maybe the other application is able to track them, but you will never know as long as you stay in your CRM. There are no times or dates, no logged activities, no proof of delivery, nothing.
Secondly, workflow rules and tasks cannot be created on items that are not integrated into the system. Businesses and especially enterprise businesses depend on process delivered by workflow governed by rules. Foregoing, for speed of integration, the ability to automatically create, assign, update fields and task and to send emails, and all of the other workflow features CRMs provide is to lose the benefits of using a CRM.
How does Thru integrate?
Built on a service-oriented architecture, Thru provides an extensive Web Services API. Over 130 API calls and the Thru MFT Toolbox, either SOAP or REST, enable true workflow enabled enterprise integration. The Thru Toolbox contains widgets offering all the major MFT functionality out-of-the-box, significantly reducing integration time and work.
The Thru API allows for deep application integration connecting at the component level. Actions taken on a file or folder can be logged as activities and workflow rules can be developed around them. Users with access to a contact has clear visibility into who has sent and received which files, and when inside the CRM. These tools provide both power and flexibility to do the enterprise-class integration that your business needs.