Salesforce Community with custom objects in a flow

Last year, I wrote about Revisiting the question of build versus buy for web portal solutions, which was greatly inspired by the reduction in solid portal offerings that began about a decade ago. The dearth in offerings is a result of acquisitions by vendors who prefer that portals work only (or, at least, easily) with their own products.

While I’m not a big fan of architectures that lead to vendor lockin, there are situations where the portal is focused on exposing a certain view of a specific application and it is best if that is built by the same vendor as the application itself. Case in point: Salesforce Community Cloud.

Salesforce has been rapidly improving its Community Cloud product with more features and easier management. I believe this is partly fueled by the demise of pure-play portals that can surface Salesforce functionality using the great Salesforce APIs (Liferay being the exception), and partly a smart move to increase Salesforce revenue while reducing customer costs for high API traffic.

Whatever the drivers, I like where it is going. Though, like any technology on a rapid growth curve, there are some bumps along the way. One such bump is puzzling out all the different permissions involved to provide various functionalities. Generally, these bumps are easily overcome thanks to the active SFDC user community. Recently I ran across something that was not so easily solved and thought I would share it here.

The requirement is to create a workflow that ties together the standard Case object with a custom object. The goal is to make the user experience of working with a long form created previously to support the custom object by breaking down the numerous fields into user-friendly chunks that will result in a Case being created along with the custom object as a related object. With the normal amount of “oops” and “darns,” I managed to put together a Visual Work Flow that would take the inputs and create the Case object and then the related custom object.

I then created a Community page in a community using the Lightning Community template Napili and placed a Flow component with the new workflow configured.

The first bump I hit was that the Case failed to be created, which I easily figured out from the various Salesforce user communities was because I was using the wrong ID for the contact (the User ID is different than the Contact ID for community users). Once this was fixed, I found that the custom object was not being created. Back to the trusty community posts, where I found the sage advice to grant access to the object to the profile referenced in the Community Builder Settings. Well, not so sage, because in my haste I forgot that that fields only applies to “guest” users (users not logged in).

To make a very long story short, the default profile granted to customer community users did not have permission to access the object (even though, during creation, I granted necessary access to all profiles) and the default profile is read-only. The fix was to clone the default community user profile, grant that profile the necessary permissions, and then use that profile for my community users. Who then could not log in! Oh, yes, even though everything about the default profile was cloned, the new profile still needed to be granted access to the community using the Community Administration view.

And, finally, the workflow could flow to the end.