What can View All Data do?

I hear this question quite a bit: "We have over one hundred people with View All Data which is too many. How can I reduce this number to reduce the risk that people can view more than they should be able to?"

Before you can reduce the list of who has View All Data, you may need to determine if any of those users have this permission for one of the following ten reasons listed below. If they don't need to accomplish one of these tasks, it's a good idea to change their profile or permission sets over to something that doesn't have View All Data. 

1. You need Read on all objects (Sharing is ignored in this case) - this is the primary use case for granting View All Data and what View All Records was meant to solve for by ignoring sharing on an object basis rather than across all objects.
2. You need to set the Running User of a dashboard to someone other than yourself (requires Manage Dashboards permission as well)
3. Anyone with Modify All Data, Author Apex, Download AppExchange Packages or Create AppExchange Packages will also get View All Data (it's required).
4. The "big deal alert" user on opportunities needs to have view all data
5. You need to view private attachments, notes, and Google docs from other users will be displayed in the related list and in the API
6. You need to view private events and tasks owned by other people are available in the calendar and API.
7. You need API Access to Forecasting
8. You need to do an API Upsert on a non unique fields
9. You need to use the System (Apex) system log (in the header)
10. You need to view private chatter groups

For more ideas on what to do when you have too many people with View All Data, check out this previous salesforce hacker post.

How Not To Give Out Modify All Data

Have you ever given Modify All Data to a user but didn't really want to?

If so, you're not alone.  There are several permissions that may be used to define an administrator. Modify All Data is the single best way to do it - it gives the user full access to all org data and about thirty other magical powers that clear their path to getting their job done. It is the ultimate power in the permission universe. After all, isn't that what it's really about, making it easy for a user to do their job?  Maybe it is, but it wouldn't it be great if you didn't have to give out full access to everything just to allow a user to download the data loader or empty the recycle bin?

It is possible to ween your users off their addiction to Modify All Data.  The key to properly enabling your users is to begin identifying the tasks that they perform that might require a permission like Modify All Data.  In some cases, those tasks are fairly straight forward and can be remedied.  For instance, I used to hear a great deal that Modify All Data had to be given out in order for someone to manage all of the data related to a custom object.  This didn't make much sense why we gave a bazooka to do a fly swatter's job, so we created the Modify All object permissions. Now a user may be granted Modify All records instead of Modify All Data in order to manage the data related to that one object and business process. This is an example of an easy decision to make.

But there are some requirements in the system such as the requirement for the automated case creator user to have Modify All Data. This isn't something that is easily remedied. 

And then there are some tasks that really can be remedied through creative solutions and features that you may have long forgotten about from the ADM 201 Admin training you took four years ago.  For instance, the ability to Login-As is granted for all users with Modify All Data.  But if your requirement is to enable users to Login-As a group of users, you can use the Delegated Administration feature found under Setup | Administration Setup | Security Controls | Delegated Administration to create a group and assign them Login-As rights to a role and/or subordinate roles worth of users.  In this case, all that would be required of the user is to have View Setup and Configuration.

In this post, we looked at a couple of specific examples how to remove Modify All Data from users who don't need it by giving them an alternative permission.  In future posts, we'll continue to examine creative ways to enable users with only the tasks they need to do rather than give them the easy way out by giving them the reins to the Death Star.

API Usage Notification, Who Knew?

I've been at salesforce.com almost eight years and I love the fact that I'm still finding new things to dig about the service. I found this gem of a feature last week. What surprised me was not discovering this feature, or the fact that it has been there for about two years, but that everyone I told about it was also amazed that it existed. I was so excited about my find that I wanted to share it with the world.

This feature solves a common problem for developers and system administrators. Over half of all salesforce.com transactions are API based. At a billion transactions per day, that's a lot of API calls. As with most things that voluminous, there are limits to help protect the service for everyone. If you run into one of these limits, you may be prevented from continuing, which can be a problem if you're in the middle of a nightly data load or are using a mission critical application that relies on the API.

API usage notifications sends an email when you have hit a configurable threshold. For instance, you might want to know when you are 50% of your API limit threshold and again when you are 80% of your threshold. This information can help you prevent a work stoppage, develop some simple forecast capacity planning, and react if you're about to hit a limit.

Monitoring usage is critical to the health of your business applications. This is just another way you can get what you need to keep your mission critical apps running.