Internal vs external knowledge base: what belongs where
Compare an internal vs external knowledge base by audience, access, content, and review needs. Use a safe test to decide where each article belongs.
Support Station Team
September 7, 2026 · 5 min read
The difference between an internal and external knowledge base starts with the reader. An external knowledge base helps customers and prospects complete safe tasks. An internal knowledge base helps employees follow company procedures and resolve cases.
Many teams need both. The important decision is not which name to use. It is which people may read each fact and what they can safely do with it.
Compare internal and external knowledge bases
| Area | Internal knowledge base | External knowledge base |
|---|---|---|
| Main audience | Employees and approved partners | Customers, prospects, or the public |
| Access | Restricted by identity and role | Public or customer-facing |
| Common content | Procedures, runbooks, escalation rules, policy details | Setup, how-to, FAQ, and safe troubleshooting articles |
| Context | Can use defined company terms | Must explain terms and assume less context |
| Review focus | Operational accuracy and access | Product accuracy, privacy, search, and clear customer action |
| Common next step | Complete work or escalate inside the team | Finish a task or contact support safely |
Atlassian's internal and external knowledge base guide also separates agent-facing and customer-facing material so teams can control access and give each audience the right information.
Put customer-safe tasks in the external base
External articles should help a reader act without access to internal systems. Common topics include:
- Create and set up an account
- Use a product feature
- Understand a public policy
- Download a document
- Fix a common customer-side error
- Contact support with the right safe details
Write in customer language. Explain product terms before you use them. State permissions and requirements before the steps. Show the expected result and a route to a person when the task needs account access.
Public does not mean vague. A strong external article can give exact steps while protecting internal controls and private data.
Keep sensitive operations in the internal base
Internal articles can cover work that an employee or approved partner must perform. Examples include:
- Identity verification procedures
- Fraud and abuse response
- Security incident steps
- Refund approval rules and exceptions
- Manual account or data changes
- Private vendor contacts
- On-call and escalation paths
- Unreleased product details
Restrict access by role when every employee does not need the information. Review membership and permissions as people change roles or leave.
An internal label does not make content safe by itself. Treat the knowledge base as an operational system. Apply access controls, remove secrets that belong in a secret manager, and follow your retention and audit rules.
Use a publication test for every article
Ask these questions before you publish or move content:
- Who needs this answer to complete their task?
- Does it include customer, employee, security, or vendor data?
- Does it reveal a control that could be misused?
- Does it require an internal tool or permission?
- Could a customer follow it without harm or false expectations?
- Who owns the facts and can approve the audience?
If the content contains both public guidance and internal procedure, split it. For example, a public refund article can explain eligibility, required information, and how to ask for help. An internal article can explain approval levels, fraud checks, exceptions, and staff actions.
Link the internal article from the team workflow. Link the public article in the customer reply. Do not expose a restricted URL as a substitute for writing a public answer.
Manage shared facts without unsafe copying
Some facts belong in both places, such as supported file types or the meaning of a public error. Repeating them in separate pages creates update risk.
Choose an owner for the shared fact. Record which articles depend on it. When the fact changes, update and test both audiences. Keep the external version focused on customer action. Add internal diagnosis and escalation only in the restricted version.
Do not paste a full internal article into a public draft and try to remove the sensitive parts at the end. Start the public page from the customer's goal. This reduces the chance that a private note, image, exception, or link remains in the published text.
The customer support article template provides a safe customer-facing structure. The troubleshooting guide helps separate public checks from internal diagnosis.
Review access and content over time
Set an owner and trigger for each article. Review external instructions when the product, navigation, or public policy changes. Review internal procedures when tools, vendors, controls, or team responsibilities change.
During a knowledge base content audit, check both accuracy and audience. Look for public pages that expose internal details, internal pages that should have a safe public companion, duplicate facts, broken restricted links, and articles nobody owns.
Test access with an account that has the intended role. An administrator's view cannot prove what a customer or new employee can see. Record the result and correct any path that crosses the audience boundary.
Use both knowledge bases when both audiences need help. Keep the boundary clear, test it, and give every shared fact an owner.