Here at CodeScience, we work on a lot of different apps that we develop for our clients to distribute on the AppExchange. One oft-delayed step, even by our own staff, is user persona testing. This results in a late mad dash to define and understand user Profiles when the UAT team belatedly realizes the vast majority of its user base won’t have System Administrator access.
Testing as a System Administrator isn’t telling you the whole story.
Why is this bad? Well, mainly because Sys Admins have access to everything, every page, field, class, and rule. This is fine and dandy for string testing, just making sure that you can get to each page in your custom workflow, but does not a finished product make. Consider it step one. The real solution is something that should be a part of your requirements conversations from the beginning. When we talk about how something should function, we should also be asking:
Who is going to use this feature?
An admin? A manager? A support rep? An over-caffeinated salesperson? Not all users should have the same access to all features equally. It’s not uncommon for an AppExchange app to have at least an Admin and User Profile. Our apps often require a Setup tab, where the installing admin might map custom fields, authorize an OAuth endpoint, or schedule your custom batch jobs to run each night. These are admin-only tasks and Force.com gives us some excellent tools to control different users’ access: Profile Settings and Permission Sets. The Admin Profile usually has Read All and Modify All on our custom objects, just in case that data need to be fixed by someone, and the User Profile will often have just Read access to our objects and data. Because of this, during your Discovery phase, your architects should be identifying and describing user persona at a high level. Then, during the Design phase, the team should be mapping out those persona into the granular permissions, from tabs and VF page access down to the field level, if necessary, and, most importantly, testing against that document later on. If you have a UX designer, that person should also be involved in the Profile design so that the experience is seamless and appropriate for all users.
The Limitations of Profiles in an AppExchange App
Now you may be thinking, silly man, I’ve been using Profiles forever, they’re nothing new. This may be true, but they behave very differently in a package than they do inside a single production org. Here’s the main difference: Your package can contain Profile Settings, not Profiles. it’s a subtle difference, so think about it for a moment. It’s not the Profile, whole hog. It’s just the group of additive settings contained within your app’s custom Profile Settings. Here’s how salesforce.com describes it:
“When you package an app, you can include your custom Profiles. Profile Settings are applied to existing Profiles in the subscriber’s organization on install or upgrade. Only permissions related to new components created as part of the install or upgrade are applied. The security settings associated with standard objects and existing custom objects in an installer’s organization are unaffected.”
This means that after the Admin installs your app, it doesn’t see the custom Profile name alongside all of the ones created. Their only option for using your custom Profile Settings, is to map them onto an existing, custom Profile. In doing so, they are only adding the permissions related to the components in your package. This is done on an oft-skipped page, the Select Security Settings step in the package installation process. After the package has been installed, those Profile Settings are gone. They no longer exist.
Also important to note on this page, even though it lists all standard Profiles and allows the installing admin to map your Profile settings to them, you cannot add Profile Settings to any standard Profiles, period. So this page is misleading at best because when I map the MailChimp Profile Settings to the standard Portal and Platform Profiles in the screenshot above, those permissions will go nowhere. In order to selectively map the custom Profile Settings the installing Admin must have custom Profiles already created, and can then map the Profile Settings to them on this step. Because of this, what we typically do is to create custom Profiles (of the correct license type, mind you) in our test orgs by cloning the correct Profile. We create them with the same names and map the Profile settings to them on install. Then it’s simple to create a test User for each Profile you need to test. When you log in as those test Users, you can always just set the password and grant login access as the admin user. Then, as the Admin, you can quickly log in as any one of them as you work through your testing. How about after installing the app, then? How do I assign those permissions to a new Profile? Manually. Ugh. Even the most minor update to your Profile Settings must be re-created manually by the installing admin. This is because you didn’t actually install a Profile, so there’s nothing to upgrade. Upgrades don’t allow the Admin to add permissions for new components. Need to add a single custom field to your app? The Admin in every org with your package installed needs to add access to every Profile that should see it, including themselves!
Why You Should Also Include Permission Sets
This manual process doesn’t sound like a scalable approach, does it? There’s an answer to that problem in Permission Sets. Permission Sets are salesforce.com’s answer to proliferating Profiles. Typically, a profile had to be cloned and renamed to something awful like “Sales Manager + Greg” because Greg had to have one more permission that the rest of his team doesn’t. With Permission Sets, it can contain as simple as that one permission, let’s say Modify All on Opportunities, and, because they are assigned per-user, can be granted to just Greg, without needing to clone his profile. Here’s how salesforce.com puts it:
“The settings and permissions in permission sets are also found in profiles, but permission sets extend users’ functional access without changing their profiles.”
In addition to being additive, another advantage of Permission Sets is that they are upgradable and protected. Unlike Profiles, which can be modified by the installing admin at any time and potentially break your app, Permission Sets cannot be modified by an admin. So when you add that new, custom field and upgrade your Permission Set, that access is granted to all users with the Permission Set upon upgrading the package version. There are still some limitations with Permission Sets in a managed package. They don’t include page layouts assignments for one. Then, despite the Permission Sets page saying:
“Permission sets include settings for:
Assigned apps
Object settings, which include:
Tab settings”
If you read the Profile Settings page closely, it says that:
“In packages, assigned apps and tab settings aren’t included in permission set components.”
With this in mind, if you need to grant Admins access to your Setup tab, but not everyone else, start with various Profiles for each level of access, such as Admin, Manager, and User. Then create corresponding Permission Sets as well (without tying them to any one license type). Those Permission Sets will drastically reduce future customer support needs, keep your customer admins happy and allow you to spend more energy adding functionality. Also, don’t forget that now you can assign Permission Sets en masse! While this used to be a downside to Permission Sets, it was resolved in last spring. Use the Manage Assignments button on the Permission Set detail page to see a list view of your Users.
Further Reading & Resources
To read more about this topic and other ISV-related stuff, download the ISVforce Guide. It is a great doc that goes through every step of what you need to do in order to build and publish on the Force.com platform, and I refer back to it often. The AppExchange Publishing Guide is a good one as well. My final bit of advice to you is this: Go try it out yourself. Go get a developer edition org and walk through the ISVforce Workbook. Get to know how it works before it’s your production application that’s in a frantic rush to be ready for the next Dreamforce. You’ll be glad you did. In my next blog, I’ll discuss Trialforce and we’ll take a peek at how Profiles and Permission Sets perform in your package on that particular platform.
