☏ 01494 590428 | ✉ hello@commerceworks.net

Salesforce Self Implementation Gotchas

We have a number of customers that implemented Salesforce themselves. To be transparent, my first encounter with Salesforce was to implement it myself, with no prior training. Now I know what I know, I think I did a pretty good job with no screw-ups. That said, I’ve worked with Enterprise systems all of my working life so I knew what to look for, even if I had to find out where it was.

When working with customers that self implement, there are a number of things I look for first that need to be corrected or haven’t been done, making Salesforce much more productive. Here’s my quick list.

Please note this only skims the surface of Salesforce setup and configuration

User Profiles (Setup | Users | Profiles)

User profiles are the first destination, every time. User profiles are part of the security system that controls what people can and can’t do and data they can and can’t access (there’s a little more to it but let’s start simple). The most common mistake is every user or too many users are System Administrators. The Sys Admin profile is the access all areas free pass to every part of your Salesforce instance. It includes such gems as mass deletion of records and the ability to send automated emails to all customers on a simple record change. A malicious employee with Sys Admin privileges can do an awful lot of damage to your organisation. Simple tip, no more than 2-3 Sys Admins and give everyone else the Standard profile. If the people with Standard profiles can’t do their jobs, clone it, assign the cloned profile and build from there. Start with limited access and slowly increase based on need. Don’t give staff the nuclear launch codes when all they need is to fire a rubber band across the office.

Standard documentation on profiles is here https://help.salesforce.com/articleView?id=admin_userprofiles.htm&type=0

Deleting Stuff (Setup | Users | Profiles)

Within Profiles you’ll see your list of objects (contact, account, opportunity, etc) with checkboxes and column headings – Read, Create, Edit, Delete. Delete means exactly that and if you don’t want your users to delete records you need to uncheck that box.

You’ll often see this referred to as CRED (Create, Read, Edit, Delete).

Users often incorrectly enter records so it’s annoying to not be able to delete the mistakes so just include a simple checkbox on the Contact, Account and Opportunity page layouts called “Flag for Deletion” then build a simple report that only selects records with that flag. You get to choose what get’s deleted rather than your staff.

Standard documentation on object permissions is here https://help.salesforce.com/articleView?id=users_profiles_object_perms.htm&type=0

Company Settings (Setup | Company Settings | Fiscal Year)

Company settings needs the basics, especially fiscal year for reporting.

To define you fiscal year https://help.salesforce.com/articleView?id=admin_about_cfy.htm&language=en_US&type=0

Sharing Settings (Setup | Security | Sharing Settings)

I always have a conversation with the client about sharing settings what they want their teams to see – everything or just their own records? The response is generally polarised – a definite yes or no either way. Remember you can share different objects in different ways. For example you may choose to share Accounts and Contacts but keep Opportunities private to the individual.

Sharing settings are generally;

  • Private – to the record owner so no-one else can see the record
  • Public read only – everyone can see the record but only the record owner can edit (or delete depending on CRED)
  • Public read/write – everyone can see and change everything depending on CRED
  • Public read/write/transfer – some objects (lead and case are examples) allow users to transfer ownership of the object
  • Controlled by parent – the parent object controls the child. Accounts and Contacts are a good example. Accounts are the parent, Contacts are the child. The sharing settings for the parent are inherited by the child. Therefore if you set your accounts to Public Read Only, the associated Contacts will be Public Read Only.

To setup sharing settings https://help.salesforce.com/articleView?id=admin_sharing.htm&type=0

Adding Fields

Adding fields is well documented and a relatively simple process, including managing page layouts. The main point here is to try and use structured data entry such as picklists and checkboxes where possible as they’re much better for data entry and reporting.

Video on creating custom fields http://salesforce.vidyard.com/watch/um8ZtKv_2awfCTitmz0vtA

Data Import

Cleanliness is the watchword here. We always ask clients to clean their data and we nearly always have to clean a certain amount. Some common examples:

  • In a list of Contacts and Accounts, account names are spelt differently every time. E.g. ABC Co., ABC Company, ABC, ABC Ltd, etc. If they’re all “ABC Company” then make them identical otherwise Salesforce will create multiple Account records
  • Address details in the wrong fields. E.g. postcodes in the town field or all address details in a single field
  • Duplication of records.

Put your data into an Excel spreadsheet and use the cell highlight rules and duplication function to find duplicates then delete them. Work through the columns and check the values are in the correct fields. Yes, it’s tedious but much cheaper for you than to pay me.

Note to self – I can’t find a particularly good reference so I’ll write one.

Reporting and Dashboards

Once reporting and dashboards are correct, I see usage of Salesforce increase. There is a school of thought that you don’t get what you expect, you get what you inspect, on that basis reporting and dashboards are your best friend.

I’m not going to explain how to write reports as there’s plenty of information online. Please remember when creating dashboard components you need a summary report to provide the data for the component – tabular reports don’t work. You’ll also need to provide totals on the report columns for the dashboard. A few reports with enough data can provide enough data for multiple dashboard components – you don’t need a separate report for each dashboard, one report can support many components.

Material on creating dashboards https://help.salesforce.com/articleView?id=dashboards_create.htm&type=0

☏ 01494 590428 | ✉ hello@commerceworks.net