There are several considerations that should be made prior to installing Staff.Wiki and deploying it for use throughout your company. In this section we'll run through those so you can roll out Staff.Wiki smoothly and successfully at your organization, with minimal risk.

Piecemeal Rollout

Features
Staff.Wiki has many features that integrate well, but most of these features are optional and can be switched off. In order to not to overwhelm of confuse users, and to properly coordinate the roll-out with adequate training where required.

Some of the features in Enterprise Edition that can be switched off initially are:

• The Questions box. This is used to allow end-users to ask questions about policies and have this sent directly to specific departments. Because this requires first setting up the ticket system, you can switch off this feature. The option is in Main Settings on the Configuration tab ("Disable Webchat").
• AI Functionality. This feature is currently offered in the editor. It can be disabled in Main Settings ("Disable all AI Features").
• Article Ratings. This "star rating" feature is disabled by default. It can be enabled when you are ready by switching on the "Enable Ratings" in the Configuration tab, Main Settings.
• Incident Reporting. This is used to allow end-users to report incidents or hazards. If you would like to disable this, you can do so in Main Settings on the Configuration tab. 
• Blog. This is used to centralize company news. You can hide this tab using the Custom Tabs feature, Hiding Tabs feature.
• Quizzes. This is used to centralize all quizzes that an end-user can take. If this is not important to your organization, you can hide this tab using the Custom Tabs feature, Hiding Tabs feature.
• Checklists. If you do not wish to use checklists, you simply do not add checklists to articles.
• Risk Registry. This is only visible to administrators and any users with Risk Analyst set on their profile. Simply don't add the Risk Analyst flag to users if you do not want this to be visible.
• Compliance. This is only visible to administrators and any users with Risk Analyst set on their profile. Simply don't add the Risk Analyst flag to users if you do not want this to be visible. 

User-Base
In order to ensure a smooth migration of your policy and procedures, it is recommended that the system is rolled out to one group or one department at a time. This will allow you to get feedback on how the system is configured, and also assess the usage and resource demands on an ongoing basis so you are adequately prepared to scale the system for more users. Because each company is different, a phased roll-out is best way to roll-out with minimal risk.

Consider a small team (<15 people) to start with, and put in specific policies or procedures related to that team. Encourage them to use the system and schedule weekly feedback sessions so you can ensure everything is working as expected. Any deficiencies in understanding can be addressed by adding supplemental user guide material into your own wiki, or if generally applicable can be sent to us to integrate into the main user guide.

We have a short guide on importing documents, but should you need assistance in converting existing policies and procedures documents, please contact us to see if we have resource availability.

This will be your phase one roll-out. In the latter part of that first phase you can start planning for phase two, scaling up for more users and more documents in the system.

Licensing Requirements

When using Staff.Wiki on-premise, you will need to acquire either the On-Premise Standard Edition or On-Premise Enterprise Edition. The Standard Edition has the same features as what is available on the Starter Edition, but allows for an on-premise installation that can be deployed on-site. The Enterprise Edition has many additional features for customization, along with a fully integrated Compliance Module and Risk Management system. It also has support for a comprehensive API that allows the system to be more easily integrated into third party applications on-premise.

To learn more about the differences, please refer to the Editions of Staff.Wiki article.

After choosing the base license, you will then have to determine how many Wiki Managers will be licensed. End-users, who will just be either reading articles or signing attestations, will not be licensed so you can add any number of these. Any editors or approvers, however, must be licensed. The base license typically comes with 5 Wiki Manager licenses. If you need more than that, you will need to add them to your subscription. LIcenses can be added throughout the term of subscription on a prorated basis. Please contact us for more details.

Determining Server Requirements

To learn about the base requirements in terms of software and hardware, please read our Deployment Requirements article.

After that you can continue by considering how exactly the application will be used in this first phase. This will include determining factors such as:

• Number of end-users
• Number of editors (known as Wiki Managers)
• Number of concurrent sessions
• Size of articles that are accessed
• Size of files that are downloaded

Each of these will factor into how you will need to plan in terms of resource availability and server capacity. The best approach to setting up capacity is to build a server that is capable of scaling up easily, such as a Virtual Machine on a larger server. This will allow you to adapt easily to increase in demands.

Aspects of Impact

Next we'll be considering the different aspects of resource utilization that you will need to consider.

• CPU utilization 
  This includes the speed of the processor and the number of cores. Staff.Wiki does not utilize the GPU. We recommend at least an i5 grade processor.
• Memory utilization
  We recommend at least 8Gb for the server. Consider also the L1 cache available on the CPU.
• Memory fragmentation
  The less memory is available, and the more certain operations are executed (such as updating very large articles), will likely lead to fragmentation of memory over time. Typically the server will resolve this by moving chunks of memory around, but it can result in a degradation of performance over time.
• Disk space usage
  Disk space is used by the SQL Server database, but it also used to store attachments in the file system. This is something that will increase gradually, so it is best to start with a reasonable size (eg. 100Gb) and be prepared to increase this should the need arise.
• Disk access speed
  Regardless of utilization the response time for accessing the disk should be <10ms for optimal performance.
• Bandwidth usage
  Consider also any limitations on bandwidth throughput you may have on your network or between servers and end-users.

Assessing Usage

The usage of your application will impact the processing resources required to support the server. Please keep in mind the following:

• CPU usage will be impacted largely based on certain operations like updating articles (including moving, inserting and deleting), as well as the number of concurrent sessions. If you expect concurrent sessions in excess of 500 over a length of time, you should consider having two or more servers with a load balancer between them to ensure adequate responsiveness.
• Memory usage will be impacted based on the length of articles, and the number of concurrent sessions on that server. Individual sessions will have some (although minimal) memory footprint, and sessions can be maintained in the server cache for up to 30 minutes, even if it relates to only one request. Additionally, various processes utilize in-memory caching for performance reasons, thus you may see memory spike during certain processing such as publishing articles.
• Bandwidth usage will be impacted purely based on the number of concurrent sessions (overall) and the size of articles that are viewed. To keep bandwidth at a reasonable level, it is recommended to keep article lengths at a certain maximum size, split into sub-articles. This means that users will only download the part of the article that they are interested in, reducing memory and bandwidth overhead.

Backup Considerations

It's critically important that you properly configure, and regularly test, a backup process that backs up both the SQL Server database and the file system (where attachments are stored). For more information, please read this article.

Integration Considerations

When authenticating users, you have several options for integration. You can read about setting up Single Sign-On (which uses OpenID Connect) in this article, or connecting to Active Directory in this article. There are also other options for implementing custom scripts for authenticating users, allowing you to integrate with third party systems through their API. Please contact us to discuss these options.

Integration with other applications is also possible, including with Microsoft Teams and Slack. There is an API that can be used to integrate with third party applications, but some coding may be required to implement that integration. Access to the API documentation is limited to Enterprise customers and provided upon request.

Setting Up Approvers

One of the most important aspects of securing the wiki is to ensure you have the proper chain of command configured in the system to manage the approval workflow. You will do this by setting up approvers at top-level articles in the hierarchy. The approvers must be Wiki Managers so ensure that you have adequately accounted for these users when purchasing the license.

More information on setting up approvers can be found here.

Setting Up User Groups and Departments

Another important aspect of setting up Staff.Wiki is to properly configure both the user groups and departments. While departments can be created for each of the main departments in your organization, user groups are usually smaller groups that are configured for specific operational duties. A user can be in one department only, but can be in multiple user groups.

Both of these are configured by an administrator using the Configuration tab's Departments and User Groups buttons.

The department is used on tickets, whereas the user groups feature will be used mostly for when configuring the limiting of access to specific articles.