top of page

Platform Users Usage Tips

  • Writer: Michael Kolodner
    Michael Kolodner
  • 6 minutes ago
  • 4 min read
Freebie doing brick work.

Lately we've been talking about Salesforce platform licenses, which are a great way to bring more parts of your organization onto Salesforce without big expense. But I don't want to pretend that the Salesforce admin setting up platform users won't run into some challenges here and there.


Whether you manage your permissions primarily on profiles or have moved into the "future of user access," with almost everything provided by permission set, you'll have to think about platform users slightly differently than full users.


Basic Profile

Right from the get-go, when you go to set up your platform user, you'll find that you can't assign the profiles you've already been using because each user profile is tied to a user license type.

Setup>Users>Profiles, where you can see that each profile has a User License listed.

So whether you're using the Standard User profile, one of the NPSP-installed profiles or a custom profile for your organization, you'll need to use a different one. (You will get a new Standard Platform User profile if you want to use that as a starting point.)

If you try to create a completely new profile, you actually have to start by cloning an existing profile, which also clones the user license of that original. So you're not going to get around this.

The New Profile dialog, which actually says "Clone Profile" even though the button was New Profile.

Basically you're going to have to have a different profile for any users on platform as opposed to full licenses (just listed as "Salesforce"). That's not a big deal, but it does mean you have at least one more thing to manage. And whenever you make a change that is going to affect profiles (like setting default record types or app access) you'll need to make the change for at least two profiles, not just one. (Realistically, your minimum is probably three, since you should have at the very least yourself on System Administrator and everyone else not on System Administrator.)


Basic Permissions

When it comes to assigning the rest of the permissions your users are going to need, I'm going to talk about this for orgs that have moved to put all permissions on permission sets. (A full discussion about moving from profiles to permission sets will be another blog post...someday.) If you're managing permissions still on profiles, then you're already managing your platform user profile differently from your other profiles.


I tend to keep a single baseline permission set that will be assigned to all users. The idea here is that this single permission set grants access to all the apps, objects, fields, and abilities that every user will need to work within the organization. But since platform users can't access Opportunities or Campaigns, a baseline permission set meant for all users is going to have to leave off access to those two objects. (If you tried to assign a permset to platform users that granted access to Opportunities or Campaigns, it would error.) So right off the bat, if you have some platform users you're probably going to need to break out the true baseline permissions and put additional permissions for full users into a second permset.


In addition, don't forget that Platform Starter users are supposed to only access ten custom objects. So keep the object count in mind as you build up the truly baseline permission set.


Other Special Permissions

The other things you'll find, depending on how your baseline permission set was built, is that it might have various special permissions in it that can't be assigned to platform users. I don't have a list handy of what those might be, but various things that might be checked off under System Permissions in the permission set. There are screens and screens worth of items in there.

Permission Set>System Permissions

It's actually kinda' hard to understand what some of them do. And some of them are permissions you can't give to platform users. So when you go to assign your baseline permission set to a platform user, you may find that you have to uncheck something. Maybe it's something that you can tell shouldn't have been granted to users in general, in which case you can just remove it. But this might be another area that forces you to have two baseline permission sets, one for platform users and one for full users.


Access to Cases

Unlike Opportunities and Campaigns, which they can't access at all, platform users can see the Case object. But you may need to jump through some additional hoops to grant them access. (Because: Salesforce.)


I was working with a client recently to reduce their license cost by moving a bunch of their users to platform licenses. When I tried to assign them our basic permission set I got an error that prevented it from being assigned to platform users because it included access to Case. I'll be honest: I had a moment of panic, and started questioning whether our license strategy would work if we couldn't give Case access to a whole department. But I was sure I'd had platform users in other clients with access to Case and the documentation about platform users never mentions a restriction around Case the way it does for Opportunities and Campaigns. Luckily, this blog post showed that you can create a license-type-specific permission set that will allow access to Case for platform users.

Permset for Platform Users

It's one more permission set to manage, but it gets the job done. Annoying.


And I'm almost certain that in other client orgs I haven't had to go to this length to give platform users access to Case. 🤷🏻


Don't wait for the next post! Get them in your In Box.

bottom of page