SuiteCRM case management and knowledge base

The case subject is the main input SuiteCRM uses to suggest Knowledge Base articles, so the sequence from inbound email to suggestion is worth understanding before you configure anything. An email arrives in the group mailbox, email-to-case creates a new case, and SuiteCRM compares the case subject against existing Knowledge Base articles and shows the agent any matches. The agent then either selects a suggested article for the reply or finds nothing useful and writes a new article. Both paths depend on the subject being present and descriptive at the moment the case is created, because that is when the comparison runs. Confirm in your own environment exactly how the email subject is mapped to the case subject, including what happens when the email has no subject or a generic one.

The practical consequence is that subject lines and article titles carry more weight than they appear to. A case subject such as "It's broken again" gives the comparison almost nothing to work with, while "Invoice PDF fails to download in Safari" names the product area, the symptom and the channel. Article titles work the same way from the other side. An article titled with the wording customers actually use is far more likely to be suggested than one titled with an internal project code. Because matching depends on the words in these two fields, a small difference in phrasing can decide whether an agent sees the right article within seconds of opening the case.

Naming conventions therefore belong in the design, before go-live. Decide who is responsible for correcting case subjects after triage, and agree a short, consistent structure for article titles, such as product area, symptom and channel. Write that structure into agent guidance so that new articles follow it. Also check how article status and approval are used in your process, since status (Draft, Pending, Not Published, Published or Expired) and the approver field show whether an article is ready for agents to rely on. Confirm whether suggestions include articles in every status or only Published ones, and do not assume the answer. If the behavior differs from your intent, adjust the process or ask the implementation team to confirm the configuration before users depend on it.

Testing matching is a pre-go-live task, not a formality. Export a sample of actual subject lines from your current queue, including messy ones from mobile devices, forwarded threads and automated alerts. Run them against a staging copy loaded with a representative set of articles, and record for each subject whether the expected article appears, nothing appears, or a misleading article appears. Use the results to refine article titles and the subject-line guidance for agents. Repeat the test whenever you load a large batch of articles or change how email-to-case populates subjects, because the suggestions depend on the contents of the knowledge base as well as on the configuration.

Case management depends on accounts, contacts and users that exist before the first inbound message arrives. Email-to-case attaches each message to a record, so the group mailbox needs a clear rule for matching a sender's address to an existing contact and account, and for what happens when no match is found. Confirm in the user guide for your version whether unmatched senders create new contacts, and decide whether those contacts are merged later or resolved by an agent. Clean the contact list first. Duplicate people, shared generic addresses and accounts with several spellings attach cases to the wrong customer and make the history unreliable. Name an owner for account and contact data so that corrections have someone accountable for making them.

Next, decide how cases are classified and who receives them. Product or service categories are the field agents and reports will use to route and group work, so agree a short list with the teams that will answer for each category before go-live. Each category should map to a team that owns it, because team assignment sets the default ownership and determines which queue a new case lands in. Define user roles to match. Decide who may create, reassign, close and delete cases, who may see accounts outside their own team, and who may publish knowledge articles. Categories can be changed after go-live, but existing cases keep their original classification, so any rename needs a plan for reporting continuity. Test each role with a pilot user before the mailbox opens.

The knowledge base is the second dependency, and it is the one teams most often leave empty. Articles carry a status of Draft, Pending, Not Published, Published or Expired, along with a resolution, version number, author and approver. When a new case is created, SuiteCRM compares the case subject with existing articles and suggests relevant matches. An empty knowledge base therefore produces no suggestions, and agents quickly stop reading the suggestion panel. Before go-live, decide who may write articles, who approves them, and who is responsible for moving an article to Expired when a product or process changes. Those decisions determine the approver and version information that every published article will carry.

A reviewed seed set should be small enough for each article to be checked properly and broad enough to cover the requests that arrive most often. Pull recent case subjects, group them by the wording customers actually use, and write one article for each recurring request with a clear resolution. Give each seed article a version number and an approver separate from its author, and set it to Published only after that review is complete. Keep unfinished material in Draft so it stays out of suggestions. Because matching uses the case subject, titles should use the words customers use, with internal product names kept out of them. Test the set by creating sample cases from past subjects (illustrative: a subject such as "cannot log in after password reset") and checking which articles are suggested.

SuiteCRM documents the move from version 7 to version 8 as a migration into a new environment, so the plan starts with a new SuiteCRM 8 installation and a controlled data move. Before anything moves, the 7 instance should be brought to the latest 7.14.x release or later, so the source data sits on the baseline the documentation expects. Cases, case updates and Knowledge Base articles then move as separate data sets, each with its own mapping to fields, statuses and relationships in version 8. Name one owner on your side for that mapping, and agree in writing with any partner who checks the moved records. Confirm the exact 7.14.x or later build with SuiteCRM before you schedule the move.

The migration documentation advises three things before any data moves. First, test the full sequence on a staging instance that matches production as closely as possible, including the same customizations and a case volume close to what you expect to move. Second, back up both the files and the database, then confirm the backup restores to a separate server. Third, review customizations, because the migration may remove non-core files under the public/legacy folder. Inventory every file you have added or changed there, including entry points, themes and scripts that support email-to-case or Knowledge Base search. For each item, record whether it will be rebuilt, moved to a supported location or retired before the staging run starts.

Not every case and article needs to move. Set the criteria with the service manager before the export is built. A common split is to move open cases, cases closed within the period your service and audit obligations require, and Knowledge Base articles in the Published status, while leaving old drafts and expired articles in an archive. SuiteCRM 8 articles carry the statuses Draft, Pending, Not Published, Published and Expired, so check how each legacy status maps before you decide. Archived records still need a home, such as a read-only export or a separate store that support staff can search. Ask who approves archive retention and how long each archived record must be kept under your own policies.

Confirm the import method for case history in your version before you design the data set. Ask SuiteCRM whether case updates, which carry the threaded customer and internal messages, arrive as linked records or as flattened notes, and whether attachments and original email headers are kept. Also confirm how account and contact relationships are re-linked, because a case without a valid contact link can drop out of the customer view. Run a test migration with a deliberately varied sample, such as a long-running case with attachments, a case with many updates and an article with an approver. Compare record counts, linked records and attachments on each side. Illustrative example: if a case shows fewer updates after the import, treat that as a blocking defect and rerun the sample.