Answered

Can I change the name of a sharepoint folder by using the sharing link

(0) Share

Report

Posted on by mvdb

When a new record gets created, a Flow creates a sharepoint folder with the primary field as name. When I change the primary field of that record, I want my sharepoint folder to changes names to the new value of the primary field, as of now I do this by using a second flow. I register the url of the sharepoint folder (which contains the path of the folder). My (second) flow gets triggered when a primary field value gets changed. I'm glad as my url with folder path doesn't get adjusted on the spot, because I need the previous value of my primary field to find the folder that should be adjusted. The actual changing of the folder name happens with an HTTP request, where I enter the folder path.

This works for now but isn't flawless. I know I can retrieve a shareable link of the folder with a flow, this link doesn't change when the sharepoint folder name gets changed. Is there a way I can use this shareable link to change the folder name or find the folder when using the HTTP-request instead of using the url with folder path? Thank you.

Categories:

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (3)

Answers (1)

EricRegnier 8,720 Most Valuable Professional on at

Like (1)

Report
Hi @mvdb,

Couple of questions/comments:

What do you mean by "the url doesn't get adjusted on the spot"? Isn't the 2nd flow that renames the folder so it will never get adjusted before the 2nd flow runs. That said if I understand correctly, I don't see the issue/flaw.

Do you need to set the folder name with the primary field? Possible to use the record ID (guid) instead as this will never change and perhaps simplify your design?

I assume you already tried changing the name with the shareable link instead? What's the error? And which Power Automate connector are your using?

Cheers!

Was this reply helpful? Yes No
mvdb 64 on at

Like (0)

Report

Thank you for answering:
1. my url (with folder path) gets created by a OnLoad-script (if the primary field is filled) by composing the basic url with the folder pasted at the end. This Url is used to change the sharepoint folder name because the HTTP request requires the folder path. The second flow collects a custom url with a bunch of random characters. So if the first URL doesn't get changed on the spot, the folder will still be accesible with the custom link.
Your point is correct, but unfortunately with my method, the primary field can be changed twice while not leaving the form and the flow would start twice (because I have a necessary OnSave-script when the primary key gets changed), but the OnLoad-script-composed link would still point to the first folder path, making the second flow impossible to complete.
2. Yes, the Sharepoint will also be accessed independently and without the primary field it would be to hard to navigate.
3. I tried using the 'HTTP-request to Sharepoint' with URI "api/web/GetFolderByServerRelativeUrl" as I did with the folder path url. But where I put the folder path usually, I placed the custom string from the second URL and got the error that the expression isn't valid.

I know I put myself in difficult situation and as of now I'm thinking of making the primary field unchangeable after one change or composing the script-url on the OnSave-event. Your thoughts?

Was this reply helpful? Yes No
Verified answer

EricRegnier 8,720 Most Valuable Professional on at

Like (1)

Report

Makes sense, and true since the flows run asynchronously there's the risk of a race condition; the 2nd run running before the 1st. One way to manage this is to have some sort of "processing complete" flag field on the table/entity. By default it's true, when the 1st flow run, the first thing it does is sets it to false, when it completes, sets it back to true.

The 2nd flow then waits until that flag is true. When it is, 1st thing it does is set it to false and when it completes, sets it to true again. Maybe not 100% bullet proof but will reduce the risk immensely. If you're still uncomfortable then on top of that flag, you can implement a lock mechanism with the changeset action.
BTW, why onload/onsave scripts and use Power Automate only? That way all your SharePoint logic is in those flows and not mixed up...

Was this reply helpful? Yes No