Hooking Script

the hooking script allows you to embed help on pages outside salesforce this script obtains the contextual help that is available for the user’s current off platform location how it works the hooking script is minimal by design rather than replicating or simulating help behaviours, its sole purpose is to connect with the logic already present in the improved help app this retains both simplicity and consistency customers can be certain that all business logic, such as access control and crud rights, will be identical to on platform scenarios when correctly configured, inclusion of the script on an off platform page results in the appearance of the quick access menu (qam) docid\ rr6yfdkj10yclwk34e1ea , configured appropriately for the user’s access rights embedded help docid\ pbyn 85hr5apwdygl 3rz , where this has been defined for the page being visited the hooking script requires users to be logged in to salesforce before any help can be delivered in these cases, the off platform page will usually operate as if the hooking script were not present add the hooking script precise steps to add the hooking script to your off site pages will vary according to the site requirements for example, one is often able to edit global site settings of some kind to include code snippets of the type required the script that needs to be added to the site’s pages is as follows in the above script, {vfroot} needs to be replaced with the visualforce domain used by improved help in the org that users have logged in to to obtain the visualforce domain log in to the helped org switch to classic this is required to ensure obtaining visualforce page paths (and not lightning tab addresses) reliably switch to the improved help app copy the domain (with protocol but no path and no final '/') of the help settings page whitelist domains the help enabling tab of the global settings page includes a “whitelisted domains” text box that can be used to control the off platform sites where help is to be provided ensure that the whitelisted domains text box includes the domain (no protocol or path) of the desired destination site(s) to be helped alternatively, ensure the whole text box is empty, signifying that all remote domains may be helped using signatures to identify helpables in order to be able to attach embedded help to page elements, help signatures must be created after adding the hooking script to an off platform site, the quick access menu should be visible at the top right of the screen initially, this will only present options such as search and bookmarks to include the ability to enter help enable mode and add help to the page, you must create help signatures whilst improved help automatically recognises the items of screen furniture present on salesforce pages and is therefore able to help them, it does not on off platform sites purpose signatures have been developed to vastly expand the reach, power and flexibility of improved help rather than relying on the presence of a limited set of known helpable elements (which are defined by recognised patterns of tags in page mark up), signatures allow orgs to define their own patterns such that improved help will look for them and allow them to be hooked to make help available, your salesforce pages must include our "hooking" code, which adds the required logic and style sheets to the user interface once the hook is in place, your pages need to feature "helpable" elements pieces of screen furniture for which you wish to provide help candidates might include elements, such as form fields or the labels that occur near them, where data entry is expected and provision of related help is important for error minimisation and consistency buttons or links that trigger complex or critical operations, where warnings or usage guidelines may be useful icons or other non specific pieces of screen real estate, which can be linked to more general help concerning a particular screen or process create signatures signatures work with mark up as delivered to the client they describe the helpable elements as they will appear once the page has arrived at the browser help administrators identify the mark up they wish to hook (for example by viewing page source or using a browser based inspection tool) then record the required details in helpable signature records once these standard salesforce records have been created, the pieces of screen furniture they represent can be help enabled just like standard salesforce elements help signature records work as follows field description signature this is the signature of the elements we wish to hook, expressed in css / jquery selector notation for example, if you inspect a classic salesforce field label as found on record detail pages, you’ll find they look something like this \<td class="labelcol"> field label text \</td> to make a signature for these elements (which we don’t need to do as improved help already recognises this one!) we would enter the pattern that uniquely identifies these kind of elements, that is the details of a table cell with a class of “labelcol” – or, in css speak td labelcol identifier & identifier type in any given scenario, there are likely to be many instances of a helpable on a particular screen in the example above, we may wish to help some field labels but not others, linking each to its own help topic as well as identifying hookable elements, therefore, signature records need to provide a way of differentiating individual helpables from each other the identifier and identifier type fields tell user help how to do this four identifier types are supported attribute the unique identifier for a particular signature helped element is an html attribute of the helpable element for this type, the identifier field is the name of the identifying attribute • property the identifier is an html property of the helpable element for this type, the identifier field is the name of the identifying property • html the identifier is the inner html of the helpable element for this type, the identifier field is ignored • text the identifier is the inner text of the helpable element for this type, the identifier field is ignored in our example, the signature makes all table cells with a class of labelcol hookable any particular field label from among these is identified by the text of the cell (i e , the label text) thus, the identifier type is text (and the identifier field is ignored) domain in order to limit the places where helpables are sought, the domain can be used to narrow the scope of particular signatures domains should be entered without the access protocol (http or https) for example, a signature for the english version of wikipedia would be en wikipedia org working with help signatures an understanding of the basic workings of hooking is useful in mastering signatures here's what happens when improved help has been configured for a given page layout pages that include the help hook request details of known helpables as they load to do this, the helped page layout is identified by examining the current page url and checking related records for known layouts having obtained these details, each potentially helpable element is checked against a list of helped elements defined for the identified layout where a particular helpable has been registered as a helped element, it is marked as being "helped" by the addition of styling and on click behaviours signatures are standard salesforce custom object records that define mark up patterns which, within the context of a particular web domain, represent helpable pieces of screen furniture signatures for the relevant domain are provided to pages as part of the hook's request for known helpables data as a result of this, the elements defined by the signatures can be hooked in the same way as the known, standard elements supported by the app, such as the field labels on an autoform