Hooking

embed help on off platform pages with the ‘hooking script’ the ‘hooking’ script obtains the contextual help that is available for the user’s current off platform location when correctly configured, inclusion of the script on an off platform page results in the appearance of the quick access menu, configured appropriately for the user’s access rights embedded help, where this has been defined for the page being visited prerequisites users must have logged in to salesforce before any help can be delivered the hooking script requires the user to be logged in to salesforce before any help can be delivered if one is not logged in, the hooking script will be unable to request the resources required from salesforce and neither the qam nor embedded help will appear in these cases, the off platform page will usually operate as if the hooking script were not present architecture 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 ways to add the script the hooking script can be added to your off site pages in two ways manually if one has administrative access to the site in question, one may be able to add the hooking script to its pages manually for example, one is often able to edit global site settings of some kind to ‘include’ code snippets of the type required browser extension if one has no such access to the site or it does not provide facilities for inclusion of code n its pages, one can use the improved help browser extension for chrome, which adds the required script to all pages as one visits them adding the script manually precise steps will vary according to the off platform site requirements 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 this can be obtained as follows log in to the helped org switch to classic this is required here to be sure of 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 adding the script via browser extension improved apps offer an un packaged browser extension for the chrome web browser that adds the hooking script to every page visited (subject to domain white listing as described elsewhere) to use the browser extension contact unaric guide for the code of the extension, which must be copied to a location to which end users have access users must access salesforce using the chrome web browser from chrome’s “more tools” menu, select “extensions” as an un packaged offering, the help extension requires that chrome’s “developer mode” option be switched on with developer mode enabled, click the “load unpackaged” button and browse to the location of the extension code the extension manifests itself as a button resembling an embedded help icon to the right of the browser’s address bar right click the icon then select the “options” menu item to reveal a settings page on the settings page, ter the visualforce domain at which help is to be accessed, then click save with the extension correctly configured, click the icon to toggle help on and off 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 this can be particularly useful when using the improved help browser extension, which (when switched on) will attempt to add help to any page that is visited, which may not be desirable 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 elements of the page, “help signatures” must be created assuming one has successfully added the hooking script to an off platform site, the quick access menu should be visible towards the top right of the screen initially, this will present options such as search and bookmarks, but will not offer the ability to enter help enable mode – so no help can be added to the page this is because, whilst improved help automatically recognises the items of screen furniture present on salesforce pages and is therefore able to help them, off platform sites are effectively ‘unknown territory’ in order to be able to attach embedded help to elements of the page, “help signatures” must be created 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 ce pages 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