Conducting An Org Health Check 2


In this post I’m going to cover some tips to help you to get to a more happy and healthy org.  The first set of tips are on SOQL to help you check who has what permissions, moving into the more standard administrator org health checks through the user interface and then on to adoption and data quality.  There’s something in here for everyone so don’t be shy. Pull up your sleeves and let’s get into the weeds.

 

Before getting into the weeds, it bears mentioning that conducting an org health check should be approached systematically.  It is important that we check all aspects.  For the sake of brevity, I’ll share a few tips with you in this post that will help with that.  Here are the things that I have checked in the past:

  1. Profile Permissions (Customize Application, Modify All Data, View All Data, etc. as well as Object / Field level security)
  2. Role Hierarchy
  3. Org-Wide Defaults
  4. Login History (Amount of users logging in at 30, 60, 90+ day intervals)
  5. Chatter Usage and objects Used On
  6. Apex Class / Triggers
    1. Code Coverage
    2. Only one trigger per object
    3. No hard coded Ids
    4. There are not references to only the first item in a list e.g. someList[0].Id
    5. No DML statements or SOQL queries in for loops
    6. Tests contain assertions per test method
    7. There is a positive and negative test case (what happens happens and what shouldn’t doesn’t)
  7. Connected Applications

What do you look for in your orgs that I haven’t mentioned above?  Feel free to share in comments, the twitters or the success community.

 

Let’s Get Started

Go to Workbench, your new best friend!  You can do so much in this playground it’s ridiculous.  Right now though, we’re going to just stick to SOQL queries on the PermissionSetAssignment object.  This object will be your new best friend.  It can tell you magic about users and profiles/permission sets in one fell swoop.  There are a few other objects that have some magic worth mentioning, ObjectPermissions, FieldPermissions and SetupEntityAccess, etc.  I’ll save those ones for another time.

 

Too Many Users with Customize Application

This permission contains so many permissions, most of which allow for “sys admin” type privelges in your org.

1. Limit the number of users that have the customize application permission.  You can query a list of all users that have this permission in Workbench by using the following:

 

SELECT Assignee.Name, PermissionSet.Name, PermissionSet.Profile.Name 
FROM PermissionSetAssignment 
WHERE PermissionSet.PermissionsCustomizeApplication = true

 

Too Many Users with “Modify All Data” and “View All Data”


2. Limit those that have “Modify All Data” and “View All Data”, though there are legitimate reasons for having them.  Best practice is that they are assigned by permission set and not for profiles.  You can query this with the following:

 

SELECT Assignee.Name, PermissionSet.Name, PermissionSet.Profile.Name, PermissionSet.PermissionsModifyAllData,PermissionSet.PermissionsViewAllData
FROM PermissionSetAssignment 
WHERE PermissionSet.PermissionsModifyAllData = true OR PermissionSet.PermissionsViewAllData = true

 

Connected Apps

3. Check your connected apps and make sure that your apps are ones that you have thoroughly reviewed.  I’m going to shamelessly redirect you to my blog post on this:

http://www.sfdccloudninja.com/admin/connected-apps/

 

Licensing

4. Make sure that the licenses that you have for your users are appropriate for their needs.  The best way to know this is to know their role.  Are they a support rep?  Then they should probably have a full license so they can access cases.  Are they in the sales role?  Then they will need a full license for sure.  Are they in marketing?  They will need one for leads and campaigns.

 

Login Rate

5. Check to see how many of your users are logging in at 30-60-90 day thresholds and use this as a benchmark for your performance.  Also seek to find out why these users are not logging in.  Is it because they aren’t finding value in the system?  Is it because they are on an extended vacation?  You can use the queries below to find that out (and I’m including the manager’s email in case you need to really raise some flags):

 

30 Days:

SELECT Name, Email, UserRole.Name, Manager.Name, Manager.Email
FROM User 
WHERE LastLoginDate = LAST_N_DAYS:30 AND User.IsActive = true


31-60 Days (replace 31 and 60 with 61 and 90 for that window)

SELECT Name, Email, UserRole.Name, Manager.Name, Manager.Email
FROM User 
WHERE LastLoginDate >= N_DAYS_AGO:60 AND LastLoginDate <N_DAYS_AGO:31 AND User.IsActive = true


90+:

SELECT Name, Email, UserRole.Name, Manager.Name, Manager.Email
FROM User 
WHERE LastLoginDate >= N_DAYS_AGO:90 AND User.IsActive = true

A Great Tool for Automated Checking

6.  Check out the Salesforce Toolkit.  It has an org health check which can run other automation on checking code coverage, usage on objects, record type usage, number of fields, layouts, etc.  It has some other useful tools as well.

Salesforce Toolkit

 

Check your Role Hierarchy & OWD

7. Make sure that your OWD settings and role hierarchy is set up as it should be.

Overview
Org Access
Org Wide Defaults (OWD)
Record Access View Roles

There’s this amazing guy named Brent Downey, don’t know if you’ve heard of him, you know…. the one and only Admin Hero?  He’s got this killer post on building a rock-solid role hierarchy:
How To Build A Rock Solid Role Hierarchy

 

Adoption And Data Quality

8. Don’t reinvent the wheel, check out these dashboards and customize to your needs!

Salesforce Adoption Dashboards

Chatter Usage Dashboards

Data Quality Dashboards  – this one runs on formula fields on each object so you can customize it for what you consider a “wholesome” record.

As always, install in a sandbox or your own DE to test!

 

 

Remember, a healthy org is a happy org!


Leave a comment

Your email address will not be published. Required fields are marked *

2 thoughts on “Conducting An Org Health Check