The design topics in this section are intended for implementers who are designing and configuring an  knowledgebase. These discussions are aimed at helping you understand the differences between different implementation options so you can make an informed design choice.

There are an infinite number of ways to configure  to address the specific needs of an organization. There is no one right way to model the data, and some choices don't have a right or wrong answer.

The following tips will provide guidance when you are faced with difficult decisions. 

  1. Keep things as simple as possible from the user's perspective. A good way to judge how simple two alternative solutions would be is to ask how difficult each would be to describe them to a colleague. The solution that is easiest to describe is usually the best.
  2. The most logical representation is usually the best. This is really another aspect of the first rule, and just means that you should represent information the way that you think about it. 

    If, in your business, Suppliers are always individuals that you work with directly, you probably think of them as people, in which case it is reasonable to represents Supplier as a type of Contact. If however, your suppliers were Companies, you would create Supplier as a type of Company. 

  3. Represent information as explicitly as possible. For example, if you have a table for collecting bug reports, it is better to have a field named Reproducible, typically a Yes/No choice field, and another field Steps to Reproduce Issue than just to have a field "Steps to Reproduce Issue" which may be left blank if the problem is not reproducible.

The design articles in this section provide some practical advice based on real-life scenarios for implementers and administrative users when designing an  system. They contain a discussion of the pros, cons, and other implications of implementing a particular solution to a design dilemma. Each uses the criteria below when evaluating and recommending a solution.

Criteria for Evaluating Design

Rarely is there a single best solution when deciding how to implement a project specification. Choosing between two or more possibilities requires evaluating your design decision and thinking through the implications of each choice. When evaluating any implementation design, consider the following criteria:


Does the proposed design meet the business requirements? The users’ needs?


Is the design as clean and robust as possible?


Can the system be adapted to incorporate new business processes and features?

Related articles