Product customizability and Overridable flows: Giving the controls to the customer

 

When developing Salesforce products for the AppExchange, we regularly face requirements where the customer needs to be able to configure (or even modify) the application. With any regular implementation project, the customer is fully in charge of the solution and its delivery, allowing them to change any part of their solution to the requirements.

However, when it comes to product development, it's completely different. The responsibility of developing and configuring the product are with two different parties. Development is done by the party building the app, while configuration is done by the party using the app. For a variety of reasons, the user of an app is not (and should not be) able to modify the core of the app itself. Just try opening a class installed by a managed package in the developer console, and you’ll find that Salesforce automatically hides it. 

Developing an application is limited to what the developer can control. In Salesforce terms this means that the developer can access standard objects, create its own custom objects, create its own classes and interface, etc. However, the developer has no access to any of the customer's components as they simply do not exist in the development scope.

 

For this blog's purposes, let’s imagine that we created an app that processes an opportunity record to create a PDF. We’ve developed the application to work with opportunity records, all known fields on the opportunity, and map that to our PDF. We install it on our own development orgs and run it. Perfect, it works!

 

We distribute our application to our customers and hope they’ll enjoy our easy to use solution! Most do, but a couple of customers report back that they cannot use the application. Some customers use custom fields on their opportunity records, and some even use a completely custom object from which they want to create the PDF. 

 

Could we have foreseen that the customers need to modify the data source? Could we have developed our solution to allow the customer to configure this?

 

What can we do to make sure the customer can use our application, in their own context? Salesforce provides us with a couple of options, some more complex than others. 

 

Putting on our technical cap, the package developer could create a global interface in his application. This interface can be implemented to perform the creation of the pdf for us. The developers can provide a default implementation of the interface, which will work for a standard opportunity record. As the interface is global, the customer also has access to it and is able to create their own custom implementation. The application will then look for the correct implementation of the interface, e.g. by reference in a custom setting or using the triggering sObjectType, and perform the customer's implementation of it.

 

However, this is a very complex solution which requires advanced technical knowledge of coding patterns and the Salesforce platform. Can this be made easier?

 

Salesforce Flows is a visual tool to create automation and is used by almost every customer. They are easy to learn, understand and modify by people who have little or no experience with coding. Flows have been around for quite a while, and as of the winter ‘22 release of Salesforce, developers of managed packages are now able to make a flow overridable.

 

 

Overridable flows are flows distributed in managed packages which are marked to be overridable. This means that a customer can create a copy of the flow, which will then “replace” the original flow. The customer has almost infinite freedom to how they want to modify the flow. They only need to make sure the input and output of the flows are the same. And best of all: this can be done for every type of flow, even screen flows!

 

Overridable flows are a lot like template flows. Previously, a package developer could mark a flow as a template, after which a customer could copy it and create their own implementation of it. The customer would also need to change any references from the template flow to the new flow, which by default cannot be done in managed components. The package developer would then need to create a custom setting, referring which flow to use, adding extra complexity to allow for customization by the customer. Overridable flows bypass these referencing values: calling the original flow will automatically call the overriding flow! 

 

Coming back to our application, we can now create an overridable flow that performs the mapping for us. Our input will be the sObject and recordId of the triggering record. It is important to note that the input variables and output variables cannot be changed when editing an overriding flow. Therefore we have the input as generic as possible so we cover as many customer scenarios as possible. 

 

We implement a default scenario where we take care of creating a PDF for the opportunity. The customer can then create a new flow that overrides our default implementation. The customer decides to add a new path in which the mapping is not done for the opportunity object, but for the Custom_Opportunity__c object, only defined in the customer's environment. The customer then clicks on the ‘create PDF’ button defined in our application, the code runs the overriable flow, but is instead redirected to the overriding flow. The pdf is created, now with the Custom_Opportunity__c values.

 

With the introduction of overridable flows, Salesforce has provided an extremely powerful tool to managed package developers. No longer is the developer required to put effort into making sure the customer can modify their application: this is all taken care of, by checking one simple box. The scenario above is a relatively simple one, but as overriding works for all flow types, the possibilities are almost limitless.