Working in Knowledge Base

Daily Operating Model

Knowledge Base works best when teams treat the module record as the source of truth and use tasks, tickets, workflows, and reports as supporting surfaces. The flows below are the common day-to-day paths to validate during setup and train users on after go-live.

Flow 1: Create a knowledge category

1. Open the KB route and create a category.
2. Name the category for the audience rather than the internal team.
3. Add description or ordering if the UI supports it.
4. Assign owners responsible for article quality.
5. Create starter articles for the most common questions.
6. Link the category from relevant pages or portal navigation.
7. Review reader permissions before publishing publicly.
8. Use reports or feedback to merge thin or duplicate categories.

Flow 2: Write and publish an article

1. Open the target category and create an article.
2. Write the answer, process, or reference content in a scannable structure.
3. Add related links to objects, forms, tickets, or workflows where useful.
4. Review for accuracy with the owning team.
5. Publish when the content is approved.
6. Notify impacted users if the article changes an operational procedure.
7. Track article age and schedule periodic review.
8. Archive outdated articles rather than leaving conflicting guidance live.

Flow 3: Use KB in support work

1. Support agent opens a ticket or customer question.
2. Search KB for the relevant article.
3. Attach or link the article in the response.
4. Create a new article draft when the answer is repeated but undocumented.
5. Flag stale or incorrect content to the article owner.
6. Use workflow tasks to route article review.
7. Measure ticket deflection or repeated questions by category.
8. Update articles after product or policy changes.

Flow 4: Govern article quality

1. Review categories for ownership and freshness.
2. Identify articles with low usage, repeated edits, or conflicting answers.
3. Assign review tasks to the subject matter expert.
4. Update screenshots, route names, and policy text.
5. Confirm public exposure settings after every major content change.
6. Retire duplicate content and redirect readers where possible.
7. Use search analytics to improve titles and wording.
8. Keep KB permissions aligned with portal and page exposure.

Day-To-Day Controls

• Start from the launchpad route, then use filters and saved views to focus on records needing action.
• Use status fields and lifecycle actions instead of free-text notes for important state changes.
• Attach documents, comments, or related records when a decision needs evidence.
• Create tasks when work leaves the current owner or needs a due date.
• Create tickets when the work is customer-facing or belongs in a support/service queue.
• Use workflows for predictable notifications, approvals, escalations, and cross-module updates.
• Use reports for recurring team reviews rather than exporting ad hoc lists every time.
• Keep permissions tight enough that users see the records they need but not sensitive configuration.
• Review rejected, cancelled, failed, or overdue records every week.
• Keep integrations aligned with the same lifecycle users follow in the UI.

Exception Handling

• If a record is stuck, check owner, status, required fields, approvals, and linked records before editing downstream data.
• If a workflow did not run, confirm the event name, trigger filter, record permissions, and service-user access.
• If reports look wrong, inspect whether the source record is draft, cancelled, archived, or missing a required dimension.
• If an integration created bad data, fix the source mapping and then repair the affected records through supported actions.
• If users cannot see a route, review launchpad access, module roles, page permissions, and tenant feature flags.
• If a public or embedded route exposes too much, disable exposure first and then correct permissions or filters.
• If two modules disagree, choose the module that owns the lifecycle as the source of truth and update the other from it.
• If a record supports audit, void, archive, or cancel it instead of deleting it whenever possible.

Reporting Rhythm

• Daily: review new, overdue, failed, rejected, and pending-approval records.
• Weekly: review owner workload, aging, status changes, and recurring exceptions.
• Monthly: review configuration, permissions, integration failures, and report definitions.
• Quarterly: review whether custom pages, workflows, and API access still match real operating practice.
• After major process changes: rerun one end-to-end flow with a pilot record before enabling it broadly.

Cross-Module Handoffs

• To Base objects: pass stable identifiers, owner, status, dates, and any dimensions required for reports.
• To tasks: include a precise action, due date, source record link, and escalation owner.
• To tickets: include requester, priority, support context, and the module record link.
• To workflows: prefer explicit create, update, approval, and status-change triggers.
• To reports: keep dimensions consistent across records so dashboards can group accurately.
• To integrations: use /reference/kb for namespace and intent details.