Inspired by Brian Kwong‘s creative blog post on “URL Hacking” with supported features in Lightning Experience using a mix of Flow URLs and Lightning Components, I wanted to see if I could solve the problem he posed at the end about providing a reusable solution.

In Brian’s approach, he cleverly used a flow’s URL in a custom button so that he could have a URL to pass parameters to just like the “URL Hacking” days in Classic experience to open a new record form with pre-populated field values. His flow then used a new feature that allows developers to surface components in flow screens by implementing the lighting:availableForFlowScreens interface. His component then fired the force:recordCreate event to pre-populate a new form with default field values passed in from the flow’s URL. Wowza!

URL >> Flow >> Component >> Record Create Form

One of the challenges with variables in flows is that we are limited on the supported data types. Maps, which in Apex and JavaScript are convenient ways to pass a dynamic number and type of variables, is not supported, so by using flow we need to concretely know the number and type of input variables we can pass to the flow and we need to concretely know the number and type of attributes on the Lightning Component we want to pass those flow variables to. Double whammy here by tightly coupling the flow and component to provide one customizable URL. Not very scalable, which Brian points out at the end of his blog post.

Please vote for these ideas to add support for more data types in flows:

  1. Allow non-string attribute types like Map and Object for Flow Local Actions
  2. Flow: Add a map(key, value) variable
  3. Provide the ability to use Maps in Flows.

Looking for ways to get around the data type limitations of flows, I began thinking of others Salesforce supported ways to create URLs to pass parameters in Lightning Experience. That’s when I remembered a new interface introduced in Summer ’18 lightning:isUrlAddressable. Components that implement this interface are able to be navigated to in Lightning Experience via a URL and they accept an arbitrary number of URL parameters. Bingo!

I started an open source project to build out a proof of concept and I’m quite pleased with how it turned out. I was able to remove the flow from the equation and exclusively use Lightning Components.

URL >> Component >> Record Create Form

contact_url_hack_cmp

However, although I solved one problem (remove data type limitations introduced by using flows), I’ve encountered a new obstacle to the overall user-experience.

By navigating to this lightning component as a URL, you are navigating away from the original page you were on when you clicked the button. The problem with that is there is no way (at the time of this writing) to control what happens when the user clicks the cancel or save buttons in the modal dialog. Meaning, there is no way to return the user back to where they were in my approach. Clicking save will navigate you to the new record, that’s acceptable, but clicking cancel will leave the user on a page that only has the top navigation tabs but no body content. Womp, womp…

record-create-url-cmp-cancel.png

Please vote for these ideas forforce:recordCreateevent to expose callbacks to customize the modal dialog button behavior:

  1. Callback method for force:createRecord event to redirect or refresh after save
  2. Allow redirect after creating a new record using force:createRecord

Update August 7, 2018

Inspired by reader Suraj Pillai, who suggested doing some navigation trickery asynchronously, I added support for loading the current record in the background while the modal to create a new record appears to the user. By the time the user decides they want to cancel the form, the original record they were working with will have loaded as if the user had never navigated away to begin with.

This record loading is optional in my solution. To use it, add the URL parameter recordId and set the value to the current record being viewed. For example, recordId={!Account.Id}. If you do not specify a recordId parameter, then when the user cancels the form, they will see a blank page like the above screen shot.

Here’s using the recordId parameter in action, note that when clicking the cancel button, the user still is contextually on the original record. Win!

cancel_save_button_behavior.gif

If you have any ideas or solutions to improving in Lightning Experience how to use URLs to pre-populate forms in a dynamic and scalable manner, please let me know in the comments below.

Thanks!