It was supposed to be an easy day. We had worked for months with our partner to develop their new groundbreaking Force.com embedded app. The strategy was sound. The market was proven. The app was disruptive in all the right ways. We’d passed security review and created the managed package. The package testing was complete, and we had a minimum viable product (MVP) that was ready for the first beta customer. I spun up the org, installed the package, and went to create the user accounts. Because it’s a Force.com Embedded app, I selected the Salesforce Platform license type for the first account. Wait… ummm…
Where are my custom Profiles?
I’d installed this package and created accounts countless times during testing, but I’d never run into this problem. What had changed this time, other than the fact that I’d promised our partner their first customer’s org would be ready by the end of the day? After a quick check of my test orgs and a couple of frantic Google searches, I realized I was being taught a lesson in practice that I already knew in theory.
Custom profiles are tied to a specific license type.
My profiles started life as clones of the standard profile, with full Salesforce licenses. This org, created for a Force.com Embedded app, had Salesforce Platform licenses, so the accounts could not be assigned my custom profiles. How did this happen? How did we get to this Friday afternoon deadline without being smacked in the face with this basic licensing issue sooner in the project?
Think About the End Before You Begin
As a product developer, one of the great things about Force.com is how easy it is to get started. Whether due to tight timelines or our own excitement to get started, we like to dive right in and build some things. Sure, we follow the SDLC. We follow best practices. But we like to create, so we do. That’s great for tackling risks early, proving our concepts, and showing our partners results that help them refine the product vision. That’s bad if you have not asked the right questions before you begin. One of the first things we did was create a couple of custom profiles. Since we planned to lock those profiles down to some very specific permissions for our custom objects, we wanted to lock them down from Day 1. In our haste, we failed to consider the business model … Force.com embedded. That means Salesforce Platform licenses for end-users, not full Salesforce licenses. Whoops.
Think Hard About Your Test Orgs
Partner developer and test orgs come with more licenses than you usually need, and all the types you can imagine. So we never ran into a blocker by using Salesforce licenses for our dev and test accounts. We were busy squashing bugs and putting the finishing touches on MVP features. We did not consider how our customer orgs were going to be different. They would be spun up as Force.com Embedded orgs, and those only come with one Salesforce license and five Salesforce Platform licenses to start.
How to Avoid Friday Afternoon Excitement?
1. Before you jump in and start building, make sure you know the product model and how that impacts what you have to build. If that sounds basic, it is. Force.com embedded? Configure to use Platform Licenses. Will your app be installed in full Salesforce orgs too? Better have profiles for both license types – and code for both of them – or you could be in for an ugly surprise down the road.
2. When you are approaching MVP, Beta, or whatever late stage milestone you are targeting, make sure your test orgs are accurate reflections of the orgs your customers will be using. Spinning up test orgs from the Partner Portal is easy, but before you bless your package as ready, think hard about whether those orgs are valid tests. If they are not apples to apples with the orgs your customers will use, call your AE and figure out how to get orgs that will be valid test environments.
Our Beta customer org was installed and running before the end of the day. Our partner was ecstatic. Lessons were learned. Happy hour was saved. Caveat lector.