AddThis Feed Button

Recent Items

My users were asking for a particular custom Opportunity field to be searchable. A quick check of the Salesforce online documentation for Search Fields revealed that:

  • The sidebar search looks in the Name field and any External ID fields
  • The Advanced Search feature looks in Description and any custom text, email and phone fields

I didn’t want to change the Name field, nor did I want users to have to seek out the Advanced Search field when they wanted to find this particular field.

Fortunately, I found Steve Andersen’s blog that referenced Tanner Shamrock’s explanation of how to add Advanced Search to the sidebar. (Ain’t the Net great!)

AdvancedSearch

This enabled me to change the standard Search dialog into an Advanced Search, so my users don’t even notice the difference. (They can no longer select the Object Type to return, but I doubt they even noticed that option!)

Oh, if you’re implementing Tanner’s code, be sure to visit your User Interface configuration and turn on “Show Custom Sidebar Components on All Pages”, otherwise the change just appears on your Home Page.

The Bottom Line

  • Advanced Search is more powerful than normal ‘sidebar’ search
  • You can replace your normal search with Advanced Search
  • It’s great to be able to use code developed by others — thank you!

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

Budding psychologists out there may be aware of Maslow’s hierarchy of needs, which is part of his 1943 paper A Theory of Human Motivation. Maslow puts human needs into a hierarchy:

Following Maslow’s lead, I wish to propose a Force.com Hierarchy of Skills:

The hierarchy has many omissions and contains much that is apocryphal (or at least wildly inaccurate), but does give an indication of the progression of skills while learning Salesforce.com and the Force.com platform.

Let’s take a look at each component:

Standard Objects & Functionality represent the first level of knowledge, which most users of Salesforce.com discover over time. Interestingly, while I’m the Administrator of my company’s Salesforce.com system, I don’t actually know all of the functionality, such as how to use Activities and Email templates. I can trust the users to figure that out.

When using the Force.com platform, there are no standard objects or functions. (Well, there’s a few like Users, but not the Sales-oriented stuff like Opportunities and Campaigns.)

Administration functions give access to the inner workings of the platform, such as adding Objects and Custom Fields, modifying Page Layouts and managing Security.

Reporting could arguably fit into either of these first two levels — it’s simple enough to give to Users, but is easier to understand and build reports if you know about Custom Fields and Formulas.

Workflow and Data Import build upon the knowledge of objects and fields. I’m talking about using the Data Loader rather than the Import Wizard. In fact, during a visit I once had to the Salesforce.com office in San Francisco, even the developers down-talked the Import Wizard. The Data Loader is very powerful and can do some magic with External IDs, but that needs a good understanding of the lower-level Admin skills.

Workflow similarly builds upon Admin skills, requiring knowledge of how information is updated and linked between Objects. It’s not hard to configure, but can be challenging to get ‘right’ in a system with lots of exceptions and strange uses.

Visualforce & S-Controls begin the concept of on-demand programming. I’ve grouped them together because Visualforce is actually replacing what S-Controls previously enabled. S-Controls have the benefit of using the familiar JavaScript language, but Visualforce is more integrated with the Force.com platform.

Apex represents the, umm, ‘Apex’ of Force.com skills. It provides powerful low-level Triggers and custom logic that can be hard to define in a point-and-click system. However, this power comes at the cost of complexity in learning the language, the development environment and the nuances of Force.com development. Fortunately, it comes with good error-prevention capabilities such as strong type checking, automatic reference checking between Apex code and objects, and good deployment tools.

I’ll admit that I was considering putting Visualforce above Apex, since Visualforce can ‘use’ underlying Apex logic (eg controllers). It’s also newer than Apex and you’re likely to find more Apex-skilled administrators than Visualforce-skilled. Nonetheless, I’m keeping Apex at the top due to its higher complexity and the great pun associated with the word ‘apex’.

I’ve got a few experiments in mind to test the validity of this Hierarchy. I’ll post the results when finished.

The Bottom Line

  • If Maslow had access to Force.com, his Apex would have been different

I had a strange one today. My users were complaining that they couldn’t drill-down from a Dashboard to a Report. They were getting Insufficient Privileges errors.

I had never known this to be the case, since the drill-down always worked for me (as an Administrator).

The reports were of the type “Campaign with Member Status”, but weren’t actually using Member Status. When I recreated the report as type “Campaign”, it worked! However, I didn’t want to recreate all the reports, so I investigated further.

I discovered that the users were getting these options when Creating Reports:

On the other hand, as an Administrator, I was getting these options:

Campaign Members are are stored as separate objects within Salesforce.com, and can be linked to Campaigns, Leads and Contacts. They basically store a Status string (eg Attended) and a HasResponded flag (to measure the success of Campaigns).

Unfortunately, there are no permission settings for Campaign Member objects. So what was preventing them from appearing to my users?

I stumbled across a Salesforce blog article about Best Practices in Campaign Management: Tips & Tricks that referenced a Custom Link that gives a “hidden report”. It didn’t help me, but it reminded me of a similar link on Campaigns that give a list of members:

Well, that report didn’t run for those users, either! (I made heavy use of the Login as Another User functionality to test this, plus a spare account that I use for testing purposes.) It’s a very useful report, so I actually want them to be able to use it.

The Discovery

Well, I eventually discovered that the users had to have Read permission on the Lead object. We don’t use Leads, so I had never assigned permission. Merely giving them Read permission fixed the problem and they can now run all of those reports.

It wasn’t obvious, but the fact that Campaign Member objects contain a pointer to Leads probably explains it. If they aren’t allowed to know about Leads, they shouldn’t be able to view an object that mentions Leads (or something like that). Case closed.

The Bottom Line

  • Many Campaign Reports require Read permission on Leads to enable access
  • Don’t assume that users have access to functionality — Test it by using the Login as Another User functionality

I consider myself a fairly good Administrator for my company’s Salesforce.com system. Not that I understand everything, but I’m aware of most concepts in the system. I even enjoy discussing configurations and implementation options with another Administrator.

However, I’m a very unskilled User. I don’t use Salesforce.com as my primary day-to-day work system, so I can’t really explain the benefits of Activities vs Events, or the best way or manage Reminders.

That’s sort of embarrassing to explain to people when I train them up on using Salesforce.com.

Here’s an example: I know how to write Apex, how to code Validation Rules, and how to write S-Controls. But only today did I discover the My Email Settings page (under Setup/Email) where people can set a return address for their emails:

Looks like I’m not alone. There are lots of Ideas posted that are asking for this functionality!

The Bottom Line

  • You learn something new every year
  • I can go home now — I’m done for the year!