Tuesday, December 15, 2015

Quick Implementation Tips: Reports and Views

Having helped implement a number of SalesForce systems for customers, I have learned some best practices/tips that can make an implementation go much easier.  This is the second post about this topic.  You can read the first one here about profiles and standard settings.

In this post I will review the report and view changes I usually make.

First, with Dashboards (under DASHBOARDS), I often remove the Company Performance Dashboard as it contains metrics that aren't relevant to the company in question.  Instead I will often create a custom dashboard towards the end of their implementation.  Also, don't forget to update the Home Page Dashboard too.

Second, with reports (under REPORTS), I often set all the default report folders to not be visible if I don't think they will have a use for the client.  This is done by clicking on the report folder and clicking 'Share' and then removing access.  I do this because many of the reports, like dashboards, don't contain the relevant fields or terms (and since they are standard reports you can't save changes).  So i just remove them.  And additional benefit of hiding the folders is that I can make new folders with appropriate permissions and save a "Report Clean-up Project" in a year.

Third, with views (under any OBJECT), I often create views (by clicking 'Create New View') that will be relevant to the customer based on the data they have.  This is because otherwise they have no easy way to access the data they are expecting to see with ease.

Finally, within a page layout, I often will update the related list fields so that they are more appropriately.  For example, most customers don't initially use 'Campaigns', but the 'Campaigns Related List' always shows on Leads and Contacts.  So I will remove that or alter the columns as appropriate.

That's all.  Nothing too fancy but just some configurations to make things easier for the users.

Friday, December 11, 2015

Quick Implementation Tips: Standard Settings

Having helped implement a number of SalesForce systems for customers, I have learned some best practices/tips that can make an implementation go much easier.  This is the second post about this topic.  You can read the first one here about profiles.

In this post I will start the tips I have learned around standard system settings to ensure that are setup.  All of these are in SETUP
  • Setup>Build>Customize>User Interface.  Commonly the "Enable Collapsible Sidebar" is not enabled automatically.  I usually enable this so that you can ensure users can maximize their screen space.
  • Setup>Build>Customize>User Interface.  Commonly the "Enhanced Profile User Interface" is not enabled automatically.  I usually enable this so that the user's have the best experience when editing their profiles
  • Setup>Administer>Security Controls>Password Policies.  Commonly the User Passwords expiring every 90 days is too often for some organizations.  I usually change this to 180 days.  I also usually change the Lockout Effective Period to Forever so that administrators have to unlock a user after 5 wrong passwords
  • Setup>Administer>Security Controls>Login Access Policies.  Commonly the "Administrators Can Log In as Any User" feature is not enabled.  I always enable this so that once the client goes live, I can easily log in as a user if they are having issues and troubleshoot them with ease.
  • Setup>Administer>Company Profile>Company Information.  For most clients, they would benefit from using multiple currencies but don't know this feature exists.  And enabling after they are live has it's own challenges.  So usually I will check the box to "Allow Support to Activate Multiple Currencies" and I will also log a case to get this feature turned on
  • Setup>Administer>Communication Templates>Letterheads.  Commonly there is no letterhead ever created; however, users have the ability to create email templates that use the letterhead (but unfortunately don't have the ability to edit said letterhead).  So I always create a basic letterhead so if a user does go in to create an email template using the letterhead it at least looks presentable.
  • Setup>Administer>Domain Management>My Domain.  Most clients, over time, will require their own domain within SalesForce to enable some features (e.g. sampleclient.my.salesforce.com).  So, rather than waiting for that time to come I get this setup at the start so that users don't need to update bookmarks, etc. in the future.
Those are the common settings I always change.  In the next post I will discuss some of the report and view changes I usually make.  

Wednesday, December 9, 2015

Quick Implementation Tip: Standard Profiles

Having helped implement a number of SalesForce systems for customers, I have learned some best practices/tips that can make an implementation go much easier.  So, over the next few blog posts I will highlight some of those tips in detail.

To start this series, I will start with tips I have learned around profiles.  When a new SalesForce system is turned up, a number of standard SalesForce profiles are enabled.  These are usually named System Administrator, Marketing User, Contract Manager, Solution Manager and Standard User.  While these profiles are great and contain everything needed, there are some gaps I have discovered about them which include:

  • You can't easily edit them around what system settings are available
  • You can't easily edit them around what they show
  • They often contain all the objects/tabs and cause confusion for new users
So, what I personally recommend is cloning upon first setting up the system.  For example, I would clone the 'Standard User' profile and make a new one called 'Client Name Standard User' and I would also clone the 'System Administrator' profile and make a new one called 'Client Name System Administrator'.  Then I would go into these profiles and do the following:
  • For the standard user profile I would update it to only include the objects I want there for go live.  So, often I would hide Ideas, Contracts, Solutions, etc. unless their implementation was actually going to use those features on going live.  I hide these because when doing training with new users, change is scary enough to a new system.  Having to remember that they don't use "this tab" or "that tab" initially makes it even harder.  I might as well hide those tabs until the client is ready to actually do the proper implementation of said feature
  • For the system administrator profile I seldom change anything; however, by having this in place if there client decides in the future they want a "junior administrator" vs a "senior administrator" I have already got the leg work ready here.  This also gives me the ability to remove features from the client's administrator view if needed.
In the next post I will discuss some of the report and view changes I usually make.