System Permissions and Data Access Rights in Salesforce.com

Security should be your first thought when implementing or optimizing your Salesforce organization. Security in Salesforce is a five-point control process:
•    Organization Wide Default (OWD) settings for each object
•    Salesforce Role Hierarchy
•    Profile permissions for each object
•    Custom sharing rules (configuration and custom code)
•    View All Data / Modify All Data

Organization Wide Default (OWD) Settings for Each Object

Every object has a baseline permission setting for each object. Taken alone (without the other three sectors above), there are four choices:
•    Private: Records are only viewable and editable by record Owners and System Admins in your org.
•    Public Read: Records are viewable by every Salesforce User in your org.
•    Public Read/Write: Records are viewable and editable by every Salesforce User in your org but only the record Owner or System Admin can transfer the record to another Owner.
•    Public Read/Write/Transfer: Records are viewable, editable and can by transferred to other Users by any User in your Salesforce org.

It’s important to note that the Organization Wide Default settings are the only place in the security controls within Salesforce, where you can limit Users from interacting with data in your objects. Each of the other four security control points only serve to open up access from this OWD setting.

When determining the proper OWD for each of your standard and custom objects in Saleforce, you must ask the following questions for each object:
•    Which users should NOT be able to see this object?
•    Which users should NOT be able to create records in this object?
•    Which users should NOT be able to edit records in this object?
•    Which users should NOT be able to delete records in this object?
•    Which users should NOT be able to delete records in this object?

Once you have the OWD established for each of your settings, there is one item left for you to decide before you leave this security point and move on to the Salesforce Role Hierarchy. You must, on an object by object basis, determine whether you want the role hierarchy to open up data access for this object.
Salesforce Role Hierarchy.

The role hierarchy in Salesforce is not a place for you to replicate your HR hierarchy, to build a complex network of branched job titles that will only serve to confuse your readers as they see the options pollute their reports.

The role hierarchy is simply a functionality that allows you to open up data access and permissions beyond the baseline OWD settings for each object and it impacts a few other functions in the system.

If “Grant Access Using Hierarchies” is checked on the OWD setting for an object, then roles above other roles shall inherit the object access and permissions of those roles beneath them in the hierarchy. This is extremely useful when your business processes require that managers require access to the records of those Users beneath them in the hierarchy, to edit or transfer or other tasks.

While you can make role hierarchies as complicated as you like (I’ve seen some stretch to over 3,800 roles!!!); I would recommend keeping it to below 10 roles and to make them as generic as possible. After you determine how many levels of access you will need, create them and name them Level One, Level Two, etc. and you can rename them after you have the structure nailed down.

Once you have the OWD and role hierarchy set up, it’s time to determine what permissions your Users will need and to build out your Profiles and their permissions.

The profile is the true powerhouse within Salesforce, when it comes to security and permissions. The major responsibilities of the Profile are to:
•    Determine which applications the User can view
•    Determine which tabs the User can view
•    Which Administrative General permissions the User has
•    The CRUD (Create Read Update Delete) permissions for each object
•    Which Page Layouts a User sees
•    The Field-Level Security (FLS) the User has to view and edit fields within each object
•    Which Record Types are available to the User
•    Which Record Types are default for the User within each object
•    The hours and IP ranges each User has to be able to access the system
•    Which Apex classes the User can execute
•    Which Force.com pages the User can access

These above permissions, along with a User’s access to data (determined by the OWD), determine what Users higher above in the role hierarchy can see and do. You can see that each of these security points work in tandem with the others to allow for a complex security structure to be built that will accommodate any business requirement to close down or open up access to data for all Users in the org in almost any situation.

You can set up some pretty intricate sharing rules for each object within the Salesforce UI based on quite a few conditions (owned by, status of, etc.) but there may come a point when you need to grant privileges to specific users based on minute behaviors within the system and then it’s time to call your Developer and get them working on some Apex sharing rules to automagicate your record sharing.

All of this technical talk about security and sharing is very important to get nailed down tightly and tweak constantly when needed. You don’t want to be the company whose data gets exposed because you didn’t take the time to nail this down.

 

PHOTO: Security wire © by lydiashiningbrightly

The Importance of Executive Sponsorship with Salesforce.com

The worst situation I have ever seen in a Salesforce org was due to lack of planning, lack of commitment and a lack of understanding by Senior Management on how the sales process works inside Salesforce.

The first Salesforce org I was an admin inside was an absolute mess composed of the fossils of organic processes built on a “we need this right now” basis which were then paved over with another process that focused on an alternative solution to the previous ones. Management in the sales and marketing departments rarely, if never logged in. The CFO questioned the cost because he had never seen a report, a dashboard, a closed opportunity, or ever heard one good thing from any of the users about the effectiveness of the system. The data was so riddled with duplicates that the Marketing department hired hourly wage interns to hand scrub their campaign lists by manually typing in each name to get the lead/contact Ids for campaign member creation when Demand Tools was an active vendor.

The completed activities were pretty much worthless in terms of exposing the value to the sale as most were dropped in from Outlook on an email by email basis with no status or description as to the value of the interaction with a customer/client. This meant that anyone seeking to find out where the company was with this customer, had to sift through dozens and dozens of emails logged as tasks and make their own determination. Try having the company subpoenaed and having to to print those emails out one by one!

Few sales teams added Contact Roles to Opportunities which meant that the campaign ROI from responses were broken in the system but that was okay because the Marketing department didn’t put the actual costs of their campaigns in there anyway. And worst of all, the whole thing was all pointless. That’s right. My job and the Salesforce org was pointless because the sales teams executed the actual deal closings through emails directly to the contracts fulfillment department and the sales people were reimbursed from another system, again through emails and phone calls, all of which took place completely outside of Salesforce. This means that closed opportunities, while mandated by Sales Management, were an administrative burden to the sales teams, often put into the system weeks after they had closed and did not have the actual in process data that, when enforced and required by validation and workflow, results in that ever valuable analysis of why a deal closed or didn’t.

And no one at the top knew enough about the system to ask the right questions or even interpret my conveyance of the issues intelligently enough to plan out a functional sales process that would have saved them countless hours of analysis and administrative headaches as they constantly rushed around putting questionable numbers together from multiple data sources throughout the company.

The bottom line is that there is a much, much better way to do things and it begins with executive level buy in and commitment to hammering out a solid, no leaks sales process that flows through Salesforce, a process that focuses strongly on data integrity both on the front and back ends, and one that passes information automatically to all parties and systems necessary to get a deal closed and retain all information related to the deal inside the CRM system of record for future analysis and retrieval. Having this executive level commitment is the first step to success and if you don’t have it, you may as well hang up your keyboard and start picking numbers out of the phone book again.

 

PHOTO: Broken glass © by liknes

Ground Rules for Selling with the Salesforce.com Sales Cloud

I have a few rules when it comes to setting up and optimizing the Sales Cloud as new customers and I’m sure I’ll add to these as time goes on.

1. GET EXECUTIVE BUY IN OR GET OUT (click here to read)


2. GET THE SYSTEM PERMISSIONS AND DATA ACCESS RIGHT NAILED DOWN (click here to read)


3. MAP OUT YOUR SALES PROCESS ON PAPER AND GET ALL STAKEHOLDER TO AGREE (click here to read)


4. PLAN YOUR IMPLEMENTATION


5. AUTOMATE EVERYTHING THAT YOU CAN THROUGH CONFIGURATION


6. IDENTIFY CHAMPIONS FROM EACH OF YOUR BUSINESS SEGMENTS


7. GET A GOOD ADMINISTRATION TEAM


8. TRAIN YOUR USERS AND WAIT FOR THEM TO LET YOU TRAIN THEM MORE


9. ASK FOR IDEAS TO IMPROVE FROM YOUR USERS AND CUSTOMERS AND THEN USE THEIR IDEAS TO IMPROVE THE SYSTEM DRIP BY DRIP


10. STOP WHINING AND START CHATTING


11. DOCUMENT EVERYTHING IN COMMON LANGUAGE THAT ANYONE CAN UNDERSTAND

 

Other Salesforce Sales Cloud articles:

• Accounts vs Contacts: Finding Higher Ground in the Salesforce Sales Cloud (click here to read)

 

 

PHOTO: Two clones playing in just one game © by madnzany

How I Passed the Salesforce Certified Sales Cloud Consultant Exam

I successfully passed the Sales Cloud Consultant exam today and it was pretty tough. I used 103 of the 105 minutes allotted but I did the same on all the exams. When I pay $200 out of my own pocket to take an exam, I’m using all the time to check each answer until I feel in my gut that it’ the best answer I have to give.

It took me about 30 minutes to do my first response answers for all 60 questions and I use the pencil and paper given by the administrator to rate my feeling about each answer on a scale of 1 to 3.

• 1 = I am unsure of my answer or the question and want to prioritize these first in the review before submitting


• 2 = Pretty sure of my initial answer but want to review it before submitting


• 3=Dead sure of the answer, no need to re-review before submitting

I memorized the breakdown of my initial answers and 13% (8) were 1s, 65% (39) were 2s and 22% (13) were 3s. Carving out the 3s, I focused on the 1s and found the best answers, then combed through each 2 until I had them all re-reviewed.

Pushing the submit button is the most nerve wracking moment of the whole exam because you know that in 2 seconds your resume and respect in the Salesforce industry is either going to change…or it isn’t. I always put a hand on my gut, close my eyes and ask myself if I have answered every answer to the best of my ability, if I’ve considered every word in every question and whether I’ve employed all my knowledge and experience in every answer.

Then I press the button.

So, my first piece of advice on those taking this exam is to obviously use the study guide. I create a word document and type out each question with a Header 1 font type, starting with the section that is valued the most in the exam. Then, I go through the questions one by one, typing out my study notes, using Salesforce Help, the Developer community and my own experience. The latter is going to be your most valuable asset in this exam. It’s import to keep in mind that this is not a test of how the system works, it’s a test on how you can make the system work for a customer who is giving you specific requirements they want developed or situations they are in and want to get out of. This means not only do you need to know what the system does; you need to know how it works best and then how to apply that knowledge to a client’s pain points.  It’s about being a good consultant.

In other words, it’s a difficult exam to study for and pass. You have to do a lot of reactive thinking and the best reactive thinking comes from the muscle memory of experience—sorry to be a downer for those new to Salesforce Development and Administration who were hoping to walk in and ace the test but if you were able to do that, it would make the achievements of those of us who’ve earned the knowledge through years of mistakes and successes in the system, that much less. My experience with Salesforce is six years of being a user, five years of administration and configuration development and about a year of Apex and Visualforce. I’ve worked in five different systems ranging from 6 users to over 8,000 and I’ve seen a lot of wrong ways and a lot of amazing ways to do things. No matter what your experience level, make sure you use at least 100 minutes of the testing time and give it the best you have.

 

PHOTO: Stretch © by Byron and Tamara

Using Google+, Twitter & Facebook Without Losing Your Mind

Following up on the last post about how I combine LinkedIn, Twitter and Facebook to streamline my communications, imagine how thrilled I was to discover that I no longer have to--well almost.

The Google+ Circles are the perfect way to segment and segregate your communication. Facebook is a pain in the ass to segment out communication, especially since the default is to blast everyone. This means when I get geeky about Salesforce, I get terse comments from my high school English teacher who could care less. Now, with Circles, I have a Salesforce group I associate the post with and only they are the ones to see it and we can get geeked out together without offending the intelligence of my True Blood lovers circle.

But here's what's missing--no API to Twitter, Facebook and LinkedIn, set on a circle by circle basis--yet! It will be so simple to streamline communicating with circles when I can set the broadcast scope within settings for each circle to tie in with other social networks. What this means is that I'll be spending less and less time on Facebook, Twitter and LinkedIn, and more time on Google+.

Throw in an awesome Google+ iPhone app and keep the integrations coming Google. The bottom line is that I don't want to have to choose between Twitter, LinkedIn, Facebook and Google+ and I shouldn't have to. Likewise, it shouldn't be a hassle to streamline communicating on all four platforms (and many more) through one UI that is easy to use and works well with the others.

It's not to much too ask to make communicating online easy and if any organization can do it, it's the big four combined.

 

PHOTO:Blob © by LawPrieR