Category Archives: SharePoint

Set metadata for files uploaded in SharePoint from CRM – CRM and sharepoint integration -New version release announcement!

Follow my blog for more interesting topics on Dynamics 365, Portals and Power Platform. For training and consulting, write to us at

We are delighted to announce the release of the next version of our tool – Sharepoint Attachment Extractor and Metadata Manager. For readers who are new to this tool, this tool enables you to upload documents to Sharepoint with multiple metadata as well as host of other features like

    • Allows you to create and edit Metadata related to files from CRM. This version allows up to five metadata fields per entity and also provides the option to restrict the metadata values to a specific set of values or free text.
    • Dynamic adding and removal of the SharePoint section on the form of an entity just through configuration page that comes with the tool. Also you can place the SharePoint section on multiple forms for the entity.
    • Upload up to five files at one go along with the option to enter metadata for each file. Also size limit of file not constrained by the attachment size limit in CRM
    • Automatically moving the document from the annotations section of CRM to Sharepoint.
    • Behaves in conformance with the security privileges of the user in CRM for the record on which the SharePoint section is being shown.

You can download the detailed documentation from this link –

For trial and pricing, please write to us at

So what’s new in Version 2.0?

1. Performance

Our team have worked greatly on the performance issues especially during metadata update and also during upload of five files with metadata. The current version is ~1.5x faster than its previous version in terms of interaction with SharePoint

2. UI in conformance with Dynamics V9.0

The entire look and feel of the Sharepoint Grid control has been revamped in conformance with the new version of CRM. The grid contains a host of features including

  • Column resizing
  • Improved Searching logic
  • Sorting
  • Paging
  • Document reload
  • Drag  & Drop

Screenshots for reference.




3. Ability to specify column ordering for metadata

The tool now comes with the capability to enable column ordering for metadata.



All of this and much more to offer. Reach out to us to know how we can help you.

For trial and pricing, please write to us at

-Debajit Dutta

(Dynamics MVP)

CRM on-premise and Sharepoint online integration–Common obstacles faced and their work-around.

Follow my blog for more interesting topics on Dynamics 365, Portals and Power Platform. For training and consulting, write to us at

Before I start writing the details, first let me tell you why this blog. After all this is so nicely explained in the following link –

Well, the above link contains all the steps you need to set-up server-server integration between Dynamics On-Prem and Sharepoint online. But still from my personal experience I find that customers find it great difficult to set this up. This is mainly because they get some error while executing a step or because some pre-requisites are not there and they are not mentioned in the technet link as well.

The main intention of this post is to rectify all those errors, identify all the dependencies and work your way to glory.

So let’s identify the dependencies first.

Dependency 1 : Dynamics should be ADFS configured and accessible over the internet.

I am not going over the topic again on how to do it. Greatly explained here – and in so many other blogs.

Dependency 2: Microsoft Dynamics 365 Hybrid Connector should be configured.

Believe me, from my personal experience I find many clueless about this. Well you no longer need to. You just need to verify here if Dynamics 365 Hybrid connector subscription is available and commissioned.

To do this:

  • Login to using the Office 365 admin credentials for your SP online tenant.
  • Open the Office 365 admin screen
  • Go to Billing –> Purchase Services


  • Expand the section Dynamics 365 Suite. Usually its expanded. If not expand it.



    • Below is the screen you get. As of now its free but the way it shows up I believe it will be chargeable some time soon Smile


    • Enter you credit card number and then click on Place Order. Don’t worry, you won’t be charged for this. You are all set and done.

Dependency 3: Connect to Microsoft Online through PowerShell.

Now this can become tricky. The technet documentation says – You need to have Azure Active Directory powershell modules. And the link redirects you to a page where it asks you to install the module using Powershell command prompt – Install-Module MsOnline

The moment you do this step, you get an error like the one below.

install-module : The term ‘install-module’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path
is correct and try again.
At line:1 char:1
+ install-module MSOnline +
+ CategoryInfo          : ObjectNotFound: (install-modele:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

Well to successfully accomplish this, you need to complete both the required steps.

  1. Microsoft Online Services Sign-In Assistant for IT Professionals Beta – select the appropriate download. It may ask you to restart the machine for the changes to take effect. Please do the same.
  2. Now also if you run the install-module command, it would fail. The reason is install-module command is available from Powershell v5.0 and above. So you need to update your powershell as well. To do this, download the necessary installer depending on your server/ 64 or 32 bit machine, from the below Url.

Again machine restart is required.

Now open powershell as administrator and then try to install the module MSOnline. It will now download the same from Nuget.

Requirement 4: X.509 Digital certificate

Well this is the simplest but again it can give you some errors which would be difficult to find out. The first question is – which certificate do I need to use.

Well, the easiest answer is, you can use – “An x509 digital certificate issued by a trusted certificate authority that will be used to authenticate between Dynamics 365 (on-premises) and SharePoint Online. If you are evaluating server-based authentication, you can use a self-signed certificate.”

So we can basically re-use your CRM certificate or ADFS certificate. All you should take care is while exporting the certificate, it should be exported along the private key.


* Export all extended properties should be checked.


You will be asked to provide a password. Keep this password as you will need this later.


Once the file is exported, import it in the personal store of the machine where deployment manager is installed.

The technet article asks you to execute the below command.

$CertificateScriptWithCommand = “.\CertificateReconfiguration.ps1 -certificateFile c:\Personalcertfile.pfx -password personal_certfile_password -updateCrm -certificateType S2STokenIssuer -serviceAccount contoso\CRMAsyncService -storeFindType FindBySubjectDistinguishedName”

The service account is important here in the above statement. Whatever service name you provide here, that should have access to the private key of the certificate. To do that, you need to provide permission to the private key from the certificate console.
Click on Manage Private Keys and give the service account user full permission on the certificate.
After completing all the above steps, while connecting to your CRM, you may receive the 401 - Un-authorized error in Powershell. For this follow the below steps.

Open registry editor


    1. Right-click Lsa, point to New, and then click DWORD Value.
    2. Type DisableLoopbackCheck, and then press ENTER.
    3. Right-click DisableLoopbackCheck, and then click Modify.
    4. In the Value data box, type 1, and then click OK.

Re-open powershell. It should work.

The commands I am not repeating from the technet article since they work just fine.
Hope this helps!

Debajit Dutta

(Dynamics MVP)

For training/ consulting/ utilities – please visit our website – or write to us at


“Based on Entity” in Dynamics 365 Sharepoint integration

Follow my blog for more interesting topics on Dynamics 365, Portals and Power Platform. For training and consulting, write to us at

Recently I was handling a training in Dynamics where I was demoing the OOB CRM SharePoint integration.

Client was already using the OOB CRM-SharePoint configuration using entity based folder structure. Anyone getting confused what is meant by entity based folder structure? Well while configuring you get an option to select whether based on Account/ Contact.


I selected Account here. Not a big deal.


But here it gets interesting. What if I upload some documents for a child record of an account and then change the account for that child record?

To duplicate this, I followed the below steps

  • Created two accounts – Account A & Account B
  • Created a case – Case | Document Test for Account A
  • In the Documents Section, uploaded file named – Document 1.txt

Let’ see the folder structure in SharePoint after this operation.


No surprises here. As we have chosen Entity based folder structure, the document got uploaded for the case under the account for which the case has been logged.

Now let’s go ahead and changed the account of the case to Account B


Now if we go ahead an upload a Document for the case – Document 2.txt, it should roll up under Account B. Let’s see that if it happens.

I go ahead and upload the document. But surprisingly it is still uploading under Account A in SharePoint.


Strange isn’t it? But why it happens? To understand this we need to understand the Document Locations record that CRM uses to map to the corresponding folder in SharePoint.

The following are the document locations record that got created after we uploaded Document 1.txt.


As you can see, four document location records got created

  • One for entity – account
  • One for account record – Account A
  • One for entity – (case)incident
  • One for case record – Case| Document Test

As you can see all are named “Document on Default Site 1”. This is confusing. So let’s name it accordingly.

Below is the screenshot after renaming. Probably looks simpler now with the names.


Looks go ahead and create the document location record manually for Account B.


If you now come back to the Case record and move to the Documents section, you will find two document locations now but if you select the Account B Document Location record, you will find no upload button.


This is because the corresponding folder in SharePoint does not exist. Lets go and create that.


Now if you go ahead to the case and move to the Documents section, you would find both the Document Locations for previous and current account.

And if you now upload a document to the case for the current account, it goes and sits at the right place. And you can always switch back to see what were the documents uploaded for the previous account as well.


Hope this helps!

Debajit Dutta

(Dynamics MVP)

For training/ consulting/ tools, please visit

Unable to see documents in navigation pane – Dynamics 365 sharepoint integration

Follow my blog for more interesting topics on Dynamics 365, Portals and Power Platform. For training and consulting, write to us at

Recently I was in a training for a client where I was demoing the CRM – SharePoint  OOB integration. So I enabled the integration and then also enabled the Account Entity for Document Management.

However when I opened a Contact and tried to Navigate to the Documents section, I find no link in the Navigation Pane. Looked like the one below.


Bit embarrassing since just before that I told the participants that the document link would appear once I enabled the entity for Document Management.

Bit flummoxed, I checked for the relationship whether mistakenly I have made the relationship display to False. It was not the case.

Then jumped on to the form editor and clicked on the Navigation Pane and then much to my relief, I could see the Documents tab in the available relationships.


Just dragged the relationship on to the Common relationship area. Save and publish the customizations. And much to my relief I could see the Documents link in the Navigation Pane


Small thing. But saves you some moments if you know this.


Debajit Dutta

(Dynamics MVP)

For consulting/ tools/ training please write to us at or visit our website

Delete attachments from SharePoint folder when a record is deleted in Dynamics 365 using Power Automate/ Microsoft Flow

Follow my blog for more interesting topics on Dynamics 365, Portals and Power Platform. For training and consulting, write to us at

Off late, I have been working with Microsoft flow and boy! I am liking it. It is cool and specially considering the fact that it simplifies whole lot of stuffs that you would normally require to write lot of code, make it even more appealing.

So here I was with a requirement.

There was OOB CRM-SharePoint integration enabled and the client wanted that whenever an entity record is deleted from CRM, the  documents in the corresponding SharePoint folder should be deleted as well.

Now the OOB behavior does not support that. Even if you delete the record, the folder corresponding to that is present in the SharePoint path with all the documents.

So what are my options here. Well some custom code that would run when the record is deleted in CRM and that code would be responsible for deleting the documents from the SP Folder. On top of that, if you are in online, you cannot use the client object model of SharePoint from your CRM plugins. You would require to make use of REST API of SharePoint which is way more complex that the client object model.

But wait, don’t worry. We have Microsoft flows. So let’s explore how can we achieve this using a few tricks and the very wonderful Microsoft flows. And let’s explore how this generic framework will work for all.

For my example, I will select the Contact entity.

Here is my contact record for which currently 3 documents are uploaded.


Below is the Sharepoint folder location for the same.


As you already know, when you enable OOB CRM-SP integration, the folder for each record for the first time gets created in the format of <Primary Attribute Name>_<Record Guid with ‘-‘>

In my case the folder name is – Darren Parker_69a0e5b988dfe311b8e56c3be5a8b200

I create a custom entity in CRM called – ‘SP Folder Delete Trigger’. And create a custom field called ‘Document Location’.

Whenever I would delete a contact record, I would create a new record of ‘SP Folder Delete Trigger’ and the Document Location field would contain the corresponding path of the Sharepoint folder. So if I delete the contact “Darren Parker”, I would create a record ‘SP folder Delete Trigger’ with Document Location as /contact/Darren Parker_69a0e5b988dfe311b8e56c3be5a8b200

How to create this record? Well I leave this up to you. Plugins, workflows, action? In what so ever you want.

Ok. But don’t create the record now. Let us first design a Microsoft flow which would do wonders. But how do I use it? Well, just like any other Microsoft feature, it is as easy as it gets. I will start from the beginning of how to enable flows for your organization. Readers who are already aware of the same can just skip the first few set-up steps.


  • If you are using first time, it will set this up for you. In either case you would land up in a screen like the one below.


  • Click on ‘Create from Blank’ button
  • In the search area, type ‘Dynamics 365’. It would show all the operations available for Dynamics 365.


  • Select the step – “Dynamics 365 – When a record is created”.
  • Enter your organization name and entity name. It will be present in the list of available options.


  • Click of ‘New Step’ –> Add an action


  • Select sharepoint and then select the Sharepoint – List folder action


  • Select your Site Url. It would be auto populated.


  • Now comes the important part, the folder identifier. Basically, it is the path to your folder. Since we are making a generic framework here, we won’t hardcode the folder path. Rather we would be passing the dynamic property. So what is the dynamic property

You remember we create a field called Document location which contains the path to the folder. So we set this field to the Document Location property of the created record.



  • Since we are using a dynamic property here, our flow works for any entity and any record. It’s not specific to entity type or record guid.
  • Now we have our folder. But we need to iterate through all the files in the folder and delete them right? So we need a for-each statement here. Let’s see how we can accomplish this.
  • Select Add step –> More –> Add an apply to each.


  • The for-each construct is being applied. In the output select ‘body’ from the previous List folder step


Remember, this body is nothing but the each of the files contained in the folder.

So the next step is to delete the files.

  • Select Add Step-> Add an action-> Sharepoint –> Delete File


  • As usual select the sharepoint url from the available options. For the file identifier, select the Id from the output of the previous step.


All set and done. Save the flow. Your flow is up and running.

Remember, we have not created the ‘SP folder delete trigger’ record. Since our flow is active now, we will do the same now. Here is the screenshot below of the same.


wondering the document location we mentioned for our example was different – /contact/Darren Parker_69a0e5b988dfe311b8e56c3be5a8b200. But the screenshot above shows a different. Well, it’s the same value. The value is just URI encoded. But why is it necessary?

This is because, the flow will internally use the REST API to query SharePoint and when our dynamic property ‘Document Location’ would be evaluated in the workflow, ‘/’ will not be a valid character and hence the flow would fail. Remember, this is very important to remember that you need to put the URL encoded values here to get the flow running. A simple mistake like this would take days to resolve and you would wonder what wrong you are doing.

So I created the record. My flow would fire now.

Go to My Flows and click on the information icon next to your flow.


Check for ‘Successes and Failures’


In my case, the flow has run and has executed successfully.

And if I go to my contact folder now, it is empty.


Awesome isn’t it? No code and you have set up something which talks between CRM and sharepoint.

And this flow works for all entity and all records. Just you need to set the Document Location property accordingly which can be done easily in CRM.

Hope you liked this. I will come up with some more interesting examples for flows. Till then, happy CRM’ing

Debajit Dutta

(Microsoft Business Solutions MVP)