What is Salesforce URL Hacking? I’ve been curious about how Saleforce Objects are setup up in reference to the URL format, and see if users and admins are able to make custom URL “Hacks” that can be quick actions to save time for your users . Some use cases I’ve since developed solutions for are creating and closing records like tasks & cases, easily creating a contact & opportunity with pre-populated fields, or even passing parameters through the URL based on field values of an account to generate custom reports. Before we go into that, I’d like to provide the basics of what URL hacking is and how we can use it in Salesforce.
PLEASE NOTE: URL Hacking is not supported by Salesforce, and the URL format can be subject to change without announcement. Situations like enabling Lightning require you to enable the My Domain feature and possibly instance migrations can affect the URL schema. Salesforce has created Quick Actions you can create in response to this technique. Do this at your risk!
Salesforce URL Hacking Overview
This all started with how most of my understanding of Salesforce functionality starts – a user requests a specific requirement, and I figure out how to solve their need. Unfortunately, I exhausted all of my resources, and turned to Salesforce support. As it turns out, what I was doing was not supported, and couldn’t get additional assistance from them. You can view the response from Salesforce Support below:
I was very curious now, and wanted to explore more about URL hacking, and how I can leverage it to solve specific business requirements from my users. First, we’ll go over the basics of URL hacking:
URL Hacking and Salesforce Objects
First we’ll start off by seeing how the base URL is formed in Salesforce. We have the basic Salesforce url here: http://XXXX.salesforce.com/ , where XXXX is your Instance of Salesforce (server location), or your My Domain (if it had been setup). Typically, anything after the backslash (the ‘/‘) after .com is where the salesforce objects and record IDs live, as well as the HTTP request parameters.
For each record, they are typically 16 digit or 18 digits long after the instance url – so http://na33.salesforce.com/XXXXXXXXXXXXXXXX. The first 3 digits after the backslash will typically represent the object that is referenced.
Here are some of the Salesforce Standard Object types that I’ve found and have access to:
00O (zero zero Oh) = Reports
001 = Accounts
002 = Notes
003 = Contacts
005 = Users
006 = Opportunities
007 = Activity History
00T = Tasks
00U = Calendar
00P = Attached File
00Q = Leads
500 = Cases
501 – Solutions
800 = Contracts
01T = Products
01Z = Dashboards
015 = Documents
701 = Campaigns
a0F = Customer References
a0G = Campaign Groups
0BM = Connections
This list is not comprehensive & does NOT include any objects that can be added by an installed/managed package, or other objects that you’ve created and are “Custom Objects”. Each of these Objects will each have their own unique Salesforce three-digit Object Code. (If you know of any other Object record IDs, please share them with me).
Now, comes the interesting part. An opportunity will follow this ID code: 006XXXXXXXXXXXXX. If you are a smaller org, it will look something like 0060000000000002xWh, representing a single Opportunity record. For some objects (not all!), to find the new or edit page, the URL structure that just follows the object URL reference with a blackslash and an ‘e‘ after.
In the opportunity example, http://na33.salesforce.com/006/e would be a new opportunity edit page on the na33 Salesforce instance.
In HTML, the GET method can be pushed through the URL by appending a ‘?‘. In the case of creating a contact, it would look something like:
In this case, we have the Salesforce URL followed by 003/e, or the Contact’s Edit page, with the retURL meaning what URL you will go back to once you click Save or Cancel.
To create a contact, we’d want to pass over parameters like the retURL, or Return URL, the Record Type of the contact, and the Account ID (accid) as well. That would look something like:
The & in the above is how you can string parameters together in the GET request.
Sending parameters through the Salesforce URL
Let’s take the Task object in this example.
Salesforce Tasks tasks are the URL code – 00T
So /00T/e – will let us set the task edit page.
We’ll then string the GET request by adding a ? after the e.
So far, so good – we’re at /00T/e?
And now, for Tasks, we have to figure out what each field on the Task object does based on the URL GET parameter.
For Tasks, here are just some of the parameters we can pass (I will go in more detail in a later post):
tsk1= Who is the Task Assigned to?
tsk2= What is the Related Contact ID?
tsk3= What is the Objects name
tsk4= What is the Due date
tsk5= What is the Subject
tsk12= What is the Task’s Status
retURL= Where to return when saved
Here’s a basic example situation for the URL Hack use case that we can create:
An unknown person calls the Main Sales line, and an inbound Sales user wants to quickly open a new Task from any page in Salesforce to get ready to jot down notes about the conversation. To do that, the user can click on a custom link (that we will create) located on the sidebar, that will have the Subject (tsk5) set to “Call: Sales Line” and have the Status (tsk12) be “Completed”. The Custom Link URL structure would look like:
This will allow them to quickly update the Task’s Comments section of the call, and associate the task with a Contact or Opportunity if existing already in the CRM. To do this, you would go to the Custom Links section in setup, and create this custom link to add to the sidebar. (Article will go here when completed!)
You could of course add on to the above URL schema to string other parameters to pass through and save with the Task record that the link creates.
Creating URL Hack in Salesforce
So how can we implement this for our users in Salesforce? As seen above in the Task use case, we can create a custom link that allows a user to quickly populate the Status and Subject fields of a task, where they can write some notes quickly, with less clicks, and by able to focus their attention to the prospect.
For many use cases, I’ve implemented Custom Links on the Sidebar or Custom Buttons & Links above an Object’s record (on the page layout) to perform these actions.
In future articles, I’ll showcase and walk-through some of the URL hacks I’ve personally created. These include populating Reports based on the Account record the link on the page layout is clicked, being able to fulfill tasks & cases quickly (more of the above), and being able to quickly create certain contacts or opportunity types to save time for your users.
Have you created custom URL hacks for your Salesforce Org? What are your thoughts on the future of URL hacks and migrations to Quick Actions? Share with us in the comments below!