Solution Knowledge

Solution Knowledge is the library of plain-language documentation that teaches the DocMgt assistants about your solution — the specific Record Types, workflows, E-forms, and Add-ins that make up an application on your site. Without it, the AI assistants only know DocMgt in general. With it, they can answer questions like "How do I approve this invoice?" or "What happens after I submit this form?" using the way your configuration is actually built.

Each entry is a knowledge record: a named solution (for example, "AP Automation") holding a set of short documents organized by category, plus optional suggested starter questions. The assistants read the Active version of each solution and use it to ground their answers.


Available when Allow Builder AI is on (Admin > Main Options > AI) and your site is licensed for AI. The screen lives under Admin > AI Configuration > Solution Knowledge.


Where knowledge records come from

This is the key connection to SOW Builder. There are four ways a solution gets documented, and most sites will use more than one:

  1. Automatically, from a SOW build. When you build a configuration with SOW Builder and import it through Config Manager, DocMgt generates a Solution Knowledge record for that build in the background. The documents and suggested questions are written for you from the objects that were just imported. This is the primary path — if you use SOW Builder, your solutions are documented without any extra work. The new record arrives as a Draft for you to review.
  2. By editing what was generated. The generated text is a strong first draft, not a locked artifact. You can open any record and refine the name, description, individual documents, and suggested questions before (or after) approving it.
  3. By having AI document an existing application. For solutions that were built by hand — or built before Solution Knowledge existed — you can point the AI at your live objects and have it generate a knowledge record the same way it would for a SOW build. This closes the gap so older, hand-built applications can be documented too.
  4. Manually. If you'd rather write the documentation yourself, you can create an empty record and hand-author every document and question. Nothing about the system requires AI involvement.


In short: SOW Builder makes these for you, but you stay in control — edit them, have AI build one for an app you already have, or write one from scratch.


How the assistants use it

Two assistants read Solution Knowledge:

  • Ask DoM — the end-user help assistant. It answers questions for everyday users working in records and forms, and it can show clickable suggested questions for whatever object the user is currently in.
  • The admin Help assistant — the chat available to administrators, which can also see documents marked Admin Only. Each document has a visibility setting that controls which of these can see it:
  • Both — visible to Ask DoM and the admin assistant. Use this for anything an everyday user might ask about.
  • Admin Only — visible only to the admin assistant. Use this for configuration notes, security details, or internals that end users shouldn't be handed.


Only the Active version of a solution is read by the assistants. Drafts and Inactive versions are ignored until approved.


Anatomy of a knowledge record

  • Solution — the application being documented. A solution can have more than one version (for example, an original Active version and a newer Draft after a rebuild). The screen groups all versions of a solution together.
  • Status — every record is one of:
    • Draft — newly generated or newly created; not yet read by the assistants. This is where you review before going live.
    • Active — the version the assistants currently read. Only one version per solution can be Active at a time.
    • Inactive — a version that was previously Active and has since been retired or superseded.
  • Generated by — how the record was created: SOWBuilder (from a SOW build import), ConfigManager, or Manual (hand-created or AI-documented from existing objects).
  • Documents — the actual knowledge, grouped into categories: Record Types, Workflows, E-forms, Add-ins, and General (which includes the solution overview). Each document has a name, a category, a visibility, and a body of plain-language text.
  • Suggested Questions — optional sets of clickable starter prompts shown in the Ask DoM panel, tied to a specific object the user is working in.



The list view

The opening screen lists every solution, grouped by name, with each version shown as a row carrying its status badge, who generated it, the date, and (for approved versions) who approved it.

From each row you can:

  • Open — go to the detail/edit view for that version.
  • Approve / Re-approve — make this version the Active one (see Approving and versioning). The button reads Approve for a Draft and Re-approve for an Inactive version.
  • Deactivate — retire the currently Active version.

Two toolbar buttons sit at the top:

  • New Record — hand-author a new manual solution.
  • Document Existing App — have AI generate a record from your existing live objects.



The detail view

Opening a record shows three editable sections.


Details

The record's Name and Description. Edit them and click Save Details. The footer shows how the record was generated and its created/updated dates. Editing the name or description never affects the documents or suggested questions — they are preserved on save.


Suggested Questions

The clickable starter prompts Ask DoM offers an end user. They appear only when the user is working in the matching object, so they feel specific to what's on screen.

Each set is one object plus a list of questions. To manage them:

  • Add — create a new set. Choose the category (Record Types, Workflows, E-forms, Add-ins, or General), pick the object the questions apply to, then list the questions.
  • Edit — change an existing set's object or questions.
  • Delete — remove a set.


When you pick the object, the editor offers a dropdown of your live objects so the name matches the real configuration (the assistant resolves questions by exact object name). For workflows, the list shows processes and their individual steps, indented the same way Config Manager displays them — choose the specific step the user would be on, or the process itself if the questions aren't step-specific. If no live objects are found for a category, you can type the object name as free text.

Suggested-question sets generated by a SOW build or by "Document Existing App" already include per-object questions — this editor lets you refine them or add your own.


Descriptions

The body of knowledge, grouped by category. Click Add to create a document, or Edit to change one. A description has:

  • Name — its title (read-only once created).
  • Category — Record Types, Workflows, E-forms, Add-ins, or General.
  • Visibility — Both or Admin Only
  • Content — the plain-language text the assistant reads. Write it the way you'd explain the feature to a colleague.



Approving and versioning

The assistants only read the Active version of a solution, so a Draft does nothing until you approve it.

  • Approve a Draft to make it Active. If another version of the same solution is already Active, approving the new one automatically deactivates the old one — there's only ever one live version per solution, and the confirmation dialog tells you which version will be replaced.
  • Deactivate an Active version to take it offline. The assistants stop using it immediately. You can bring it back later with Re-approve.
  • Re-approve an Inactive version to make it Active again (deactivating whatever is currently Active for that solution).


This lineage is keyed to the solution, so rebuilding an app with SOW Builder produces a fresh Draft alongside the existing Active version — you review the new one, approve it, and the old version retires on its own.


Document an existing application

Use this to document a solution that already exists on your site but has no knowledge record yet — typically a hand-built application, or one built before Solution Knowledge was available.

  1. From the list view, click Document Existing App.
  2. Give the solution a name (required) and an optional description.
  3. Pick the existing objects to include — Record Types, Workflows, E-forms, and Add-ins are each listed with checkboxes. Select everything that belongs to this application.
  4. Click Generate. The AI reads the selected objects and writes a Draft knowledge record — descriptions and suggested questions included — just as it would for a SOW build.
  5. Review the generated Draft, edit anything you like, and Approve it when you're happy.


This uses Builder-pool AI tokens (it's the same generation the SOW build path uses) and is recorded in your AI usage as an "App Documenter" activity.


Creating a manual record

Click New Record to create an empty Draft with just a name and description, then add documents and suggested questions by hand. This is the fully manual path — no AI is involved — and is useful when you want complete control over the wording, or when you're documenting something the generators don't cover.


TIPS

  1. After a SOW build import, visit Solution Knowledge and review the new Draft before approving it. The generated text is good, but a quick pass to confirm it matches how you actually use the solution makes the assistants noticeably more accurate.
  2. Use Admin Only visibility for configuration internals and Both for anything an everyday user might ask — getting this right keeps Ask DoM helpful without leaking admin detail.
  3. For suggested questions, tie them to the specific workflow step a user is on rather than the whole process when the question only makes sense there — the prompts will feel tailored to the moment.
  4. Keep one Active version per solution. When you rebuild, approve the new Draft and let the old version retire automatically rather than leaving two versions live.
  5. For an app you built by hand, Document Existing App is the fastest way to get the assistants speaking your solution's language — start there, then refine.


NOTE ON (AI): Generating a knowledge record (from a SOW build or from existing objects) consumes tokens from the Builder pool and may incur extra fees. Editing, approving, and hand-authoring records use no AI. Please verify all generated content, as AI can make mistakes.