for a knowledge article to be published or archived, there are a few different ways this can occur based on some of the values on some of the fields in the associated knowledge base see the knowledge table schema docid 5woaq0zumbf7pij 6iewi for the specific differences in the workflow, however the fields in a knowledge base that control approvals are and what they do are publish article instantly this field highlights whether an article can go directly to the status of published from draft this will skip any approvals or any stages between publishing an article from draft require approval for publishing this field highlights that when an article is in a state of peer review or is archived, an article will need to be approved before going into a state of published it will require one approver from the approver list on the associated knowledge base article to be published require approval for archiving this field highlights that when an article has been published, if it needs an approval before going into the archived state it will require one approver from the approver list on the associated knowledge base article to occur knowledge base specific visibility and editing for each knowledge base there are extra visibility and editing options you can have on top of the base permissions to restrict who can edit and view the articles within the knowledge base by default, platform self service users can see any published article, as long as the role required for visibility field has not been set, whilst by default knowledge editors can edit any article where the role required for editing has not been set it should be noted that someone needs visibility of a record to edit a record therefore, once the role required for visibility and role required for editing has been set, it is important that any roles required for editing, are also entered in the role required for visibility field knowledge base manager extended capabilities when a user has been made a knowledge base manager, it is assumed they have the knowledge manager role, as without this they will not have their full capabilities by being a manager of a knowledge base, the user has the capability to publish and archive an article without any approvals, even when the knowledge base has the require approval fields set as true in addition to this, these users can edit a knowledge article, even when it is not in draft or peer review, therefore offering them capabilities over and above the average knowledge editor user it should be noted that administrators and knowledge administrators also have the same capabilities knowledge article type within a knowledge article, there are currently two different types they are standard this simply shows users a knowledge article that is stored within servicely on a content page when being accessed via sofi this will use a combination of the title, summary and content to show the user a knowledge article from the servicely knowledge base federated url this allows users to provide a federated document url for a knowledge article what this will mean is that when a knowledge article is selected via sofi, the user will be redirected to the document url, rather than providing the content of the knowledge article stored within servicely auto archiving as an optional extra of knowledge articles, it is possible to set an auto archive date servicely checks every hour for any published knowledge article that has passed the auto archive date, with the purpose to set that article's workflow status to archive as this date is set prior to approval, it is assumed that if an article has passed the approval and review statuses, even if the associated knowledge base requires approval for archive, it will archive automatically after this date and time therefore it is seen that these article have been approved for archiving, when they are being published highlighted articles another optional extra of knowledge articles is the ability to "highlight" an article by highlighting an article, it will provide the ability to query on these records specifically and will be used to highlight certain articles on the self service homepage if an article has been highlighted, it is also possible to set a highlight expiry date every hour servicely will check any highlighted knowledge article that has been highlighted and automatically set the highlight field to false, once the expiry date has been passed the idea is that this may be used to highlight changes, maintenance or otherwise (written in a knowledge articles) that everyone needs to see at a glance for a set amount of time automatic archiving on source record closure when an article has been created from a record extended from the work table (for example problem and incident), by setting this field to true, it will automatically archive the article when the associated work record has been closed the record that will cause the archiving of a record can be seen via the source record field on a knowledge article it should be highlighted however if a knowledge article is re published or the source record was closed prior to association, this field will no longer have an impact of the article status and the article will stay published indefinitely (assuming the auto archive date has not been set as well) attaching a knowledge article from sofi's recommendation if you have sofi installed and configured + knowledge articles created on your instance, it may suggests some of those articles to the tickets you are raising to enable the ability to attach knowledge articles from sofi, you will need to have the following application property created application properties key property type application properties value sofi ai config settings ui kblink knowledge boolean true sofi's flyover pane will then show a link called "attach" below every suggested knowledge article example below after you have clicked on the "attach" link, the knowledge article will be linked to the ticket on the field called "attachedknowledge" you can also configure how the article is shared with the customer of the ticket that is done via the respective out of box ui events for the ticket tables, they are all suffixed with "enable sofi on form load" as an example, one for the incident table is called "incident enable sofi on form load" out of box, attaching a knowledge article will place a link to the knowledge article onto the client journal however, if you would like to place the knowledge article's content instead, you would need to find to find the following code in the aforementioned ui event above client setjournalarticle(current clientjournal, kbarticle); and replace with current clientjournal(kbarticle content); then repeat the above step with other equivalent journal fields as needed another example is for major incident on the ui event called "incident enable sofi on form load", replace client setjournalarticle(current majorincidentjournal, kbarticle); with current majorincidentjournal(kbarticle content);