Creating custom folder structure for Sharepoint integration using Flows

By | March 18, 2019

We’ve come across an interesting problem recently. Imagine that you have a few different business units, and you want Sharepoint integration to work in such a way that all the documents within each business units would be shared, but there would be no sharing between the business units.

This is not how it normally works in Dynamics, though, so the options are:

 

The permissions replicator is great, and it would do the job, but, just to explore that custom implementation option a little more, what can we actually do?

If it were on-premise, or if it were a few years ago, we’d have to think about a plugin for this.

But, since we have Flows, I figured it would be interesting to give it a try. And it worked.. Not without a few quirks, but I did not have to write a single line of code. Which is unusual to say the least.

Here is how it happened, step-by-step.

1. Creating a solution

First, we need to create a solution..  I’ll be creating a flow in the next step, so I figured flow.microsoft.com would be just the right place to create this solution:

image

2. Creating a flow

I will add more details about the flow down below, but, at this point, here is a screenshot of what the flow will look like once it’s built:

image

3. Preventing default document location logic

There is a bit of a problem with this whole approach. What if somebody created a case and jumped to the “related documents” right away? The flow above is asynchronous, so it won’t create document location immediately. If a user navigates to the related documents too quickly, Dynamics will create default document location.. so we need to prevent that from happening somehow.

That’s what this real-time workflow will be doing:

image

It will run “on create” of the document location records, check if that record is regarding a case AND if it does not have a keyword in the Name field (which will be added to all locations created from the Flow above), and, then, will stop the workflow as cancelled.

Honestly, the error message is going to look somewhat nasty:

image

After a minute or so that grid will get back to normal, but, of course, the users will have to refresh that screen:

image

Besides, most of the time Dynamics users would not create a case just to start uploading documents right away, so there is a good chance that error would not be showing up in 90% of the cases. Still, there seem to be no way around it except the notorious “user training” (as in “yes, if you navigate to the related documents too fast, you will see an error message”)

Actually, the screenshot below shows exactly what’s happening in Dynamics as a result of the flow execution.

And, of course, a folder gets created in Sharepoint:

image

4. What about that flow, though?

Step one is a trigger. We need to create a document location for every new case.

Steps 2 will get case owner user record from Dynamics – this is to get to the business unit.

Which is what step 3 will do – it will query case owner’s business unit record from Dynamics.

image

In the next step, the flow will query document location record by name:

image

This is part of the setup, actually.

For every business unit, an administrator will have to do 2 things in advance:

  • Create a sharepoint library and setup permissions in such a way that only BU users will have access to that library
  • Create a document location record in Dynamics pointing to that sharepoint library (and having the same “name”)

 

Here is an example of the sharepoint library:

image

And here is a corresponding document location record:

image

So, basically, the flow will find that location by name (treecatsoftware is the business unit name), and, then, will use it as a parent location when creating document location for the cases in that business unit.

Finally, we need a foreach in the flow. Technically, there is supposed to be only one record that matches the condition (name = business unit name). I just don’t know how to reference exactly the first one in the record set, so I figured I’ll go with foreach:

image

This first action above will create a folder in Sharepoint for the new case. It’s an http request Sharepoint connector action, and here is the URI:

_api/web/GetFolderByServerRelativePath(decodedurl=’/sites/Dynamics/@{body(‘GetBU’)?[‘name’]}’)/AddSubFolderUsingPath(decodedurl=’@{triggerBody()?[‘incidentid’]}’)

And the second action will create a document location in Dynamics:

image

Here is a link to the exported solution (I did not try to import it anywhere yetSmile ): http://itaintboring.com/downloads/SharepointFolders_1_0_0_0.zip

2 thoughts on “Creating custom folder structure for Sharepoint integration using Flows

  1. Shidin Haridas

    Had similar requirements and decided to use MS-Flow and tweaks or hacks over the SharePoint CB Replicator (which is brilliant, but nevertheless, a 3rd party tool).
    For “3. Preventing default document location logic”, used JavaScript to hide the ‘Documents’ tab from the related section till the conditions are met (or in my case, once Flow ran successfully, it would update a flag field on the record)
    formContext.ui.navigation.items.getByName(“navSPDocuments”).setVisible(visibility)

    To reference exactly the first one in the record set, believe this might work:
    body(‘GetBU’)[‘value’][0][‘name’]

    Reply
    1. Alex Shlega Post author

      Hi Shidin, thanks for those tips.. makes total sense.. That getByName for the items bothers me a little since I can’t find a reference to that method in the documentation. But it’s a collection still, so worst case a loop should work.. also, I guess if I add a timer there to re-read that flag(or just to check directly if the document location exists), I can, then, re-enable the navigation once the document location is available (and can probably show/hide some kind of form notification, too). Will look into it – thanks!

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *