URL Hack Functionality In Lightning?!

Posted August 2, 2018

In APEX, Visualforce, Lightning Components, Automation, Blog, Flow, Salesforce Lightning

URL Hack Functionality In Lightning?!

First, sorry for the click bait like blog title. Second, sorry to Shannon Hale who I’m sure still cries everytime someone uses a URL Hack.

Now a history lesson. For you young and hip kids who have never known anything besides Lightning Experience, you likely have no idea what I mean by a URL Hack. But back in my day (hitches up pants past his belly button) in Salesforce Classic you add information in the URL and change or augment the behavior of Salesforce. Common examples of URL Hacks were Creating a Contact Role at the Same time as Creating an Opportunity, Automatically selecting the To and email template when sending an email, and the classic – opening a new record page while pre-filling values.

An example of the last one would look like this: https://na14.salesforce.com/001/e?retURL=%2F001%2Fo This is the standard classic URL for creating a new account. Looking at the HTML source of the code, I can find the name of a field, say Number of Employees and add it to the URL as a parameter. Adding &acc15=35 would pre-fill the number 35 in the Employee Number field. So thus our URL became https://na14.salesforce.com/001/e?retURL=%2F001%2Fo&acc15=35

Place this URL on a custom button and perhaps use some merge fields and you have a dynamic way to pre-fill data. This is a URL hack because we are taking the URL of Salesforce and “hacking” it to change the behavior.

Cool right? Well the problem young wippersnapper was URL hacks were never officially supported. Plus the use hard-coded HTML values. Did you just go from NA14 to NA44? Guess what? All your URL Hacks are likely broken. Did you just create a new object and URL Hacks on sandbox? Guess what? You have to update those hacks because the Name/IDs have changed. When Salesforce rolled out Lightning Experience, it prevented almost all URL hacks from working. The only support URL hack is dynamically setting a filter value on a report via the URL – and that only works on the browser and not the mobile environment.

Salesforce attempted to replace URL Hacks with quick actions. And in some circumstances, these are a great alternative. There’s something to be said to having the user go to the normal edit or create page and seeing the full page layout. With actions you have to specify the page layout and it doesn’t support sections. It’s impossible to make the pages look identical. It’s also a lot of upkeep since you have to update the page layout plus the action layout everytime you add or remove a field. Speed and response time is also an issue on actions with lots of fields. Got a big page layout and want to duplicate as an action? Be prepared for some slowness.

Actions could really only replicate the create URL Hacks. All the other URL Hacks couldn’t be addressed. It also was a poor substitute for needing a full-page layout when creating or editing. Finally, there’s one scenario where these quicks actions simply cannot handle, that URL Hacks DID handle, and where my little solution replicates with a bit more effort.

The Setup

I was using a custom object for my real-world scenario, but for universal comparison, let’s use Cases. In our world, we use tasks to remind users to create follow up Cases. How do I handle this without a URL Hack or other helpful shortcuts?

As a user, I click on the “related to” of the Task to go to the Account.
next I have to use the New Case or New Case Action to create the Case.
I enter the Contact – which was on the Task for the Case and fill out other fields which – some which values are on the Contact or the Account
Then I click save

Ick, what a crappy user experience. It’s only 4 steps, but come on. FOUR Steps! I’m too busy doing whatever I’m supposed to be doing in my job to deal with FOUR steps! We could use an action on the Account to create the case and populate some of the fields from the Account, but it wouldn’t be able to do that with the Contact. Plus, we wouldn’t get to the same layout if we use an Action. Other options include creating the case via automation and then having the user edit it – bleh. We could use Flow to query the information from the account and contact and then display a screen to capture the rest of the information or just create the case and have the user edit it afterwards. Again, Bleh I tell you!

Here’s my solution:

Click a button on the Task
Go to the new Case field with Account & Contact values filled in. I only have to add other items
Save

Boom! I saved ONE whole step! I know you’re laughing at me. That’s only one step! Well depending on how many fields you have to fill in based on values on the Account and Contact, I just saved a lot of data entry. Plus, the user is taken to the full new case page layout. If I add or remove fields, I don’t need to update anything else.

It looks and feels very much like a URL Hack in Classic. So how do I replicate this URL Hack Functionality In Lightning?

Building a URL Hack Functionality In Lightning

To accomplish the wonderful feat, we need 3 things:

An Action that calls a Flow
The Flow for said Action
A Custom Lightning Component

Wait, wait wait! Don’t leave! I know I said Lightning Component and everyone starts thinking “Oh that’s code, that doesn’t count.” Here’s the thing, this Lightning Component requires NO Apex code. You can easily copy and paste the examples I’ll provide and alter them and it’ll work! You just need to have My Domain enabled to use it. Plus, you can use this same Lightning Component to create other “Hack” buttons using the same object (more on that later).

Let’s take these piecces one at a time.

The Action

Using an Action to call a Flow is one of my favorite Winter ’18 Feature . This is how we’re going to call our Flow and thus our Lightning Component from the Task. Creating these actions are very simple.

Go to Object Manager in Setup and select Task
Select Buttons, Links, and Actions
Click “New Action” button
Select “Flow” as the Action Type
Select your Flow
Provide a name
Save and add to the page layout

That’s it! So darn simple.

The Flow

Here’s the second key component with this solution. Technically speaking, the Flow really only needs to call the Lightning Component. Let’s not do that because we want to make this really cool, right?

So in this example, the Flow will be fairly simple. Here’s the list of the elements in the order they “Flow.”

Lookup Task: Fast Lookup to get the task. My lookup criteria is Id equal recordId. recordId is a flow variable and is where the Task ID gets stored when the user clicks on the Action
Decision WhatId Object: This is a Decision Element that checks that the WhatId of the task (also known as related to) is indeed an Account. This is important since if the Task is related to an Opportunity and someone clicks to create the action, I need different elements to query for the data I need for my case. I would have a path for each object you WANT the users to create the case from.
Lookup Account: Fast Lookup to get the Account and the fields I want from the Account
Lookup Contact; Fast Lookup to get the Contact and the fields I want from the Contact
Create Case: Lightning Component where we pass the values from Account, Contact, and anything else as attributes.

That’s it. It’s not a difficult Flow. You should have fault elements for the Fast Lookups and have an error handling screen for your Decision. I didn’t do that to keep the screenshot small. I would strongly recommend using your default outcome for the Decision element to handle scenarios when a user clicks the action and the WhatId isn’t any of the preferred objects. This way you can provide a screen to your user that states there was an error and when you want them to use the Flow.

Simple Flow for URL Hack in Lightning

The Lightning Component

The Lightning Component involves NO Apex code. Which means anyone should be able to do this.

I used the Developer Console to create this Lightning Component.

Open up the developer console, click the file menu and hover over New and then select Lightning Component.

There are 3 parts this this Lightning Component. The Component, Design, and Controller. You can select these items from the menu on the right side of developer console.

Lightning Component in Developer Console

The Component

There’s a couple of important bits in the component. The first is what is “implements.” This controls where this component can be referenced. There’s a whole list in the documentation. In this situation, we’re using just the implement to make it available as a Flow Action.

The second important bit are the attributes. The official description is “describes an attribute available on the app, interface, component, or event.” Not all that helpful to non-developers. Think of these attributes as names for data you’re going to use in the component. In this example, I’m using just string for text values. There are a bunch of other types including Date, Decimal, and Boolean.

For my example, I chose attributes for the fields I’m going to pre-fill on the Case. I chose to use “Input*FieldName*” to keep it simple, but you can name it whatever you want. Just remember that the name will be the same in the design and will be what will show up in the Flow.

<aura:component implements="lightning:availableForFlowActions">
  <aura:attribute name="InputContactID" type="String" />
  <aura:attribute name="InputAccountID" type="String" />
  <aura:attribute name="InputType" type="String" />
  <aura:attribute name="InputOrigin" type="String" />
  <aura:attribute name="InputReason" type="String" />
  <aura:attribute name="InputSubject" type="String" /> 
</aura:component>

The Design

Design Attributes are similar to the attributes in the component. They need to be spelled the same and with the same capitalization as the Component attributes. In the design, the attributes listed are what will be exposed to tools like the App Builder or in our example Flow. Since I’m using my Attributes to set the data I want to pre-fill on the form, I’m again using the field names.

<design:component>
  <design:attribute name="InputContactID" />
  <design:attribute name="InputAccountID" />
  <design:attribute name="InputType" />
  <design:attribute name="InputOrigin" />
  <design:attribute name="InputReason" />
  <design:attribute name="InputSubject" />
</design:component>

The Controller

Finally, the Controller. This is the bit that some people may go cross-eyes and get confused. The Controller controls what the component does. I’m going to break this down into sections.

Get the values passed into the component
Define what action the component will do
Set the parameters for the action
Fire

The first part is where you see all the “var name = component.get(“v.InputContactId”)”; This is a variable in the controller. It can be named whatever you want. The key part is component.get. This tells the controller with Attribute you want to get from the component. The format is v.AttributeName. You’ll notice in my example I choose to name my controller variable to be the Attribute name without “Input.”

The second part defines the actions. This is the variable I call “createRecordEvent.” In this scenario I want to take the user to the create record page so I’m setting it as “$A.get(“e.force:createRecord”)” The developer documentation has what other actions you can perform.

The third part is setting the parameters for the action. So if our action is creating a record, we need to tell the component the type of record we’re creating, the record type id, if applicable, and the values for the fields. entityApiName is the object for the record. This could be “Account”, “Contact”, or for custom objects “MyCustomObjectName__c”. Next are the fields and their values. You can see in the sample the API name of the field in single quotes, followed by a colon, and ending with the variable holding the value. You don’t have to use the variable here. If the field value will always be the same you can skip the attribute for the field and simply do ‘fieldname__c’ : “Value”.

Finally, we “fire” the action” This is an important line. Everything that we’ve done so far is simply setting things up. Without firing, the create action will not occur.

That’s it for the Lightning Component!

({
 invoke : function(component, event, helper){
   var ContactID = component.get("v.InputContactID"); 
   var AccountID = component.get("v.InputAccountID"); 
   var Type = component.get("v.InputType"); 
   var Origin = component.get("v.InputOrigin"); 
   var Reason = component.get("v.InputReason"); 
   var Subject = component.get("v.InputSubject"); 

   var createRecordEvent = $A.get("e.force:createRecord");

   createRecordEvent.setParams({ 
     "entityApiName": "Case", 
     "defaultFieldValues": {
      'ContactId' : ContactID,
       'AccountId': AccountID,
       'Type': Type,
       'Origin': Origin,
       'Reason':Reason,
       'Subject':Subject
    } 
  });
  createRecordEvent.fire(); 
 }
})

Wrap up and Conclusion

There we go! Three simple items to re-create URL Hack functionality in Lightning.

Is it as simple as a URL Hack?

I think that’s up for debate. It’s more than a URL, so in that respect it’s not as simple. However, with this method there’s no trolling through HTML to find field names on the form and there’s no concern about IDs/Names changing from Instant changes or moving from Sandbox to Production. In the sense it’s is simpler.

Is there a way to do this better? Can I make it more re-usable?

Probably. But I can’t think of a way to do it now. My first attempt at this component was to make it 100% re-usable. The challenge is that Lightning Components that implement availableforFlowActions only accept certain types of attributes. If I could pass in a map or even reliably parse a string of a map or json, we could make a completely re-usable component. The part that is NOT re-useable are setting the Object (entityApiName) and the Field Values (defaultFieldVales). We could pass an attribute to pass in the object, but not to pass in the fields/values.

The only way I can think of making it a bit more reusable is putting a set cap on the number of fields. I could then have attributes like “Field1Name”, “Field1Value”, “Field2Name”,”Field2Value” and so on. But that just looks so messy. Instead I opted to create one for each object.

I still would like to make it more flexible, so please go vote on this idea: Allow non-string attribute types like Map and Object for Flow Local Actions

Finally

I hope you find this helpful and useful. Let me know how will you use this “URL Hack” in Lightning in the comments. I also love to see what other URL Hack functionality you would like to be able to do in Lightning, so please add those in the comments.

Finally, if you’re a Flownatic myself, check out our T-Shirts at our new store. Purchases help support paying for the services to host the blog and podcast. We’re an affiliate so purchasing other people’s designs after clicking our link helps us too.

Thanks for Reading.

P.S. Want to have fun with me being silly with a greenscreen behind me? You can grab a gif of Shock Wizard Here:

https://wizardapprentice-dev-ed.my.salesforce.com/sfc/p/j0000000KIxy/a/0a000000cwQp/JX9vr25r_1YBIDwQp5Df4rbLEwDXy61keI6eTAC1Fsg

URL Hack Functionality In Lightning

Addendum: Doug Ayers took this idea and went completely Lightning Component. No Flow included (what’s the fun in that?) Check out his Lightning Component URL Hack which includes a git hub for you to grab the code yourself!

I’ve tried this out and it does work. The only issue I’ve experienced are when users go “Back” using the browser button or through a “back” button in the component. When you are using this lightning component for multiple buttons on the same layout, the system doesn’t seem to “refresh” between button clicks when the user uses button 1, cancels or goes back and clicks button 2. Beyond that, it works really well.

Don’t miss a post! Sign up to receive email notications.

I run this site, the podcast, and my training videos for the community. I do incur some costs. I greatly appreciate if you can help me out by checking out my affiliates and – if you shop amazon – start your search on my site.

Brian Kwong

Has been Administrating and Developing on the Salesforce.com platform since 2007. Brian was made a Salesforce MVP in Winter '13 and is co-leader of the Wisconsin Salesforce User & developer group. http://wisconsin.salesforceusergroups.com He's known to occasionally walk around with a Wizard's hat on his head - particularly during trainings, user group meetings and Dreamforce. Just what is with the hat? https://thewizardnews.com/2015/02/26/the-story-of-the-hat/