Cheryl Feldman’s Post

Hi Cheryl Feldman, One of the common usecase I have seen is Dataware House Integration User, where DWH team want to pull all the necessary data for almost all objects and fields. This burns couple hours to days for every release.

I'd personally prefer a View Summary Button on the Object Page to be able to see what Profiles/Permission Sets have access to that Object. With Select All mass assigning FLS is easier than it was. However View All Fields at the system level would be super helpful for System Admin Users.

If you're talking as broad of a perm as it sounds, this could open the door to huge security breaches. I'd be very cautious of enabling this kind of permission. When I've configured API users, I only gave them access to the objects they actually needed for specific integrations. Imagine someone hacking an integration user. If the user is granted access to more objects than are actually needed, you've potentially given the hacker the "keys to the castle". Just my 2 cents on the issue.

We would have loved to use an API only license for OwnBackup but couldn’t because of the restrictions listed in this knowledge article https://kb.ownbackup.com/articles/knowledgebase/Using-the-Salesforce-Integration-User-23-5-2023

Thanks for continuing to make Salesforce Admin's lives easier! I love the idea of having View All on the object level with all the fields. For integration users (especially Salesforce to Salesforce) and even some internal one it can be time consuming to keep adjusting the access with the addition of new fields. I am not sure about View All on a system level (all objects with all the fields) and can see some security risks with it and creating redundancy. I think we all usually backup MOST of the objects to DWH and it would be interesting to hear how many customers actually need to have API only user that have to access all the objects with all the fields.

Data Warehouse integration user, comes up every release where perms get slightly out of sync and manual intervention is required. If the org is using a singer-based ETL/sync tool like Stitch.io, integration systems then need updated once the perms have updated. Enough of a PITA that my engineering team brings it up every few weeks.

We often have clients request a user (or set of users) have read only access to parts of the system. They need to see the data but not interact with it. Having a view all fields in this object and use that across the set of objects given to those users would be amazing! Also, expanding on this, as Salesforce moves away from Profiles and goes to permission sets for CRUD and FLS, it would be great to have view all and edit all to apply to system admins and others

This would be so helpful for backup and archiving tools which to function properly need access to all objects and fields. I have a recurring Slack workflow at the end of each sprint reminding my team to ensure any new objects/fields deployed were added to the permission set for the tool.

This would be great - aside from the data warehouse / reporting scenario that has been mentioned already, the other where this commonly comes up is data backup. Common AppExchange providers like Own, Odaseva, AvePoint usually get set up with a dedicated user that need view all fields to ensure all production data can be safely retrieved and backed up

The amount of time this would save…