Salesforce Record Access

Overview

First of all, just wanted to clarify I’m not going to discuss how Salesforce handles security on their end, but rather how you as an admin can configure it in your org.  I would again like to remind you that I highly recommend nailing down the fundamentals of being a Salesforce administrator first regardless of which path you ultimately end up taking.  Salesforce security is so fundamental and universal, it is something that I ask interview applicants for admin positions about 100% of the time.  I should also note that while it’s probably alright to not remember every single different possible way a user could gain access to a record in an interview, demonstrating that you don’t understand the way that security works will always be a red flag for me.

“Security and Access” covers about 15% of the Salesforce Administrator certification exam and “User Setup” covers another 9%.  If you can master your understanding of how and why someone would or wouldn’t have access to a specific record in Salesforce, you’ll be ¼ of the way to being ready for your certification!

Every Job You’ll Ever Have

Every job you’ll ever have, in some capacity or another, will have an element of security to it.  There will be someone or something that you need to protect.  When working in technology, more often than not, the most important asset your company will have, is its data.  This means that you, as the Salesforce admin, will most likely be the keeper of your org’s keys.

Key

For that reason, it is imperative that you learn how to use them in the best way possible!  Salesforce has an easy to remember URL for their series of videos on this topic: sforce.co/WhoSeesWhat!  I’m going to summarize at a high level what the different pieces are but I highly recommend going through the links, Trailhead modules, and gain some experience to capture all the finer points.  I’m continuously learning new things about it all the time!

Profiles

The most basic level of access starts at the profile.  Users can only be assigned one profile so it is very helpful when choosing how to create your profiles, to choose names that capture the type of user they will be.  Profiles contain a TON of different settings.  There are so many, that Adam Torman once rolled out the complete list over 40 feet long down the side of a building:

Profile

The basic things you need to know are that these permissions contain the most basic Object, Field, and System level access for your org.  Nothing in Salesforce can restrict access to a user if their profile explicitly grants it.  The Object permissions are often referred to as CRUD permissions.  While this is an odd sounding name (and still amuses me every time I hear it) CRUD is simply an acronym for Create Read Update Delete.  This means you can grant or deny these 4 permissions for all objects.  There are also special permissions on objects such as “View All” and “Modify All” which override all other permissions in the system to give a user in that profile full access to all records of an object regardless of ownership.

Field level permissions on the same page as the Object permissions are set and can be marked as either Visible (allowing editing if the field is editable), Read Only (which includes the visibility permission by default), or left blank (which gives no access).

System permissions include things such as “Lightning Experience User”, “View All Data”, “Modify All Data”, etc can be set here as well and dictate the behavior that a user will have at an organizational level, beyond specific object permissions.  These will generally be specified on Salesforce Help pages if a certain permission is required to complete a specific action.

Access to Apex classes, Visualforce pages, tabs, apps, and other metadata can be set here as well.  Users MUST be assigned a profile and profiles are tied to license types.  It is also important to note that Standard profiles can’t be modified and are updated automatically with new releases.  They can be cloned to quicken the process of creating custom profiles though.

Organization-Wide Defaults (OWD)

Record ownership is key in Salesforce and by default users will have full access to a record that he or she owns.  What about the records of an object that a user DOESN’T own though?  This is where Organization-Wide Defaults (commonly known as OWDs) kick in.  With a couple exceptions, OWDs on an object can be set to one of 3 options:

  1. Read/Write – gives all users Edit access by default
  2. Read Only – gives all users Read access by default
  3. Private – gives all users No access by default

These settings will depend on you asking yourself a few questions such as “What is the minimum level of access someone needs to a record they don’t own?” and “Is there any reason someone would have to access a record that they don’t own?”  As I mentioned, there are some exceptions to this for specific objects but for the most part it will be one of those 3.  These can be set in Salesforce Classic by navigating to Setup -> Administration -> Security Controls -> Sharing Settings or Setup -> Security -> Sharing Settings in Lightning Experience (or simply searching for Sharing Settings in either search bar).

Permission Sets

A common issue when determining access is generally along the lines of “Well, if I give 10 users the same profile, what if 2 of them need slightly different permissions?” or “What if I need to give 2 users additional permissions for a few weeks, but then want them to go back to normal?”  Fortunately, rather than causing you to go through the 40 feet of a building process of creating a brand new profile, Salesforce has thought of this!  While a user can only have 1 profile at a time, they can have many profile extensions, known in the Salesforce world as Permission Sets.  A permission set is just that, a specific set of permissions.  This can range from Object specific permissions, to field specific permissions, to app specific permissions, to system specific permissions.  

Generally it is a best practice to have a specific use case in mind for a perm set and name it accordingly, such as “Convert Leads”, “View All Account Data”, or “Destroy Deathstar App”.  You can quickly swap out and assign permission sets to users to give them elevated privileges either temporarily or permanently.  You can also use these on users of different profiles in case specific individuals from different departments need to access an app, or a tab, or pretty much anything!

Roles Control Records

Probably one of the most important, and simple, statements that I keep in mind from learning Salesforce was something I was taught in a training video once: Roles control records.  This short, sweet, and alliteration friendly, statement refers to the last major component of basic Salesforce visibility, the Role Hierarchy.  Similar to profiles, users are limited to only 1 role.  Unlike profiles however, roles control ability to access records in an org.  Since managers often have reasons to be able to see records of their direct reports, Salesforce has made this easily doable by allowing the admins to assign roles to users that correspond to what the organization’s visibility looks like.  While I would highly recommend (from experience) against overcomplicating the hierarchy, it is possible to have up to 1000 roles.

Sharing Rules

If you have a more complicated security model you’d like to implement, Salesforce allows you to do this as well in the form of sharing rules!  You can implement rules that share records based on specific criteria to various roles, roles with their subordinates, or public groups.  These can be configured on an object-by-object basis.

security-access

Team Sharing

The next type of object sharing is of the “Team” variety.  Users can be added to Account or Opportunity teams in different roles on specific records and get additional Read or Edit access without having a relationship to the record owner.  These teams can also be saved in a user’s settings and be re-applied to help the owner work on selling to specific customers on an automated basis.

Manual Sharing

Sometimes there are one off cases where a user needs to share a record with someone else.  Maybe they’re going on vacation or maybe just need a little push from someone on a different team.  This is where manual sharing comes into place!  Users can manually share individual records at their own discretion.  In order to share a record, you must be the owner, above the owner in a role hierarchy, or an administrator.

Apex Sharing

Yet another option for sharing records is by configuring Apex sharing.  I haven’t personally done too much of this but the general idea is that you can create “share” records for any object through code that allow you to extend access of specific objects based on criteria that your developers (or maybe you someday!) define.

Wrap Up

Wow. With all these options for sharing records, there’s no end to the amount of customization you can give to your security model!  Each one depends on your company’s unique requirements.  If you’re ever in doubt about who has access to a particular record, Salesforce has you covered there as well!  By clicking the “Sharing” button on the top of the record (available if the OWD is set to anything other than Public Read/Write), you can see everyone who has access to the record, what their access is, and even click on “Why?” to see the reason behind why that particular user has access.

Screen Shot 2016-05-28 at 6.56.33 PM

Screen Shot 2016-03-16 at 7.55.05 PM

Hopefully that’s enough to get you started (and pass an interview with me) but just in case it isn’t, feel free to check out the helpful links and the Trailhead modules as a result!  Congrats! You’re on your way to becoming a Salesforce admin!

Relevant Trailhead Modules

Certification Items to Focus On

Security and Access from the Certified Administrator Study Guide:

  • Explain the various organization security options
  • Describe the features and capabilities of the Salesforce sharing model
  • Given a scenario, apply the appropriate security controls
  • Describe the various settings and permissions a profile controls
  • Given a scenario, determine the appropriate use of a custom profile

User Setup from the Certified Administrator Study Guide:

  • Identify the steps to setup up and/or maintain a user
  • Given a scenario, troubleshoot common user access and visibility issues

Additional Resources

Sharing Tips: http://resources.docs.salesforce.com/198/14/en-us/sfdc/pdf/salesforce_sharing_cheatsheet.pdf

More Info on Ownership: https://developer.salesforce.com/blogs/engineering/2013/10/behind-the-scenes-of-record-ownership-in-salesforce.html

Adding and Managing Users: https://help.salesforce.com/HTViewQuickStarts?id=000120152

Salesforce On Security: sforce.co/WhoSeesWhat

Profiles and Permission Set Auditing: http://www.salesforcehacker.com/2013/10/visualizing-users-permissions-across.html

Admin Hero on Security: http://www.adminhero.com/salesforce-security-part-1-record-access/

Manual Sharing: https://help.salesforce.com/apex/HTViewHelpDoc?id=granting_access_to_records.htm&language=en

Building Even More with Salesforce

Happy New Year!.  I wanted to expand a little bit on my last post and introduce a few other basic admin tools to round out the Standard and Custom objects portion of the Certified Admin exam, compromising 18% according to the rubric.  I also wanted to share my new Journey Progress page and encourage you to start your own if you haven’t already!

More on Lookups

Last time we introduced the unique concept of creating a field on an object that links that object record to another object record, such as a Contact to the Account that it corresponds to.  By connecting 2 objects together, you can create complex automations and gather additional data on parent objects when its child objects get updated.  Creating a lookup relationship creates what is called a One-To-Many relationship meaning that there will be one single parent object and potentially many child objects.  The child object record will have a single field that will be a hyperlink to the parent record and the parent object record will have what’s called a related list on the bottom of the record page that will show all of the associated child records.  

Use Master-detail lookup relationships when you want the child objects to depend on the parent objects.  For example, if you had a custom object called Jedi Knight and a related object called Lightsaber, you may want a Jedi’s lightsabers to also be deleted if the Jedi record is deleted.  You could also have a roll-up summary field to count the total lightsabers a specific Jedi owned*.  The detail object record will inherit all security and visibility from its master record.

If you had another object called Vehicle, you probably would want to assign the Vehicle a new Pilot if something happened to the original one.  A standard lookup relationship would be best here to relate the two objects but not make them dependent on each other.  This allows you to have a variety of vehicles and pilots that you can swap out as necessary.  It may be possible that better pilots could be driving multiple vehicles but chances are vehicles should only have one primary pilot.

Sometimes it’s necessary to create a many-to-many relationship, for example if I was setting up a college course signup app, I might have a custom object called Student__c that would be enrolled in multiple Course__c objects.  In turn, each course would have multiple student objects associated with it.  In order to set up a relationship such as this, we can use what is called a “Junction object”.  We could create an additional object, such as Course_Slot__c that would have a lookup field, and a One-To-Many relationship, to both the Student and Course objects and would represent one student signing up for one course.  We could then adjust our Course Slot related lists on both the Student and Course objects so we could see a student’s complete schedule and a course’s full roster by looking at their specific records.

*You can also create a one-to-one (1:1) relationship using a hack with roll-up summary fields and validation rules outlined here: http://one-to-one-salesforce.blogspot.in/

Chained Dot Notation

In the last post, we also introduced the concept of “Dot notation” where I can say Wand__c.Wizard__c and be referencing a Wand’s corresponding Wizard lookup field.  But what if I wanted to know what Hogwarts house the Wizard was in without having to click on the Wizard to find it?  If I was looking at the wizard, I could look at the Wizard__c.House__c field and that would tell me!  Wouldn’t it be pretty cool if I could ask a wand which house its wizard was in though?  Fortunately, Salesforce let’s us do this!  We just have to let Salesforce know we want to ask a wand about its related record.  Because it’s a related object though, we’ll use slightly different notation, namely “__r” instead of “__c”.  We can say Wand__c.Wizard__r.House__c to ask about the Wand’s Wizard’s House from the Wand record!

CustomFields

Generally you can have Salesforce figure this out for you by inserting merge fields such as in the screenshot above but it’s definitely good notation to know, and even better to know that we can do it!  You’ll most often see this in formulas, validation rules, and email templates, and as with most things, you can also do it in code.  You can also create a chain of objects up to several lookup levels deep!  As with electronics though, it can get messy, not to mention dangerous, if you go down too many levels so Salesforce has a depth limit of 5 levels in place (3 for master-detail).

Wires

Schema Builder

A good way to view all the relationships between your objects is by using the Schema Builder.  The example below shows that the Account object has a One-To-Many relationship to the Case, Opportunity, and Contact objects, Contact has a One-To-Many relationship to the Case Object, and the Lead object is not connected to the other objects via lookup.  You can also create fields from here but I generally prefer going through the UI instead.

SchemaBuilder

Record Types and Page Layouts

While it is great to be able to create a great data model full of standard and custom objects and fields, it is likely that you’ll have different types of records for each object and different users are probably going to need to see different fields.  For example, you may have a bunch of different droids represented as Contacts.  Some will be protocol droids such as C-3PO, some will be astromech droids such as BB8 or R2-D2, and some will be medical droids.  All of these would be classified as contact records but are going to have very different relevant fields.  

Is there really a point in an astromech droid having a field called Languages_Spoken__c or a protocol droid having a field called Medical_Skill_Level__c?  Most likely not.  The Contact object will need to have both of these fields though.  This is where the concept of Record Types come in, so you can quickly figure out how many of each type of droid, or Contact you have.  You may also allow certain users to only be able to create certain types of new droids.

You might also have different employees that need to see different fields of the same type of record.  For example, you probably won’t want a Sith in your organization, or any one else in the Dark Side department, to know the value of Home_Planet__c on the protocol droid Contact record type but they still may need to know about its existence for reporting purposes.  You can create separate page layouts for various users and assign them to record types and user profiles so you can determine exactly which fields each type of user should see for each record.  

Note that fields are added to Page Layouts, Page Layouts are assigned to Record Types and associated with Profiles.  You can’t add fields directly to record types and you can’t restrict visibility of Page Layouts directly to users.  The combination of record types, page layouts, and field level security (more on this next time) together will dictate exactly what each user will see when viewing a specific record.  

List Views

Between objects, fields, records, and record types, there’s a lot of potential data to be viewed at once.  Fortunately, Salesforce lets us filter what records we want to see in what are called List Views.  List Views allow you not only to filter which records you see at any given time, but also which fields show up on each particular view.  Sometimes it’s useful to only see records that you own, sometimes all records for a given time period, sometimes sorted by record type, or sometimes by a filter of your choice!  You can also choose if you want the current view to be visible just to you or to your entire org as an admin.  You can also allow end users to create their own list views so they can filter however they like as well.  With Lightning Experience, you can also add cool charts to your list views for quick data analysis!

Wrap Up

A lot of info to cover but hopefully you have a better understanding of how to start building on the platform and customizing a little bit more using both the built in functionality of the standard objects and some custom objects that are built specifically to support your org.  To get a little hands on practice, feel free to check out a few of the Trailhead modules listed below and the additional resources for some more information.  After you finish the modules, feel free to add yourself to the Trailhead leaderboard!

 

Relevant Trailhead Modules

 

Certification Items to Focus On

Standard and Custom Objects from the Certified Administrator Study Guide:

  • Explain how to create, delete, and customize fields, page layouts, and list views for custom and standard objects
  • Given a scenario, determine the appropriate fields and page layouts for custom and standard objects
  • Explain how to create, delete, and customize record types for custom and standard objects
  • Given a scenario, determine the appropriate record types and business processes for custom and standard objects
  • Explain the implications of deleting fields: https://help.salesforce.com/apex/HTViewHelpDoc?id=deleting_fields.htm&language=en

 

Additional Resources

Object relationships: https://help.salesforce.com/HTViewHelpDoc?id=relationships_considerations.htm&language=en_US

Roll-Up Summary Fields: https://help.salesforce.com/apex/HTViewHelpDoc?id=fields_about_roll_up_summary_fields.htm&language=en

Junction objects: https://help.salesforce.com/HTViewHelpDoc?id=relationships_manytomany.htm

 

Salesforce Career Paths

Fork in the Road

Now that you know a little about me and a little bit about how awesome Salesforce is, it’s time to discuss a different topic, why did I choose it as a career path (and why you should too!).  While Salesforce is a diverse platform and it is becoming increasingly more difficult to know everything about everything (even certified architects don’t know everything), it does help to have an end goal in mind with regards to where you’d like your career to take you.  Dreamforce, Salesforce’s annual conference, has a place for customers, partners, developers, administrators, salespeople, marketers, executives, and everything in between!  The key is to find your passion and go for it!

Fork in the Road

Chicken or the Egg

When looking for your first Salesforce job, if you’re anything like me and don’t have a ton of experience, you might find it a little intimidating when many positions are looking for at least 2-3 years.  If you do have a little experience, you may run into the issue of employers wanting to see some form of proof that you do in fact know what you’re talking about.  Fortunately, Salesforce has a pretty extensive certification program that is highly recognized across the industry!  Whether you’re new to Salesforce, or a Salesforce vet, it’s always the right time to build your resume and launch yourself further into your Salesforce career.  Certifications were a tremendous boon for me because even though I had limited hands-on experience, by getting trained and getting certified (and learning a ton along the way), I was able to prove that I understood Salesforce well enough to land a great job as a Software Engineer at a rising company in SolarCity.  Since updating my LinkedIn profile to reflect this, I now consistently get messages from recruiters several times a week about potential job offers.  For a taste of the potential that a Salesforce career can take you down, check out this incredible presentation from a self-taught Google engineer, and my personal inspiration David Liu, as well as some top leaders in the Salesforce industry who are on the lookout for talent.  David actually came from a marketing background and much to his own chagrin, used to be a professional email spammer which just goes to show you that no matter where you come from, anyone can learn Salesforce!  With endless opportunities to learn and get certified, there’s no reason why you can’t do both together!

Career Paths

In future posts, I’ll go into some tips I’ve picked up about how to study and achieve some of the certifications but for now I just want to lay out some of the options.  One of the key tenants of Salesforce certifications that isn’t always found among other technical certifications, are the requirements that you stay current.  Salesforce has 3 releases a year where they release usually 100-200 new features and offer maintenance exams to ensure that all of their professionals stay up to date.

Salesforce Administrator

One of the most common paths, and the first one that I would recommend going down, is that of the Salesforce Administrator.  I’ll go into a little bit more about some of what an Administrator does in future posts but for now, think of this person as a superhero who is able to manage the entire Salesforce instance for an organization without writing any code.  Truth be told, there is no one definition as every org is managed slightly different, which makes perfect sense when you think about how every company is managed differently.  Larger orgs sometimes even have an entire team of administrators to take care of their Salesforce instance but there is also a tremendous amount of support out there for the Solo Admins who are managing orgs on their own.  This path contains 2 certifications, the Certified Administrator, and Certified Advanced Administrator.  To get involved on social media with other admins, be sure to follow @salesforceadmns (there’s no ‘i’ in Admin) on Twitter and use the hashtag #AwesomeAdmin!

Awesome Admin

Salesforce Consultant

No matter what path you choose to go down, understanding the power and limitations of being a Salesforce administrator will greatly help you accomplish tasks much quicker on the platform.  Another common path a lot of people choose to go down is that of the Salesforce Consultant.  Generally, people choose to specialize in a particular product such as Sales Cloud, Service Cloud, or Marketing Cloud.  Consultants can span anywhere from independent consulting, to contracting with a specific organization, to working for a consulting firm such as Appirio or Bluewolf.  There are also community launched websites such as CRM Market that allow you to highlight your skills for anyone company looking for some help.  While there is no substitute for experience, your resume and career prospects can be greatly boosted by going after a specialized certification such as Certified Sales Cloud Consultant, Certified Service Cloud Consultant, or a Certified Email or Social Specialist on the Marketing Track.  All of these certifications are independent, although Sales Cloud and Service Cloud require the basic Administrator certification as a prerequisite.

Salesforce App Builder and Salesforce Developer

For those who do like getting a little bit more hands on and building things (such as myself) there is also a certification just for building on the platform, appropriately named Certified Platform App Builder!  Previously known as Force.com Developers, App Builders don’t actually need to know how to write any code, but rather develop using Salesforce’s easy to understand “point-and-click” approach, which is just as it sounds.  What many app builders, and admins for that matter, don’t often realize though, is that while they aren’t directly writing code, they are being exposed to it and indirectly writing it all the time!  As I’ll also discuss in future posts, many of the Salesforce non-coding tools, such as formulas, process builder, workflows, flows, and field API names that non-coders use on an every-day basis provides a great introduction into the world of coding.  

For that reason, the Platform App Builder certification is a great segue into the Platform Developer I and Platform Developer II certifications, which do require the ability to code on the Salesforce platform.  These certifications are a little harder to achieve but from what I’ve heard from recruiters, are definitely worth it (I’m actually going for them soon!).  I’ll highlight these in greater depth in later posts as well, but know for now that those options are out there.  To get involved with this community on Twitter, be sure to follow @SalesforceDevs.

Salesforce Technical Architect

Last but not least, my eventual goal, the coveted Certified Technical Architect certification, of which there are only currently 182 in the world.  This certification is currently undergoing a revamp so not exactly sure what it entails just yet…hopefully we’ll have some fun learning together!  Individuals who hold this certification are considered masters of the platform.  While they may not know EVERYTHING, they’re pretty darn close.  While these are just some guidelines, there are an infinite number of paths that your Salesforce career can take.  I would love to hear about whichever one you choose!

Benefits of Getting Certified

My favorite benefit of getting certified was honestly learning the Salesforce platform!  It’s a lot of fun to dig into and the amount of training material out there is extensive enough for just about anyone to start building their career and proving their worth today!  My next post will actually go in depth about how to do just that!  If you want a sneak peak, it involves trails 🙂

One of the other helpful benefits though, is the ability to make a living off of doing something that can be a lot of fun and is adding 300+ new features every year!  A blog post from Salesforce MVP Ben McCarthy earlier this year outlines some of these sample salaries that the market is currently offering.  A sample of 70+ people from the Denver user group put together by Salesforce MVP Brent Downey also showed that the market will pay very well for Salesforce certifications.  While just a small sample size, hopefully it gives you an idea of how lucrative (and amazingly fun of course) a Salesforce career can be! For the latest info on the certification program, be sure to follow @SalesforceU on Twitter. 

Salesforce Salaries

Conclusion (TLDR)

Salesforce offers an infinite number of paths that you can take on your way to a successful, fun, and lucrative career.  While many choose to go down the Admin, Consultant, Developer, or Architect route, the truth is that even those who identify with one of these, often identify with several (myself included).  It’s also not uncommon to wear many hats and do several of these at the same time!  This year alone, I’ve generally considered myself a developer, while also wearing the hat of an administrator, and doing some consulting work on the side.  This post was a little on the long side and there was a lot of information but hopefully you’re wondering where and how to get started!  I’ll promise you that you can start today and it’s completely free and I’ll go into greater detail on exactly how next time…