Restrict/Manage Report Builder Permissions

We want to grant permissions to some of our CSM team to be able to view and create reports in Report Builder, using this approach, so that the admins don't always have to be asked to pull reports for them.  I was hoping to be able to manage the repository by only allowing these users access to certain folders. 

For example, we have many reports that exist on dashboards and the 360, that we don't want these users to make changes to.  It would be nice if they could have "permission" to only view/create reports within a specific folder in the repository so that the entire repository wouldn't be flooded. 

Is this something that is currently possible? If not, any plans for further granularity when it comes to allowing access to Report Builder?
It is definitely in our plans to support permissioning on folders in our short term roadmap (next releases in early 2018)
Thanks Denise - love your use of the word "definitely" ;) 
We plan to release the folder and permission for dashboard folders first
Any word on this? It's early 2018 🙂
Permissions on dashboard folders is releasing this winter. Allowing the CSMs to build their own reports is on our roadmap thats gaining increasing weight by day.  Folders in both reports and dashboards is going to help that ask / feature. Will update here again when we actually take that feature up.
Hey, You can find the above enhancements in our Winter Release. Our Winter Release notes is out,please refer this article. This will help you in configuring. Thanks for sharing 🙂
I would also appreciate ANY permissioning we could do for Reports, whether it's at the folder level, or on individual reports, or even just a profile level control.  We'd love to open up the ability to create reports to more people, but I'm terrified someone's going to delete a report we've created and shared on a dashboard, without realizing it. 
This idea says Implemented...but I don't think Report Builder permissions were implemented, right?
We released dashboard permissions with the Winter (February) release but ran into some unexpected issues and had to temporarily turn off that functionality. We will re-enable it soon.
Was that the Who ID/What ID stuff? I read over the release notes but didn’t realize that was the permissions piece. The concept wasn’t exactly clear (to me anyway) but I didn’t have an opportunity to spend much time on it.
The WhoID and WhatID functionality is tied to reporting and allows referencing user or object details in a different object via lookup. 

This link explains the purpose and examples of WhoID/WhatID:

Here are the details on the dashboard permissions that we had to roll back.

also, I misspoke a little when I indicated report permissions. That is coming next right after dashboard permissions.
Also status is corrected to Planned.  

Jeff will take your feedback on the WhoID and WhatID and review our documentation and explanations of that.
Thanks Denise!
We are already getting questions about this from our CSMs before rollout and I have run into this in previous jobs/companies as well. Any permission capabilities would be awesome!
Is there an update on this? Do we have the ability to permission folders in Report Builder?

Voting for this as well. It would be nice if we could restrict users to only be able to create a new report or save a copy of an existing one. I believe this is how SF’s default reporting permissions work. This way we could open up the report builder to as many people as we wanted without fear that critical reports could be deleted or modified. 

Echoing the above sentiments and voting for this as well - would love more granular permissions around reporting as in SFDC, to give people ability to view reports without them having to be nested in a dashboard, but not give them abilities to create new reports

Hi @angelo.morlani 


We do have plans for End User Reporting. Today you can open up report builder to end users but we do not have enough access controls to stop them from changing reports. We want to provide permissions on reports too so that you can open it to end users