Back to meat and potatoes – or their vegetarian equivalent in my case.
We are working with a client to deploy Alfresco One as a content and records management platform for their business. An important requirement is that we be able to integrate with Salesforce as that’s where their contracts are currently stored as attachments and where their workflow exists. During the scoping process we knew that Alfresco had created a Salesforce integration app that was available on AppExchange.
However, there are some limitations and “gotchas” that are good to know about when designing a solution around this integration.
- The integration is only supported for my.alfresco hybrid cloud integration. This is driven by Salesforce’s security requirements. If you have an on-prem or hosted Alfresco installation you will need to synchronize with the cloud extranet.
- The integration is really designed to be initiated from the Alfresco end rather than (as in our case) putting attachments from Salesforce into Alfresco. The developers at Alfresco have been very helpful in giving us guidance on how to work with this, but understanding this “normal flow” would have helped us earlier in the process. Learn from my mistake!
- All the content from Salesforce is put into a single “attachments” folder in a single site. However, if the SF record has an account record as parent record it becomes the root for that structure and then each object becomes a child of that folder. For example: Attachments ->ClientA->OpportunityZ Attachments ->ClientB->CaseY
- You can use Alfresco rules to move content around if it makes better sense in your existing organization because nodes are tracked no matter where the files are moved to.
- All the content in the SF site will have common security, so you will have to assign security to content. Again, the integration is built from the PoV that content is initiated in Alfresco, synced to the cloud, and from there to SF. If you are reversing that flow, things become WAY more complex.
- The current release of the Alfresco integration app only supports a default set of metadata for Accounts, Opportunities, Contracts, and Cases – these need to be mapped to Alfresco properties. However, we hear that there may be support for custom metadata in the next release.
Overall the integration is great if you are following the use case it was designed to address. The documentation is good, installation is easy, and the developers have been helpful and responsive to questions. But we may need to look at other ways to extract the existing content and populate our Alfresco repository. I’m currently looking at Data Loader as a tool to extract existing objects for import into the Alfresco instance.
(Thanks to Jon Chartrand, Jared Ottley, and Greg Melahn for their help in gaining this insight – all mistakes are mine)