Skip Navigation
Knowledge Advanced User Administration and Search Access to Articles
Answer ID 9892   |   Last Review Date 10/24/2019

What actions are required to administer the users that will use Knowledge Advanced and Search for Articles?


Knowledge Advanced, All Versions


There are two out of the box (OOB) searches for Knowledge Advanced (KA):  One in the Customer Portal (CP) for contact users and one in the Agent desktop (AD) for staff users.  There is also an API search, article import, etc. that can be used for further customizations which is not discussed here.

Contact users:

When a contact user initially logs into CP and uses some KA function a KA web user is created in the authoring web user list.  The web user is assigned the web roles that correspond with the access levels in the users CX contact user.  Service level agreements (SLAs) map to access levels and contact users need to have these mapped in CX.  This mapping happens either through the organization that the contact user belongs to or by adding the SLAs directly to the contact user.  Every time the contact user uses a CP KA function, their user information and access levels are updated to match the correct KA web roles.  If the web role does not yet exist for that access level, one is created by the KA system.  Nothing extra needs to be done on the authoring side for contact users.  If contact users do not have any access levels they will only be able to search public documents.

Note: If the contact user has not logged in and used KA function since changes were made to their CX contact user, the authoring web user will still reflect the old web role/access level assignments.  Also if contact users or access levels are deleted, the web users and web roles are not currently deleted.

Note:  Web roles and user groups are the same thing - they both map one to one to access levels.

Staff users:

CX Staff users are created and added to a profile which determines what they can do in CX.  The user may or may not have access to any of the KA tabs in the profile permissions on the service tab, but they will have access to search.  When a staff user logs into AD and uses some KA function a KA console user is created in the authoring console user list.  The console user is assigned the console role that corresponds with the profile in the users CX staff user.   Every time the staff user logs into AD and uses KA function, their assigned profile and staff user are updated to the correct KA console user properties and console role.  If the console role does not yet exist for that profile one is created by the KA system.

Administrative tasks for staff users:

1. The console user will need to be assigned the views that map to the interfaces that they have access to in their profile.  By default they have access to all views.  If this needs to be restricted the user has to be updated to change those views.

(The users views should be allocated when the user is created by the KA system by what interfaces the user has access to in their profiles.  Currently the tenant view is being assigned which might not be desirable.  This gives the user access to all documents in the KA authoring tab.)

2. To use authoring function, the console role needs to have authoring privileges added in the KA console role.  If there are additional article views that the user can author than more view access can be granted.  Also if user groups are being used in AD search, then the matching web roles need to be added to the console user or user groups can be added to the console role.  User groups and web roles and access levels are the same function.  This allows access to articles at a console role level or an individual console user level.

Note: In addition, the users console role needs to be granted view access for each content type that the user can view articles for.  This is done automatically for all authoring content types when the console role is created from the profile by the KA system.

KA views and interfaces:

A KA view can be used for more than one interface, but each interface has one view.  This means that only KA articles assigned to that view will return in that interface.  In the KA authoring tab users are also restricted to the articles assigned to the views they have.  All KA articles have a view which is not the tenant view.  The tenant view only applies to users and it allows them to see all articles in the authoring tab and see articles in the KA search for that interface.  Users and articles can be assigned to multiple views.

Note:  Web content does not have a view assigned to it, therefore it returns in the search of every interface.

KA user groups:

CX access levels map one to one to KA User groups which can be assigned to web content or KA content.  All content without a user group is considered public content.  The KA articles without user groups are also public but they are restricted to the interface(s) that they are assigned to.  The CP interfaces are always restricted by the contact users access levels/user groups.  AD interfaces can be enabled to use access levels/user groups but OOB this is disabled.

Note: User groups are not used in the authoring tab to restrict content from authors.  In authoring, user groups designate which user groups that user can assign to articles and this is determined by the user groups in the console role, the content type and the view.

CX Steps to provide restricted access to contacts users:

  1. Define Answer Access Levels
  2. Define SLA's and associate to the appropriate access level.  Check the values for the content you want that SLA to be able to view for that organization and its users.
  3. Define Organizations and select the SLA that matches the users access
  4. Assign the contact to the organization.