function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

fieldLevelHelp 1.0

I was looking at field level help on the IdeaExchange and I thought to myself, "Self, wouldn't it be nifty to build a feature like that for fun?" So I did.

However, I don't have time to write some fancy documentation, so here's the quick version:

1) Test drive the app, and make sure to get the XML file from the Documents tab.
1) Install the app into your organization.
2) Find the ID of the S-Control in Setup | Build | Custom S-Controls (eg. 01N30000000XXXX).
3) Elect to show custom sidebar components (Setup | Customize | User Interface).
4) Create a new home page component (Setup | Customize | Home | Home Page Components). Make sure the component is on the "narrow" side.
 Use the following code (check "Show HTML" first), updating the ID of the S-Control:
<IFRAME style="DISPLAY: none"
5) Create a home page layout (Setup | Customize | Home | Home Page Layouts), and add the component to the layout. Assign the layout to the correct profiles.
6) Update the XML file from step 1 to include your terminology. You may embed HTML tags by escaping them-- see the example XML file for examples of this.
7) Edit the S-Control (Setup | App Setup | Build | Custom S-Controls), and use the "Attach File" feature below the code to upload the file. Save to have the XML file uploaded.

That's it. You now have field level help on all standard and custom objects. Testing suggests that the XML file is cached by the browser, so only the home page should take longer to load. The XML parser in modern browsers seems to be quite fast at what they do; I can't even tell the script runs (although I'm only using a 3kb example, it seems to scale well).

I'd feel safe in saying the XML file could be at least 100kb without a penalty, if not more.

The code isn't that elegant, as I wrote it in about 20-30 minutes or so, so use at your own risk. (Honestly, it took me longer to create the appExchange entry for it than it did to write the app itself). Feel free to modify it, tweak it, whatever you would like to do to it.

How it works:

1) By embedding it on each page, it loads when the browser loads any detail page.
2) When it loads, it calls the XML file into memory and searches for an object with the same name as the page.
3) If it finds one, it proceeds to load the field entries and tries to locate each field. If it finds the field, it adds the custom message to the field.

If you have questions, post them to this thread, and if I have time, I'll answer them. I don't have time to support this as a full-time application though, so be forewarned. That's why I'm posting this as a free publication with the intent that someone will find it useful for future integrations using this methodology.

One final note: I apologize for the source code. I tend to be rather cryptic at times when writing code privately. If you can't figure something out, just ask. And please keep it in this thread, so all the answers can be found later.

~ sfdcfox ~
Or, you could wait for field level help to be part of the platform.  :smileywink:

I saw that the feature is marked as Coming Soon, but it's still a useful "proof-of-concept" app. You could conceptually modify the Save button behavior, for example, or remove "Save and New" from various pages. The possibilities are endless, given a bit of ingenuity and inventiveness. Page-level validation rules (why? I don't know, but someone out there is bound to try), default values for certain standard fields, including cross-record default values... So many possibilities. The only problem with developing anything for the platform is you never know how soon a feature is going to be released. Unless I were a developer, which I'm not, so I have to sort of just write whatever catches my fancy and let the ideas take care of themselves. :D

~ sfdcfox ~
So, you this coming soon?  Cool. 

As for the, and I'll use the term loosely, "injection" technique, there are some dangers here.  One is that you code will run for every page.  Might not even notice it, but then again, you might.  The real danger is that you are scraping the pages to determine what dom object to interact with.  I'm sure you are aware of the problem with this, but, let me say it again.  The dom structure is not an API and we can change it at any time.  If we do change it, the impact may be as simple as your code just doesn't run due to not finding the element, but could be as bad as have a javascript error on every page in the app.

It's your data and your app, just be aware of the possible consequences.