Tricks all Salesforce Admins Need part 1 of 7 – Switching Page Layout Views #ForceFriday

Today we launch part 1 of a 7 part series I’m Tricks all Salesforce Admins Need. Today’s topic is switching to between the Enhanced Page Layout Editor and the Classic Page Layout Editor. This is an very simple distinction, only one checkbox in Setup, but can cause hours of searching for a solution if you don’t know the trick to switch.

You might need to switch to make a to the classic page layout if you receive an Internal Server Error while editing a page layout. The Internal Server Error can be caused by several issues including an actual Salesforce database error, corrupted fields, the Salesforce Physical Delete process not completing, and a bunch of other potential causes. The important thing is that they all present with the same error: “Internal Server Error”.

To switch to the classic Page Layout Editor:

  1. Go to Setup > App Setup > Customize > User Interface
  2. Uncheck the checkbox next to “Enable Enhanced Page Layout Editor”
  3. Click the Save Button
  4. Go to the Page Layout you are trying to edit and make the change you want
  5. Got to Setup > App Setup > Customize > User Interface
  6. Re-check the checkbox next to “Enable Enhanced Page Layout Editor”
  7. Click the Save Button


Open Records and Inactive Owners – #ForceFriday

Employees come and go. Its a natural part of the ebb and flow of business. Keeping up with the data transfers when employees go can be a headache and often falls to the administrator to manage. By default, Salesforce offers a way to report on this via standard fields on the User object, although you need to manually add these fields to a Custom Report Type. However, a custom formula field offers a bit more flexibility including the ability to add the formula field on the page layout as well as use as a filter in the Mass Transfer Wizard. However, the report option may be all you need or you may be in an organization with long change management process so getting a formula field in production may not be feasible on a timeline you need. For these reasons, I’ve included instructions for both the reporting and Formula options:

Adding User Active Field to Custom Report Types:

To add the Active User field to Custom Report Types follow these steps:

  1. Go to Setup > Build > Create > Reports Types
  2. Either Create a new Report Type or click on the Report Type Name of an existing Report Type
  3. Click on Edit Layout
  4. Click on the “Add fields related via lookup »” link
  5. Click on the “{object} Owner »” link
  6. Click the checkbox next to “Active” and then click the OK button
  7. Click the Save button.

Adding a custom Formula to identify Inactive Owner:

Fortunately, a simple formula is all that is needed. I’ve put together the most common standard object formulas needed in an un-managed package if you don’t want to take the time to put in the custom formula’s yourself.

Inactive Owners (Accounts, Contact, Opportunities, Activities, Leads, and Cases) –


However, if you are looking to put this formula on a different object or want to put these in yourself here’s the steps:

  1. Go to Setup > App Setup > Customize > {Object} > Fields  – If creating the formula on a Standard Object – Go to Setup > App Setup > Customize > Create > Objects > {Object} – If creating the formula on a Custom Object
  2. Click the New button in the Custom Fields & Relationships section
  3. Select Formula and click the Next button
  4. Select Checkbox and give the field a name – Click the Next button
  5. Enter one of the two formulas in the editor, depending on if the object has access to a queue owner

Object with only user as owner:

Owner.IsActive = TRUE,

Object with only user/queue as owner:

Owner:User.IsActive = TRUE,

6. Click Next and determine the field level visibility and page layouts you want to add to the field to

Note: In Professional Edition the report visibility of individual fields is determined by if the field is on the page layout or not. Since we want to report on this field, Professional Edition orgs should always have this field on the page layout

Reporting Options

Now that you have created the correct reporting fields you can include them as report filters and even create a custom dashboard with a component for each object.

Having certain records owned by inactive users is not necessarily a bad thing. For example, closed Opportunities should remain in the users ownership, even if the user is inactive. This would be to ensure historical data integrity as well as not attribute past sales to an existing user. However, if an employee leaves the company with open Opportunities the administrator will want to transfer those records immediately. The point here is to build in a process that makes senses for your organization with regards to inactive owners.


Example Opportunity Filter to produce a list of open Opportunities owned by inactive users.


Tips for reporting:

~ Reports should be filtered on open records
~ Reports should be summary reports so they can be added to Dashboards
~ Create a Dashboard and schedule it to yourself and any other interested parties on a regular basis to ensure consistent data quality

Sandbox Refresh Checklist – #ForceFriday

I like Fridays… especially this one as it’s New Years Day! Fridays are the perfect day to wrap up projects, close out the week, and start your weekend which for me usually means baby duty and marathon training #MoreWorkThanWork. Its also a good time to kick off a Sandbox refresh since they sometimes take a while to complete (especially the Full Sandboxes). Today is also the last day to get your Sandbox on the Spring 16 Sandbox Preview ( Don’t wait!

Image courtesy of Salesforce

Here are a few things that I check before I refresh my Sandbox and a few things I always do after its finished.

Check if there are any changes going on – Setup Audit Trail and Login History

About a month ago I got an email from a colleague that made my heart sink to the bottom of my stomach. I had refreshed my personal Sandbox I use for just messing around and had erased some development work he was doing. I gave him access to my Sandbox just to play around and do some testing… and then promptly forgot I had done that. Fast forward a month and there goes his work.

I always try and check the Setup Audit Trail and Login History before I refresh a Sandbox which would let me know what’s actually going on recently in the org. If there are changes that aren’t expected or haven’t be migrated to another Sandbox or production then that’s your red flag.

Refresh on a Schedule

Salesforce does three releases a year and companies should identify some Sandboxes to be refreshed along with this schedule. There are several different thoughts on development cycles and Sandbox refreshes to match those cycles. Outside of the whatever development cycle you use some Sandboxes should be matched to the release lifecycle with Salesforce releases.

Enable Sandbox only users

Many times, some users, such as developers, contractors, or even admins technically only need Sandbox access. Instead of paying for a production license you can maintain a list of users that only need Sandbox access and put in place a policy to load those users immediately after the Sandbox refresh.

More details from Salesforce on Sandbox Best Practices:

Email Deliverability

By default, after a sandbox refresh the Email Deliverability is set to “System Email Only”. This limits two things:

1) Ability for email to be sent from the Sandbox with exception of system emails like error messages.
2) Disables the visibility of the Send Email Global Action

In testing, email deliverability is integral in most processes and testing the delivery of said email is important. Add this setting to your post-refresh process and you won’t have to worry about it!