Creating custom folder structure for Sharepoint integration using Flows

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:

• Custom implementation
• Tools like CB Permissions Replicator

 

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:

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:

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:

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:

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

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:

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.

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

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:

And here is a corresponding document location record:

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:

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:

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