Embedded Help
Help Domains
use help domains to control who sees what set up conditional content visibility using salesforce sharing rules how it works out of the box, improved help is configured to offer read only access to all key content records to all licensed users as a solution for delivering critical help and training material in context, this is logical and appropriate, as the desire is typically to share knowledge across the organisation in the default setup global visibility is the default as such, configuration decisions, such as where to position help lightning components, control where help facilities will be available the active flag on help topics can be used to hide draft materials from end users until they're ready for use (only help authors and administrators see topics whose active check box is un ticked) in built contextualisation logic in combination with data driven features (ddf) control which topics are surfaced on particular pages with particular record data create sharing user groupings in some circumstances, it can be desirable to control which content is visible to a given group of users for example, one might wish to have a set of french materials for francophones, with the same materials available in english translation for english speakers help domains make this possible create public groups or similar for use in salesforce sharing rules, where granular content access control is required help domains take the form of salesforce sharing rules, which are designed to provide granular control over who sees which records this is achieved by specifying the object whose records are to be controlled (for example, help topics) the criteria for sharing (for example, share topics where owner = some user) the set of users who are to be granted access to records matching the criteria the set of users is defined by membership of salesforce user roles and / or public groups the first step is therefore to create groupings that reflect your need for help domains and to assign users to them for example, one might create a public group called french speakers and add francophone users or suitably populated divisional role representing an organisational unit whose content needs differ from others in the business create sharing rules having created groupings of users (roles and / or public groups) representing the help domains that are to be made available, create sharing rules to define the sets of help they are to see sharing rules should be created for help topics, as these represent the content to be shared helped elements, as these control which topics to display embedded into your helped pages at a high level, the process of creating each required rule is as follows select the object to be shared enable granular control over sharing by editing organization wide defaults to be private (so no one sees records of the type being managed until sharing rules grant visibility) create a new sharing rule for each help domain that is desired provide a suitable name and description select based on criteria for the type specify criteria share with the relevant user grouping(s), as created previously specify the desired level of access (typically read only) sharing rules criteria the criteria to use to define visibility can be based on many combinations of object data, including locally defined custom fields for simplicity, however, both help topics and helped elements include a 'visibility' pick list that can be used in defining sharing settings the available values can be amended as required via setup for example, one might add a new value of french to the help topic visibility pick list and specify criteria of visibility = french when creating the sharing rule for help topics, sharing with the appropriate sharing use grouping (e g , a public group) create custom permission sets create custom permission sets that lack view all access where granular access control is required unaric guide ships with a number of permission sets suited to various user types, each providing varying levels of access to help authoring and management facilities however, they all provide global, read only access to key help content records to take advantage of sharing settings, our standard permission sets should be cloned and new versions produced, identical in all respects except for removal of the view all crud permission on help topics and helped elements allocate these cloned permission sets to users instead of those shipped as standard