Queues

We touched on Queues in Chapter 4, “Microsoft CRM Functional and Conceptual Overview,” Chapter 5, “Setting Up Microsoft CRM,” and Chapter 6, “Homepage, Workplace, and Navigation,” now let's get into more detail on them. Queues are like folders that can be used to group Service Cases. The Microsoft CRM training documentation describes Queues as placeholders for unassigned Cases. However, in reality the user who creates a Case will become the default Case owner. When you assign that Case to a Queue it will show up in the Queue, but the owner will not change. So, it might be more clear to think of a Queue as a folder where the Case can be parked for future action.

The most obvious use of Queues is for reassignment to a pool of users so that one of the users can take ownership of the Case and do something with it. This might be an escalation process where one user has attempted to solve an issue without success and is now passing it to a higher level resource to try and resolve it. In this case, the originating user would reassign the Case to the appropriate Queue and a user monitoring that Queue would then review it in Workplace and accept it. At the point the new user accepts the Case, she becomes the Case's owner. The originating user remained as the owner of the Case even after assigning it to the Queue. The significance of this is that the Case never was without an owner even though it was parked in a Queue waiting for a new owner. It is interesting to note that in this example of the Case being assigned to a Queue, but remaining “owned” by a user, the Case record itself has no visible indicator that it is in the queue. The only way to know that the Case is in the queue is to go to Workplace and look in the queue.

NOTE Queues can be configured to receive all inbound emails sent to the Queue's email address. This can be especially helpful for a general support/service email alias such as [email protected]. For information on configuring Queues to receive email, refer to the "Microsoft CRM Email configuration in-depth" section of Chapter 5.

Through Workflow, Cases can be assigned to Queues based on the attributes of the Case or its related objects (in other words, its associated customer, Contract, and so on). This functionality can be used, for example, to assign all resolved cases to a Queue for manager approval. It can also be used to assign cases to certain Queues based on the Case Subject or Product. If you are working in a Service environment where a single user is logging all Cases, you can use Workflow processes to intelligently assign the Cases based on attributes of the Case (for instance all Cases with high priority and subject = “Bikes” are automatically assigned to Jim). The Cases can be assigned to either Users or Queues.

TIP If you plan to have Case escalation, this is an area where Workflow rules can be a big help. Case escalation refers to the re-assignment of a case to another resource, group, or department often based on severity or complexity of the Case. A typical example of a business rule to enable Case escalation would be the auto-reassignment of all Cases with a Status Reason of “In Development” to a queue monitored by the development team.

User Queues

Each system User by default has two personal Queues that can be seen in the Workplace area of the application. These Queues are the User's private Queue (labeled “Assigned”), and the User's Work In Progress (WIP) Queue (labeled “In Progress”). Whereas Users can be set up to see all Cases assigned to public Queues, only the User's themselves can see what is in their private Queues.

Public Queues

Public Queues are also displayed in Workplace, and can be seen by all Users with access to view Queues. Of course, the User viewing the contents of the Queue is only presented with those objects for which he/she has view security privileges.

KB (Knowledge Base) Manager

As was mentioned briefly in Chapter 6, the Knowledge Base (KB) is a tool that can be used to search KB Articles that have been submitted and approved. To see how KB Articles are created, we'll have to take a look at Knowledge Base Templates in the Setting area.

Navigate to Settings, Template Manager, Knowledge Base Templates and you will see a list of all existing templates in the system. These templates are simple document layouts to help you organize the various types of Articles you will want to create. Figure 9.13 shows the Knowledgebase Article template.

Setting up a template is a simple task. Using the tools to the right of the screen, you can add sections and move them up to down to create the proper document order. These sections are filled with text by the Users creating articles.

Users can create Articles by going to Service, KB Manager and selecting the New Article Button. The User is prompted to select an Article template, and then is allowed to enter text into the various template sections. Figure 9.14 shows the KB template explorer.

Each Article is given a title and keywords and must also be associated with a Subject. Article numbers are automatically generated by the system with the prefix chosen in the Auto-Numbering tool under Settings, System Customization. Figure 9.15 shows a completed, published KB article.

When the new Article is saved it is in Draft status and can be viewed from the Draft Queue.

Article Queues

For starters, Article Queues have nothing to do with the Case/Activity Queues we just discussed. KB Manager provides a simple process of three Queues used to submit, approve or reject, and publish Articles.

When an Article is newly created, it is put into the Draft Queue and is in draft status. The user who created it, when they feel the Article is ready for review, can click the submit button on the Article form to move it to the Unapproved Queue. The Article is now in unapproved status and a user with privileges to approve or reject articles can review the article and either approve or reject it. If that User rejects the article, he/she is prompted to enter an article comment giving the article's creator some feedback on why the article was rejected. This comment, pictured in Figure 9.16, is stored on the Comments tab of the Article record.

Upon rejection, the Article is moved back into draft status and back to the Draft Queue. The author (note that Articles are not linked to owners) can then improve the Article and resubmit it. Upon approval, the Article is moved to the Published Queue and is in published status. Published Articles can be unpublished at any time by a user with the appropriate privilege to do so. Articles must be unpublished to be modified. Only Articles in the Published Queue are searchable.

Subjects and Articles

We mentioned earlier that all Articles must be associated with a Subject. The Subject is a way of categorizing the content of the Article and is used as criteria in searching and browsing Articles. Although we typically think of Knowledge Bases as repositories for data to be used in resolving issues for customers, the Microsoft CRM Knowledge Base can be easily and effectively used to house all sorts of external, as well as internal, information. For example, you could create a Subject called Personnel Policies and create templates and articles to publish out all personnel policies including travel policy, expense reimbursement, and so on. Employees would then have that information in a fully searchable format.

Search Tab

With respect to the Search tab of Knowledgebase, this is an area where Microsoft is leveraging the strength of the underlying SQL Server application. The KB search is carried out using the Full Text Search (FTS) capability in SQL Server. FTS allows a database administrator to create Full Text indexes of tables and add those indexes to Full Text Catalogs. The Full Text Catalogs can then be populated and SQL Server jobs can be created to schedule ongoing incremental populations of the Catalogs. In the case of the Microsoft CRM Knowledge Base, a Full Text Catalog is created named fcat_documentindex. This Catalog contains the Full Text Index on a table called DocumentIndex. DocumentIndex is the table that holds the KB Articles. As displayed in Figure 9.17, the Full Text Index covers the Title, Keywords, and SearchText fields of this table. It does not include the Article comments that are attached to the Articles. These are not searchable.

When Microsoft CRM is installed, an SQL Server job is created by default to run an incremental population of the fcat_documentindex catalog on a 15 minute interval. Therefore, by default, newly published articles can take up to 15 minutes to appear in searches if this default interval is not modified.

NOTE The Full Text capability in SQL Server is implemented through a service called Microsoft Search, which is a Windows 2000 service that finds its origins in Index Server and Site Server. This service must be running for Full Text search and the Microsoft CRM KB to work. What Microsoft Search actually does is to pull out data from SQL Server and create operating system index files in the FDATA folder (by default) under SQL Server. From a security standpoint, this means that it is possible that someone with access to the SQL Server's filesystem could find his or her way into the contents of your Knowledge Base articles. This is something to consider when planning security of your Microsoft CRM deployment.

One final note on the search tab is that although its use is very straightforward, it is worth mentioning that when you search using the Full Text option under the title “In the article:” your search will not include key words. You must specifically select the Keywords option in that same drop-down to search the Keywords. In addition, when you open an Article to view it the Keywords that were added at the time of creation are not displayed. If you want to view an Article's keywords you must use the KB Manager under the Service Area.