Difference Between Profiles, Roles and Permission Sets in Salesforce

A quick guide to the key differences between Profiles, Roles and Permission Sets in the Salesforce security model.


If you are new to Salesforce, or perhaps haven’t worked with the different tools available in the security model for a while, this handy little guide should give you a steer on whether or not you should be considering using Profiles, Roles or Permission Sets as part of your solution.


Once basic access settings have been configured in your Organisation Wide Defaults, Profiles determine a user’s most basic level of access to objects, and therefore users can’t be created in Salesforce without being allocated a Profile. Remember, you can’t use Profiles to revoke access already granted via Organisation Wide Defaults – you  can only grant additional access.

Here is a partial list of what you can control access to using Profiles:

  • Page Layouts
  • Fields
  • Apps
  • Tabs
  • Record Types
  • Admin Permissions (such as being able to manage users or author Apex)
  • General Permissions (such as being able to send emails or convert Leads)

(To see the full list, just log into your Org as a System Administrator and edit a Profile.)


Roles are different to Profiles, and are used to control access to records rather than objects or fields. These are commonly used to implement a Role Hierarchy whereby for example individual sales reps cannot see each other’s opportunity records, but their manager has a view of all their opportunities.

(See this comprehensive post about Salesforce record security for more information on Roles and Role Hierarchy.)

Permission Sets

Permission Sets are more like Profiles, in the sense that they can control the access a user has to specific objects and fields. Remember, you can’t use Permission Sets to revoke access already granted via Organisation Wide Defaults or Profiles – you can only grant additional access.

Here is a partial list of what you can control access to using Permission Sets:

  • Objects & Fields
  • Apps
  • Visualforce Pages
  • External Data Sources

(To see the full list, just log into your Org as a System Administrator and edit a Profile.)

Need more information?

I hope this post has been useful as a quick overview. The security model is a bit more complicated than this and offers even more features such as Sharing Rules, which I haven’t covered here. As always, your first port of call for more information should be the official Salesforce documentation or Trailhead.

Control Who Sees What – Salesforce Help
Data Security – Salesforce Trailhead

Photo by MILKOVÍ on Unsplash

Salesforce Certified Platform App Builder Exam Tips

How to pass your Salesforce Platform App Builder exam.


I finally got around to sitting the Salesforce Certified Platform App Builder exam. I have previously said that the Salesforce Certified Administrator exam was one of the toughest I’ve taken, but I will now add that the App Builder exam comes a close second.

Having the Administrator and Sales Cloud Consultant certs under my belt, together with lots of practical Salesforce implementation experience, I felt confident going into this exam and expected it to be a breeze. I was completely taken by surprise. There was a lot of ground covered, and while the breadth wasn’t as wide as the Administrator exam, the App Builder questions did go into a lot of detail, so you need to have experience and will also need to revise in order to pass.

First step: find your weak spots

As always, the best approach is to start with the official study guide from the Salesforce Certification Website. This study guide contains the familiar exam outline, which breaks down the exam into sections like this one:


It is very important that you look at each of these sections and spend some time honestly trying to work out where your strengths and weaknesses are. Don’t make the mistake of telling yourself you already know this stuff. This is a tricky exam and you will need to put in some study in order to pass it.

As usual, methodically work your way through the exam outline, highlighting sections where your knowledge is limited or perhaps out-of-date. Scoring yourself out of ten for each item is a good strategy, as it will reveal where you need to focus your study/revision. Being totally honest with yourself is crucial!

As with all Salesforce exams, each section is weighted according to its importance, and so the higher weighted sections will have correspondingly more questions in the exam.

Make use of Trailhead

Trailhead is a brilliant learning resource, and we are lucky to have it. There is a complete Trailmix for the App Builder credential, which you can use to improve on your weak areas. Don’t just spend time reading or scrolling through the material – invest some time in doing the exercises too. It will pay off.

Of particular importance are trails that have been updated to cover Lightning Experience. When I did my Administrator exam, Lightning was only just starting to creep into Trailhead, but now it’s everywhere, and lots of content has been revised accordingly. The App Builder exam is very heavy on Lightning, so you will need to know it well.

Many of my questions were around Business Logic and Process Automation, which is understandable considering it’s weighting of 27% in the exam. These questions covered things like Record Types, Roll-up Summary Fields, Approval Processes, Process Builder, Visual Workflow and Workflow Rules/Actions. You absolutely need to know the differences between these.

There were also lots of questions around User Interface, with a particular focus on the Salesforce Mobile App, Quick Actions, and the Lightning App Builder.

Salesforce Connect was an area I wasn’t particularly familiar with, but I’m glad I took the time to study/revise it. It featured quite heavily in the exam I sat, and there were several questions around the types of relationships that apply to external objects.

The capabilities/uses of the different types of sandboxes also featured quite heavily.

Beware of mock exams!

Once again, be very careful about judging your readiness by some of the mock exams that are available. I think this is very important, as some of them will lead you into thinking you’ve got it nailed when in reality you may not quite be there.

There are some good mock exams and some bad ones that include wrong answers! Universally, I have found they are all way too easy. The questions you will face on the actual exam are much more in-depth and will require a lot more thinking through.

So, use mock exams with caution!

Be confident and try to ‘feel’ when you are ready

I don’t know if you’re the same as me, but I get a kind of instinctive feel when I know I’ve done enough study. I suddenly get a surge of confidence and am keen to just sit down and get through the exam as soon as possible.

In order to get there, I make sure I put in the hours of working through the study guide, evaluating my strengths and weaknesses, and focusing my learning where I’m weakest. If you take the same approach, you should pass this exam.

As usual, I had a problem mid-way through, which seems to be traditional for me! The WebAssessor site seemed to go down and I was faced with an HTTP/500 error that wouldn’t go away. If something like this happens to you, don’t panic … just click the little Help icon and wait for someone to come to you. Worst case, they will be able to suspend and immediately reschedule the exam for you, and you can just pick up with the questions where you left off.

I don’t think there’s a lot more I can add here except to wish you luck.

If I can do it, so can you!

Did this post help you prepare?

If these tips helped you prepare for the Salesforce Certified Platform App Builder exam, please share the love by leaving a comment and/or sharing with your Salesforce Ohana!

Photo by Glenn Carstens-Peters on Unsplash

Assign a Lead in Salesforce based on existing Contact Owner

Lead Assignment Rules in Salesforce are useful, but fairly limited. For example, one of the things you can’t do is assign a new Lead to the same owner of an existing Contact in Salesforce.

Why might you want to do this? Well, let’s say your business uses Web-to-Lead functionality where customers/prospects fill in an enquiry form on the website and their enquiry automatically gets created as a new Lead in Salesforce. What happens if that customer has bought from your business before, and dealt with a specific sales person? You might want the customer’s repeat business to be automatically assigned to the same rep.

Lead Assignment Rules don’t allow this kind of Named Account/Contact assignment, even though apparently Salesforce.com themselves operate such a named account policy in their sales organisation.

In the Salesforce Trailblazer Community, lots of people ask how to assign Leads to appropriate Account/Contact owners (as in this post), and there are a few apps in the Salesforce AppExchange that provide the functionality at a price.

Here’s a way to implement a simple version using Process Builder and Visual Workflow. It uses just four elements in a Flow which searches existing Contacts for an email address, and a simple Process that fires when a new Lead is created. This works for existing Contacts, but it would be easy to extend to existing Accounts if you need to.

Create the Flow

The Flow we are going to create uses just four elements: an sObject Variable that contains the Lead that gets passed in from Process Builder, a Record Lookup to search existing Contacts for the Lead’s email address, a Variable to store the found Contact’s OwnerID, and a Record Update to save the Contact’s OwnerID to the Lead.

In this blog post I’ve name the Flow ‘Search Contacts for Email Address’.


Use the Resources Tab in Flow Designer to create an sObject Variable. This will be used by Process Builder to pass the Lead record to the Flow when a new Lead is created.


Use the Resource Tab in Flow Designer to create a Variable. This will be used by the flow to store the OwnerID from an existing Contact.


From the Palette Tab in Flow Designer, drag a new Record Lookup element onto the Canvas. This will be used to search for any existing Contact that has the same email address as the new Lead, and obtain the Contact’s Owner ID. This Element needs to be set as the Start Element in the Flow.


From the Palette Tab in Flow Designer, drag a new Record Update element onto the Canvas. This will be used to save the Contact Owner ID back to the new Lead record.


That’s it in terms of Visual Workflow configuration. Make sure you activate the new Flow so you can see it in Process Builder in the next step.

Create a Process

In Process Builder, create a new Process that starts when a record changes. In this blog post I’ve named the Process ‘Assign Lead Owner’.


Choose the Lead object as the object for which you wish to start the Process, and specify to start the Process only when a record is created.


Define criteria for a new Action Group, and set the condition so that the Action Group is only executed if the Email Address on the new Lead record is not null.


Finally, configure the Action Group to launch the Flow you created earlier in this blog post, and set the Flow sObject Variable ‘NewlyCreatedLead’ to Lead. If you correctly setup the Flow in the previous steps in this blog post (and activated it), everything should be selectable from within Process Builder.


Remember to activate the new Process.

Now, whenever a new Lead record is created in Salesforce, a check will be carried out to see if there is a matching Contact with the same email address. If there is, the new Lead will be assigned to the Owner of the existing Contact. Otherwise, the new Lead will be assigned to the user creating the Lead.

Limitations of this solution

This isn’t a perfect solution. One of the limitations is that the Owner of the original Contact could have moved on, and is no longer an Active User in Salesforce.

Another limitation is the fact that the Lead must have an email address matching an existing contact. A more flexible solution might be to attempt a match a Lead’s Email domain against the Website domain on an Account, which could enable any new Leads for an existing Account to be assigned to the Owner of the Account.

Has this helped you?

I hope this post has been useful. If it has helped you, please share the love with your Salesforce Ohana and leave a comment and/or share this post!

BA (Honours) in Leadership and Management


It’s been a long time since I updated this blog, as I have been busy with lots of other things besides Open University study. However, I wanted to share some news with the thousands of people who have visited and/or continue to visit this blog for information and/or inspiration.

After six years of study I finally got my degree. If I can do it, with all the other things I had going on in my life during that time, then believe me … anyone can do it. I truly mean that. It’s my graduation ceremony this weekend, marking the successful conclusion of my OU journey. (At least for now!)

What next for this blog? Well, I’m considering adding to it on a more regular basis and making it about much more than just academic study. If you look at my About page, you will see this was something I always intended to do. Let’s see if I can finally make that happen!

Good luck with your studies!

Salesforce Process Automation: the difference between Process Builder, Workflow, and Visual Workflow

Always use Process Builder wherever possible.


Salesforce has so many Process Automation options, it can be difficult to decide which one to use. Granted, there is lots of overlap, but there are a few fundamental differences once you get to know them. The best approach to deciding which Process Automation option to use is to ask yourself the following questions:

Do I need to interact with the user?

If the process you are automating relies on interacting with the user (e.g. to obtain input), you will have to use Visual Workflow to do this, as it is the only Process Automation option in Salesforce that supports screens. Easy decision.

Do I need to create a record (other than a Task)?

All three tools can create Tasks, but if you want to create other types of records (including Chatter posts), you will need to use Process Builder, or alternatively Visual Workflow if your process is more complex.

Do I need to delete a record?

Only Visual Workflow will allow you to delete records. No decision to be made here.

Do I need to send an outbound message to an external service?

If you are communicating with an external service (such as an API) and need to send an outbound message from Salesforce in XML format, you will have to use Workflow. None of the other Process Automation tools offer this facility without the need to write supporting Apex code.

Do I need to invoke some Apex code?

If the answer to this question is yes, you will need to use Process Builder or if your process is more complex, Visual Workflow.

The preceding five questions should be enough to put you on the right track in terms of which automation tool you will probably need. However, there are a few finer points that may sway your final decision. See this Trailhead article for some in-depth detail to help you choose.

What you can do with Process Builder

Process Builder should always be your first port of call when looking to automate processes in Salesforce. With Process Builder, you can:

  • Create records
  • Update records related to the one that triggered the process
  • Post to Chatter
  • Send Email Alerts
  • Invoke other Processes
  • Launch Flows
  • Submit records to an Approval Process
  • Call Apex code
  • Use a Quick Action

What you can do with Visual Workflow

Basically, anything you can do with Process Builder you can also do with Visual Workflow – all except invoke Processes. However, with Visual Workflow you can also:

  • Update any record (not just ones related to the record that triggered the Flow)
  • Delete records
  • Send emails (not just email alerts)

What you can do with Workflow

Workflow is a little more limited. With Workflow Actions you can:

  • Create Tasks
  • Update the record that triggered the Workflow Rule (or its parent record)
  • Launch Flows (this is coming soon – a pilot is in progress)
  • Send Email Alerts
  • Send outbound messages in XML format without using code

If you need any more information, Trailhead is your go-to place. There’s an excellent module on Process Automation that will teach you everything you need to know, in the usual fun Trailhead style. Go for it, Trailblazer!

Photo by Alex Knight on Unsplash.