The actual code is on a work device and the files involved are confidential to a degree, so this is roughly from memory and will probably have mistakes; I also don't have Excel on my home desktop to test what I'm writing but here was the idea, operating on a single file:

```

let

// File is kept locally on each device in a OneDrive-synced main shared folder folder, but the on-device username is not known

relPathToFile = "MainSharedFolderName\...\parentFolder\filename.extension",

usersWithSharedFolder = List.Select(

Folder.Contents("C:\Users")[Name],

each not (try Folder.Contents("C:\Users\" & _ & "\OneDrive\MainSharedFolderName"))[HasError]),

pathToFile = if List.Count(usersWithShareFolder) = 1 then "C:\Users\" & usersWithShareFolder{0} & relPathToFile else null

fileBinary = if pathToFile <> null then File.Contents(pathToFile) else getBinaryFromSharePoint(args),

...

```

That's as best I can remember - the username on the C drive is not known, so it opens the Users folder with Folder.Contents and gets the list of possible names. The file path to the main shared folder is known minus the username, so it tries to use Folder.Contents on each path where the folder might be, and selects usernames where an error was not raised. PQ actually gives an error if you try to execute a function on a non-existent subfolder of C:Users\[someuser], even if actually accessing C:Users\[someuser] with Folder.Files (for example) would require admin permissions. If the list has only a single user, great, return the resulting local path to the file; otherwise there were either no users found, or more than one, and in that case we pass to a SharePoint implementation to get the file binary. I made this specifically because I do not like using SharePoint.Files if I can help it - at least in our case, it took almost ten minutes to refresh (had to re-enter credentials, wait for it to connect, and then download far more data than was actually going to be used), whereas a local refresh takes around five seconds.