Odoo Knowledge Implementation
Wiki + procedures + runbooks.
Internal wiki with rich articles, property-based structured data, template library, and full-text search: the single source of truth for your team.
Odoo Knowledge is the wiki that lives inside the ERP. Articles nest in a tree under Workspace, Shared and Private, they are written in the same editor that writes a quotation description, and they can carry a live Odoo view instead of a screenshot of one. It is an Enterprise application. There is no Community equivalent, so adopting it is a licensing decision rather than a module install.
The argument for it over Confluence or Notion is proximity. A support agent reading a resolution procedure is one panel away from the ticket. A finance clerk working through the month end runbook is inside the system the runbook describes. No second login, and no extra subscription for anyone who already holds an Odoo internal user. The cost is that Knowledge is a wiki and not a document management system, and those two get confused on most projects.
Whether it survives contact with a real company is decided by structure and ownership rather than by features. Articles multiply fast, permissions are inherited from the parent when an article is moved, and nothing in Odoo tells you a procedure went stale eighteen months ago. The implementation work is agreeing the tree, the permission model, the properties that turn a section into a register, and who is accountable for each branch.
Who Odoo Knowledge is for
- → Operations teams who want the procedure and the record it describes in one system, so the runbook opens beside the transaction it governs.
- → Support organisations that need a customer facing knowledge base and internal resolution steps drawn from the same set of articles.
- → Companies carrying a written compliance obligation, such as a German procedural documentation or a documented e-invoicing process, that has to be maintained rather than written once and filed.
- → Teams already paying for Odoo Enterprise and paying a second wiki vendor per seat for twenty pages nobody has reviewed in a year.
- → Not for a public documentation site that needs versioned releases, stable permalinks and its own navigation, which a Website page set or a documentation tool serves better than a share link.
- → Not for controlled document management where every revision needs an approval signature and a retention period, which belongs in Documents and Sign or in a dedicated quality system.
Key features
- ✓ Rich article editor
- ✓ Property-based data
- ✓ Template library
- ✓ Full-text search
- ✓ Favorites & sharing
- ✓ Versioning & history
What Odoo Knowledge actually does
The article tree is also the security model
Articles nest to any depth. The sidebar separates Favorites, Workspace where every internal user can reach an article, Shared which is limited to named members, and Private which starts with a single owner. A child inherits the parent permission unless it is overridden, so moving a branch moves its access rights with it. Articles take an icon and a cover image, and an article can be locked so the body stops accepting edits. Deleted articles go to Trash and are purged automatically after thirty days on a default database. That window is a system parameter rather than a switch on a settings page, so treat thirty days as the recovery you have unless somebody has deliberately changed it.
Editor and the slash menu
The body uses the same editor as the rest of Odoo. The slash menu inserts headings, checklists, tables, quotes, code blocks, files, images, a video by URL, a table of contents, a link to another article, and a clipboard block whose text copies out in one click. Content pasted from Word or from a browser arrives as HTML with its own markup attached, which is where most of the formatting argument on a project starts. Agree early that authors paste as plain text and restyle, because a tree carrying four inherited font stacks looks like exactly what it is.
Items and property fields
An article can hold items, which are child articles carrying property fields defined once on the parent. A property can be text, a number, a date, a checkbox, a selection, tags, or a link to another record such as a partner or an employee. Items then render as a list or a kanban with those properties as columns, filterable and groupable like any other Odoo view. A section becomes a small register, an incident log or a policy index, with no new model and no Studio work.
Embedded Odoo views
An article can embed a real view, for example a filtered list of open tickets or a kanban of purchase orders. The embed is built from the source view rather than from inside the article: you set the filters and grouping on the list you want, then insert that view into an article, and the filter travels with it. The reader sees current records inside the procedure rather than a picture taken last quarter. Access is still evaluated per reader, so somebody without rights on the underlying model gets nothing where the author sees rows. Test every embed with a low privilege login before you tell anyone the page is finished.
Sharing inside and outside
Each article carries an internal permission of none, read or write, plus individual members who override it. Members added on a parent apply to everything beneath it, and Odoo shows which ancestor an inherited right came from, which matters the first time somebody asks why a contractor can read the pricing article. An article can also be published to the web, which produces a URL that opens with no login for anyone who has it. There is no expiry on that link and no per visitor permission behind it. Unpublishing withdraws the URL, and that is the whole of the control you have after the fact.
Reuse from the record side panel
From the Knowledge side panel on a record form, an article can be posted into the chatter as a message, dropped into a description field, or copied to the clipboard block by block. Sales keep answer blocks there, support keeps resolution steps, HR keeps policy wording. The article remains the single copy, so correcting it once corrects every later use. Odoo offers a small set of article templates when you create a page, and for house standards the working pattern is one skeleton article per document type that authors duplicate.
How we configure Odoo Knowledge
Design the tree before anyone writes
Top level sections should follow function rather than the org chart, because departments get renamed and processes do not. Decide what belongs in Workspace, what is genuinely Shared, and what is Private. Agree a title pattern up front, for example process area then verb then object, because a result list is read by its titles and forty articles called Process are unusable. Two hours of argument here removes a permission repair job later, since restructuring a live tree carries access rights along with the branch.
Write the permission model down
List who reads and who writes for each top level branch, then set the internal permission on the parent and add members only where a branch differs. Watch the case where a Private article is moved into Workspace, since it becomes visible to every internal user at that moment. Name who is allowed to create top level articles as well. On a default database any internal user can start one, and an unowned parallel tree beside the agreed one is how a company ends up with two wikis inside a single application.
Turn the repetitive sections into items
Anything you would otherwise keep in a spreadsheet, such as incidents, policies with owners and review dates, or supplier notes, should be items with properties rather than paragraphs. Define the property list once on the parent so every child inherits the same fields, because retrofitting a property across ninety existing items is manual work. A selection property for status and a date property for the next review give you a filtered list of everything overdue, which no amount of free text will do.
Put live data in the article
Where a procedure refers to records, embed the view and save the filter with it rather than pasting an image. Keep embeds narrow, three or four columns, since a wide list view inside an article is unreadable on a phone and slows the page for every reader. Point embeds at a filter you control rather than at an ad hoc domain, so the same list can be corrected in one place when the underlying process changes.
Decide the review and retention rules
Odoo will not expire an article. Add an Owner property and a Review Date property on each parent, then keep one items list filtered on review date in the past and work it as a standing monthly job. Where a review has to appear in somebody's task list rather than in a wiki page, mirror it as a recurring project task or a calendar event that links back to the article. Check what Trash retention your database actually runs on as well, because the default gives you thirty days and a recovered article costs far less than a rewritten one.
Where Odoo Knowledge projects go wrong
Assuming it is in Community
Knowledge is Enterprise only in Odoo 17, 18 and 19. This surfaces late, usually after a Community pilot has been demonstrated to management using screenshots taken from Odoo marketing material. The nearest community option, document_page from the OCA, gives hierarchical pages with revision history and stops there: no properties, no item views, no embedded records, no side panel on a sales order. If a wiki is a real requirement, it belongs in the licensing conversation on day one, not in the second month of a build when the budget is fixed.
Counting the writers and forgetting the readers
Every person who reads a private or workspace article needs an internal Odoo user, and internal users are the ones you pay for. A warehouse of forty operators reading work instructions is forty users, not a free audience. The usual answers are publishing genuinely public procedures to the web, putting customer facing material behind Helpdesk, or accepting the seat cost with open eyes. Do this arithmetic before you promise the whole company a wiki.
Permission surprises after a move
Access is inherited down the branch, so dragging an article to a different parent silently changes who can read it. The two common incidents are a Private draft moved into Workspace and read by the whole company, and a restricted branch that stops being restricted because somebody tidied the tree on a Friday. Check the members panel after any structural change, and keep genuinely sensitive material out of the part of the tree that people reorganise.
Expecting a Confluence or Notion importer
There is none. Migration is a manual or scripted exercise: the page tree has to be rebuilt, macros and source tool databases have no equivalent, internal links break, and attachments must be re-uploaded. Writing article records through the API is feasible for the body HTML and the parent relationship, and it will not reproduce the source formatting exactly. Budget the migration as content work with a named owner, not as a technical import that runs overnight.
Using it as the document store
Articles are HTML records, not files under version control. Every file and image you put inside an article becomes an attachment in the filestore, counted in your storage and copied into every backup, with no retention rule applied to it. Contracts, signed policies, drawings and anything with a legal retention period belong in Documents, with the article linking to them. The wiki explains what to do, the file store holds the evidence.
Publishing to the web without checking
Sharing an article to the web produces a link that opens without signing in, and anyone who receives it can pass it on. Unpublishing withdraws the URL, but it does nothing about a copy already taken or a page already indexed. Child articles and embedded content need the same review, and an internal price list or a customer name inside a pasted screenshot is a disclosure. Treat a published article like a website page, review it again after each edit, and keep a register of what is public so it can be audited.
What it works with
- + Helpdesk, where an article can be published to the help centre and resolution steps drop into a ticket from the side panel
- + Documents, which holds the files and the retention while the article holds the procedure
- + Sign, where a policy needs a countersigned acknowledgement rather than a page view
- + Employees, for onboarding paths and role specific handbooks reached from the employee record
- + Studio, for the point where a register outgrows properties and needs a real model with its own access rules and reporting
- + Website, for publishing selected articles under your own domain and design rather than a bare share link
- + Project and Quality, for work instructions read at the point the task is actually executed
Odoo Knowledge by country
Saudi Arabia (KSA)
A ZATCA Phase 2 runbook is the strongest first article here: certificate renewal dates, the split between clearance for standard invoices and reporting for simplified ones, and exactly what a cashier does when Fatoora rejects a document. Test Arabic in the editor before you commit, since mixed Arabic and Latin text in one paragraph needs checking, and keep personal data out of Workspace level articles given PDPL exposure.
United Arab Emirates
Corporate tax at 9 percent above AED 375,000 sits alongside 5 percent VAT and a multi year record retention duty, so the closing checklist and the FTA filing steps deserve an owner by name and a fixed re-read date. A group holding both mainland and free zone companies wants one filing article per entity rather than a single group page, because the tests that apply differ by entity and a merged page hides that. WPS salary file preparation is the next candidate.
India
Write down IRN generation through the invoice registration portal, the 24 hour window in which an IRN can be cancelled, and e-way bill generation and extension including who acts when a vehicle is delayed. Multi state operations want one article per GSTIN registration rather than a single national page, because place of supply treatment and state level practice diverge enough to produce real filing errors.
Pakistan
FBR digital invoicing runs through a licensed integrator, with sandbox testing before production credentials are released, so token handling and the sandbox to live cut over are worth recording while the detail is fresh. Name who holds each credential and when it expires. Urdu pastes cleanly into the editor, but keep titles in the script your staff actually type into a search box.
Turkey
The routing decision between e-Fatura and e-Arsiv turns on whether the counterparty is registered with the revenue administration, and that single rule is the most useful page a Turkish finance team can hold. e-Defter ledgers and their berat uploads run to their own deadlines, so a calendar article naming who uploads what pays for itself the first time that person is on leave. Check search behaviour with the dotted and dotless i, because casing differences change what a title match returns.
Germany
GoBD expects a Verfahrensdokumentation describing how records are created, processed and archived, and maintaining it as an article beats maintaining it as a Word file nobody can find. The approved version still has to be retained to the same standard, so export it to Documents when it is signed off and treat the article as the working copy. DATEV export steps and works council agreements are the next two pages.
France
The Toubon law requires documents that set out obligations for employees, or that are needed to do the job, to be available in French, so an English only procedure set is a legal exposure rather than an inconvenience. Articles hold one language each, so plan a French article per procedure linked to any English original. Put Factur-X handling and platform routing in writing ahead of the 2026 and 2027 e-invoicing phases.
United Kingdom
Making Tax Digital requires digital links between the systems that feed a VAT return, and HMRC expects a business to be able to describe that chain on request. One article mapping each hop, with an embedded view of the source records beside it, answers most of that conversation. The HMRC connection itself sits in the Enterprise UK localisation and has to be re-authorised periodically, so record which user holds it and when it was last granted.
Odoo Knowledge FAQs
We are on Odoo Community, what are the options?
Three, in order of cost. Install document_page from the OCA and accept flat hierarchical pages with history. Publish procedures as unlisted Website pages, which works for read only material and gives you nothing structured. Or move to Enterprise, which is the only route to properties, item views, embedded views and the record side panel. Pick on the strength of the requirement, not on the demo.
Can we import our Confluence or Notion pages?
Not with a supplied importer, because Odoo does not ship one. Articles are ordinary records, so the body HTML and the parent child structure can be written through the API, while internal links, attachments and any source specific macros or embedded databases have to be rebuilt by hand. Sort the source by last edited and last viewed before you budget anything. The list of pages people actually open is usually short, and the rest is a retirement decision rather than a migration line item.
Does it replace SharePoint or Google Drive?
No, and the useful question is which half of the job each side keeps. Knowledge holds the written process and the links out of it. The files stay where an owner, a folder structure and a retention rule can be attached to them, which is Odoo Documents or the platform you already run. Two habits keep the split honest: never let an article hold the only copy of anything, and link from the article to the file rather than the reverse, because the article is what somebody will search for at eight in the morning.
Can customers or suppliers be given access to one article?
Not individually. Knowledge has no per external user permission, and portal users do not reach the application at all. The choices are publishing the article to the web, which is open to anyone with the link, or moving the content to where external access already exists, such as a Helpdesk knowledge base or the portal view of the record the information belongs to.
Is there an approval workflow before an article goes live?
Not natively. An article is live to its audience the moment it is saved. Teams build the missing control from a status property, a named owner and a review date, then work a filtered item list of anything overdue or still in draft. Where an audit trail has to be stronger, the approved version is exported and signed as a document, and the article carries the link to it.
Does the search look inside attached files?
Knowledge search matches article titles and body text, across the articles the person searching is allowed to read. It does not read the contents of an attached PDF or spreadsheet, so a procedure that exists only inside an attachment is invisible to the person who needs it. Write the steps into the body and keep the file alongside as the source. This is the single strongest argument for writing procedures out rather than attaching last year's document.
How do we handle a bilingual team?
An article holds one language, so the practical pattern is one article per language, linked to each other, with the language visible in the title so search separates them. Give each language version its own owner. A translation that quietly stops tracking the original is worse than no translation, because somebody will follow it during an audit and be wrong with confidence.
Can we prove that an employee read a policy?
Not from Knowledge, which does not keep per user read receipts. Where proof is needed, send the policy through Sign for a countersignature, or use a short Survey with the acknowledgement recorded against the employee. The article stays the living version of the text, and the signed record becomes the evidence for what the text said on a given date.