Summary
We recently solved a problem for one of our clients who wanted to have Salesforce objects available in SharePoint as well as able to tag them; that is, to have master metadata from Salesforce available in SharePoint.
Problem
The Client had two Objects (Clients, Projects/Investments) in Salesforce that they wanted to use as a Library and Document Set in SharePoint, respectively. They also wanted to have the metadata flow from Salesforce to SharePoint for tagging and search.
Resolution
As we well know, SharePoint is a remarkable document management tool. The Client wanted to use it as a Document Management System to store, manage, and auto-tag the documents when they were placed inside the Document Set and Library.
There were two Objects that needed to be replicated from Salesforce, which were Clients and Projects to SharePoint as Library and Document Set, respectively.
The Client had Projects defined with different metadata that they wanted to use to tag documents when uploaded in SharePoint.
As part of the solution, we created a Power Automate/Microsoft Flow where the trigger was from Salesforce, which is “When a record is modified,” which would capture any changes made in Salesforce.
The Salesforce connector is a premium connector, which means we would have an account that would work and has permission in Salesforce and SharePoint as well.
To implement this, one needs to sign in to create the connection,
Also, you can create connections and share with other users in case you don’t want to share the credentials. In our case, the connection was created and shared with us by the Client.
Once the connection is established, we need to select the Object type.
We created two Flows, one for the Issuer (each being a partner company or “Client,” as we refer to it below) and another for Projects.
For a new Client, we are creating a Library in a SharePoint site. So, for each new Client created in Salesforce, a library is created in SharePoint.
After the trigger, we are processing the metadata related to clients in variables.
This is how we created the library from Flow,
After adding the library, we are also adding the Content-Type (document set) and columns from the flow as well.
Along with creating a library, we are also storing the client’s unique ID from Salesforce and the library’s GUID in a Central Client list.
When an update is made on the Client, to manage the updates, we created a Central Client List in the same SharePoint site where we were storing the unique ID of the client from Salesforce and the Library’s GUID, so when an update is made, we can easily get the mapping by filtering the ID from Salesforce and make changes.
When an update is made on a client, we check the ID of the client from Salesforce against the IDs stored in List and, get the relevant Library’s GUID, and make the changes.
For a new Project, we are creating a Document Set in the relevant library (Client) in the SharePoint site. So, for each new project created in Salesforce, a document set is created in the relevant SharePoint library.
For a Document Set, we created a Content-Type and made sure the columns are shared so that when documents are uploaded in the document set, the properties are shared from their parent.
After creating the Document Set, we made sure to update the properties of the same with corresponding metadata flowing from Salesforce, such as Status, Initiation Date, Country of the client, and other metadata.
So as and when documents are uploaded in the Document Set, the properties get shared, and the users can search documents using the metadata we configured in a custom SharePoint search site.
After the Document Set is created, we are storing the Salesforce derived metadata in a Central Project List along with client’s unique Salesforce ID, project’s unique Salesforce ID, Library’s GUID from Central Client List and the document set’s item ID.
When an update is made in Project, to manage the updates we created a Central Project List in the SharePoint site where we were storing the unique ID of Project from Salesforce and the Document set’s item ID as well as the salesforce ID of client where project is created, so when an update is made, we can easily get the mapping by filtering the ID from Salesforce and make changes.
For updating the Document Set, we are also checking the metadata that flows with it, if the change is made in them, they are updated as well.
The overall goal was to sync Salesforce and SharePoint using a mechanism that would make it easy to check if there were any errors or issues.
Summary
As we know SharePoint is a remarkable document management tool, they wanted to make the best use of the metadata being flowed from Salesforce to SharePoint to tag documents which can be easily used for the reporting purposes.
In short, you can keep Salesforce as a source reference master data repository, knowing when you create objects and metadata, they can be replicated into SharePoint, with SharePoint as a document management system fully in sync in real-time from Salesforce.
Please post your question if you will find it while implementing this process. Thank you.
Want to talk?
Drop us a line. We are here to answer your questions 24*7.