Once upon a time, I had to Override the standard New button on my Contact object to set a field value as part of the record created. (Specifically, I wanted to set the Account field to a default value.) I did this by creating a Custom S-Control:
It has to be done as an S-Control because the ‘Override’ function only permits S-Controls and Visualforce pages:
That all went very well.
Cloning
I have since been requested by my users to permit Cloning of a Contact record. Here at Atlassian, we have Contacts with two Record Types:
- Manually created: Fully editable within Salesforce
- Imported from our Customer Database: Mostly read-only, loaded via DataLoader
I have no problems with peole cloning ‘Manually created’ Contact records, so I provide the normal Clone button. However, for Contact records ‘Imported from our Customer Database’, I was not willing to permit cloning because:
- The record type would need to be changed (to ‘Manually created’)
- The ID field from our Customer Database would need to be cleared
- Many fields should not actually be cloned (eg Name) because the prime purpose of enabling Clone was to save typing when creating a new Contact from the same company as an existing Contact
In the end, instead of a ‘Clone’ button, I decided to implement a ‘Copy’ button that created a new record but automatically copied selected fields across to the new record:
Two important things to note:
- Field values are passed in the URL, eg ‘con4′ is the Account field
- I appended a custom field to the end
The technique of setting fields in the URL is standard in the user community. I don’t know if it’s meant to be officially done, but enough people do it that it is pseudo-official. I get field names (eg con4, con19street) by viewing the Page Source of the Salesforce page and looking for the field of interest. Hopefully they’ll stay the same across change to the Page Layout.
Custom fields, however, are known to produce problems. Rather than having a nice field name (eg conRegion__c), the Page Source uses the ID of the custom field. You can prove this by putting the ID in a URL, such as na1.salesforce.com/00N20000001Bx9v. Unfortunately, this results in an error because the URL doesn’t understand something that starts with two zeros.
By a stroke of luck, I found that I could append the Custom Field to the end of the URL (outside the URLFOR command), which would be correctly added to the generated URL that creates the new object. This has driven people crazy for ages, so I figured it was worth a blog post to help future generations of Salesforce Administrators!
The Bottom Line
- Add custom fields to a URL by placing the custom field assignment AFTER the actual URLFOR statement
- It can be easier to create a New record rather than a Clone, especially if you don’t want to copy most fields
