I have a flow that triggers 'When a file is created (properties only)' in a document library. The flow works properly for me, but does not trigger for any other users. I have added the library under the SharePoint section of owners. I have made a simple flow that just sends me an email notification when a file is created, and the problem persists. I have tried adding other user accounts as owners of the flow as well and it still doesn't trigger. The folder line is left blank to include the whole library. In the document library I have Content Approval turned on.
I want this flow to trigger every time a new document is added to the library regardless of the user. Currently the flow only triggers for me. I feel like this is a simple problem, but I can't find the answer anywhere.
Thanks for any help.
You mentioned you have Content Approval turned on, which means this library is in a Publishing site. Have you set any of the options in the library Versioning Settings > Draft Item Security? If that is set to show draft items only to users who can edit or approve items and the original maker wasn't an Approver then the flow running in your context may not see documents created by other people and therefore won't trigger.
Thanks for the reply,
Yes, it is set to only users who can edit the document. I suspected this had something to do with it. The flow owner (me) has full control in the library and can edit all the drafts in the library, however I cannot see documents created by other users until they are checked in as a draft for the first time. This is odd behavior in my opinion and really undermines what I perceive as the intent for the Created trigger for automation. Is there anyway to get these documents to show up for the edit users before the initial draft check in? (So the trigger will trigger) The content control settings must remain as is for this application.
The workaround is to use the Modified trigger with column indicating if it has been processed, then it will trigger at the first check in, but this is not very elegant and the auditing of the document is delayed as is the information passed to the user.
Same problem: Created a simple Flow to trigger when a file is added to a SharePoint folder (When a File is Created - Properties Only). Next step is an Action to notify. Two steps - couldn't be simpler.
The point is that the way SharePoint enumerates documents to show you is by getting all the documents that are checked in and then deciding whether you should see the latest draft of the latest published version of the document. If at least one draft version of the document hasn't been checked in then the document doesn't exist officially yet. If it is checked in as a draft and you are only able to see published versions then you also won't see it until a published version is checked in. Since the trigger works off your permissions it won't trigger on documents you can't see. That is by design and I doubt it will change since its been that way in SharePoint since Publishing was introduced.
I also don't think your modified trigger will work for other users. If it isn't a document they can see then it won't trigger.
As I explained. This is all dependent on the version settings of the library. If they are set to hide draft items from non-admin users then this will happen. Automated flows run in the context of the maker. So if you can't see a file in a library because someone else put it there as a draft then the flow won't trigger. Turn off the special versioning settings in the library, refresh the connection and you will find that it will now work for all files.
Thanks @Pstork1 for your quick reply!
I'm not fluent in SharePoint, nor is my Team. We're approaching from the Microsoft Teams interface and folders - whether seen in the Teams interface or synced to our local Windows File Explorer - just look like folders to us. We aren't aware of nor use any check in/out features. We just drop files into folders and use them as we would in File Explorer. No one ever seems to have a problem seeing any files in any folders.
I went looking for "special versioning settings". In the SharePoint interface on the Documents screen where I can see all the sub-folders associated with a particular Team, I clicked on the Settings icon in the upper right corner and selected "Library Settings". In the "Documents/Settings" screen that comes up there is a link for "Versioning settings". Clicking on that takes me to "Settings/Versioning Settings". I can't seem to paste in an image of what I see but the settings are:
Not sure where to go from here. I don't think we have any special versioning settings applied based on the above but I may not be looking at the correct items. Can you point me to a reference or the correct item I should be looking at?
Thanks again and sorry for my inexperience with SharePoint.
If those are your library settings then you are not experiencing the same problem that the original poster is experiencing. I'm not sure why its not working in your environment. I assume you are uploading the files through Teams and that may be causing the problem. Teams may be adding the files to the library as a system update rather than a user update. But that is just speculation. I don't know why it wouldn't be working in your environment. I'll need to do some testing and see if I can reproduce it.
Thanks @Pstork1 .
Sorry for glomming on to Jedd's post but his title was bang on the issue I've been experiencing. To add color - We have synced our Teams folders (which I understand is actually SharePoint) with File Explorer on our desktops so we can manipulate files just as we would in any file system. When a new file is dropped into a particular folder I'd like to trigger a Flow and do some actions on the dropped file. This used to work fine (after, as I said, I elevated myself to an admin user) but mysteriously stopped working over the summer. Now I'm back to having the trigger only fire when I drop a file into the folder and not having it trigger when anyone else drops a file. Also, it doesn't matter where we do the file dropping - in the Teams interface or in File Explorer - the results are still the same; it triggers for me and no one else.
I haven't tested the syncing scenario, but I just finished testing the scenario where a Team member (not the maker of the flow) uploads a file to Teams and the flow does trigger as expected. I am unable to reproduce the issue.
Having said that, I wouldn't be suprised if a file that is added to the system by syncing it from a folder on your desktop would NOT trigger the flow. But as I've said I haven't tested that. I did test the direct upload scenario and it is working as expected.
Thanks @Pstork1 - it is great to hear that it works for you. Now I just need to figure out why it doesn't work for me! You say you tested "where a Team member (not the maker of the Flow) uploads a file to Teams". I'm guessing this means you used the Teams interface to do a file-copy operation to drop the file into the trigger folder. Of course we have tried it that way as well but on our end it doesn't work (or rather it did but stopped over the summer). Strange.
I keep feeling there is some kind of setting that I am overlooking, but this all seems so straightforward and should be easy. Is there anything special about your setup that might be different than mine and provide a clue? We're a small business with Microsoft365 subscriptions for several employees. Could any of this tie to a subscription or service level that you (and others of course) have that perhaps we do not?
Other than the library settings we've already discussed there is no subscription level setting that I am aware of that would cause this. My setup is plain vanilla with users added through the Teams interface using the standard permissions for the public channel. I used both the upload menu and drag and drop to do the upload. Both worked. But I should add that there is an up to 5 minute delay before the trigger fires. This is typical of File triggers in Teams.
Things to check.
Learn how to create your own user groups today!
Check out the new Power Platform Community Connections gallery!
Join us, in-person, December 7–9 in Las Vegas, for the largest gathering of the Microsoft community in the world.