How the EspoCRM knowledge base supports support teams and the portal
A support lead who wants customers to find answers before they open a case needs the knowledge base to do two jobs at once: publish the right article to the right audience, and keep stale guidance out of view. In EspoCRM, an article is shown in a portal only when its status is Published and it is assigned to that portal. Those two conditions are the first thing to check when a customer says an article is missing, and the portal user's role must also grant access to the Knowledge Base. Confirm the exact status labels and role permission names in your own EspoCRM version, since the menu wording can differ between releases.
Expiration is the control that keeps the portal honest over time. Once an article's Expiration Date passes, EspoCRM hides it automatically, so a pricing note, a retired integration guide or a time-limited outage workaround stops appearing without anyone deleting it. Plan who owns review dates for each article family before go-live, because an expiration date that nobody set leaves the article visible indefinitely. Ordering controls how the remaining articles are sorted, which matters when several answers cover the same question. Test the portal as an external user after each change, not only as an administrator, because administrators see records that customers never will.
Articles can also be associated with Cases, so an agent handling a ticket can attach the answer they already gave and the customer can find the same guidance later through the portal. This link is what turns a knowledge base into a deflection tool rather than a separate wiki, and it also shows which articles actually resolve cases. A team needs this setup when it has repeat questions, several support agents answering the same issues, customers who must self-serve outside business hours, or guidance that changes often enough to need expiration. A simpler approach, such as a short static FAQ page or a few pinned case templates, is enough when the product is small, questions are rare, and only one person writes answers.
Knowledge Base configuration options and when each fits
This table compares the six configuration choices that decide who sees a Knowledge Base article, for how long, and where it appears in a case. Read each row as a separate setting, then check the fit column against your customer, partner and internal support model. The main takeaway is that portal assignment and portal role access decide visibility, while status, expiration and case association decide whether an article stays useful.
| Configuration | What it controls | When it fits |
|---|---|---|
| Status | Whether an article is Published or still in draft. Only published articles can reach a portal. | Use drafts for articles under review by support or legal. Publish only after the owning team has approved the text. |
| Portal assignment | Which portal shows the article. An article appears only in portals it is assigned to. | One portal fits a single customer audience. Several portals fit separate audiences such as end customers and channel partners, with articles assigned to each. |
| Expiration date | The date after which EspoCRM hides the article automatically from portals. | Set it for time-bound content such as temporary service notices, promotional terms or release-specific steps. Leave it empty for evergreen guidance. |
| Ordering | The sequence in which articles are listed, so the most important answers appear first. | Useful when a portal has a short set of top-task articles. Confirm in your EspoCRM version how ordering is set and whether it applies per portal. |
| Case association | Links an article to one or more cases so agents can find and reuse it while handling a request. | Fits support teams that resolve repeat issues. Associate articles with the case types they resolve so agents do not rely on memory or search alone. |
| Portal role access | Which portal users can read Knowledge Base content, based on the portal role they hold. | Use separate roles when some customers should see restricted guidance, such as partner pricing steps. Test each role with a sample portal user before launch. |
Designing article content, ownership and review before the build
Knowledge base articles are only as useful as the structure behind them. The decisions below determine which articles exist, who keeps them accurate, and when they stop appearing to customers. Settle them on paper before creating any article, portal assignment or case link.
Article categories and portal grouping
Decide the category set first, because it becomes the navigation customers see in each portal. Keep categories tied to what customers ask, such as account access, billing, or product setup, rather than to internal departments. Check that each article can sit in one category and that every portal you run gets only the categories its audience needs. Renaming categories later changes what customers search for, so agree on names with the support lead before publishing.
Named owner for each article
Every article needs one accountable owner who answers for accuracy, not just the author who drafted it. Record the owner in the article record so that a stale article can be traced to a person and a team. Decide what happens when the owner leaves or changes role, and who inherits their articles. Without this step, articles about retired features tend to stay published because nobody is responsible for removing them.
Review cadence tied to expiration dates
Set expiration dates as the enforcement mechanism for review. EspoCRM hides an article automatically after its Expiration Date, so the date should match how long the underlying product behavior is expected to hold. Decide a standard review window per category, for example shorter for pricing or release-specific steps and longer for stable policies. Agree who receives the reminder to renew before expiry, because an expired article disappears from the portal without warning.
Mapping articles to recurring case types
List the case types your team handles repeatedly and identify the article that answers each one. Link articles to those cases so agents can find the right answer during triage and reuse it in replies. Check for case types that have no article, which show where knowledge is missing, and for articles linked to no case type, which may be duplicates or outdated. Keep the mapping in a simple register so reviewers can see which cases depend on each article before changing it.
Separating drafts from published content
Use the article status as the boundary between work in progress and customer-facing content. Drafts should never be assigned to a portal, so customers cannot see them even when they are partly written. Define who may move an article from draft to published, and whether a second reviewer must approve it. Confirm the status values and portal assignment rules in your installed version before writing the process, because the exact behavior is the point where mistakes reach customers.
Access rules for portal roles
Decide which portal roles can read each category before building the portal. Customers, partners and internal staff often need different views of the same knowledge, and internal troubleshooting notes should not reach an external portal. Map each audience to the articles it may see and test that a user in each role sees only that set. Confirm the role configuration options in your EspoCRM version, since access mistakes are the most costly error in this area.
How to set up Knowledge Base publishing in EspoCRM
This sequence takes a test instance from a disabled or unchecked Knowledge Base to a published, expiring article linked to a case and visible only to the right portal users. Each step ends with a check, so you can confirm the behavior before you publish real help content.
Confirm the Knowledge Base module is enabled
An administrator confirms that Knowledge Base is active on the instance and appears in the navigation for a test internal user with an admin role. Menu locations can differ between EspoCRM versions, so check the current path in your release against the EspoCRM Knowledge Base documentation. The step is complete when that test user can open the Knowledge Base list view and create a draft record without an error message. If the entity is missing, fix the module setting before you continue, because later steps depend on it.
Set up the portal and its roles
An administrator creates or selects the portal that will serve help content and assigns it a portal role. Grant that role read access to Knowledge Base only, and confirm it does not allow editing or publishing articles. Keep the role narrow, because portal users should see published help and nothing else. Confirm the exact permission labels in your version, since the names in the role editor may vary. The step is complete when a portal test user with this role can sign in, reach the portal home page, and see an empty Knowledge Base area, which is expected before any article is published.
Create a test article
An internal administrator creates a new article with a clearly labeled title, such as "KB test article (illustrative)", and adds a short body. Leave the status as Draft so the article stays hidden from the portal while you build the test. Record the article ID or name in your test log so you can find it in each later step. The step is complete when the article saves, appears in the internal Knowledge Base list with a draft status, and does not appear when you sign in as the portal test user.
Publish and assign the article to the portal
The administrator changes the article status to Published and selects the portal in the field that assigns the article to a portal. Save the record and confirm the assignment is stored. Per the EspoCRM documentation, an article is shown in a portal only when it is both Published and assigned to that portal, so both conditions must be met. The step is complete when the internal list shows the article as published and linked to the test portal, and the portal test user can now see it in the Knowledge Base area.
Set an expiration date on a test article
The administrator sets an expiration date on the published test article and saves it. Then create a second test article with a past expiration date to see the hidden behavior immediately, since EspoCRM hides articles automatically after the expiration date. Confirm that the first article still shows in the portal before its date and that the second one is hidden. Check how your instance treats past dates on save, because validation rules can vary. The step is complete when you have recorded which article is visible and which is hidden as the portal test user sees them.
Associate the article with a test case
An internal user opens a test case and links the published article through the Knowledge Base relationship on the case. Confirm the exact field or relationship panel name in your version. The link lets agents attach help content to a customer case, which is the main reason to associate articles with cases. Check the link from both sides: the case should list the article, and the article should show the related case. The step is complete when both records show the link, and the test case still saves normally with the article attached.
Verify visibility as a portal user
Sign in as the portal test user assigned to the portal role and review the Knowledge Base area. The published article should appear, while the draft and the expired article should not. If you created an article assigned to a different portal, confirm it is also hidden here. Check the order in which articles appear and compare it with the ordering field in the article record, since ordering behavior should be confirmed in your version. The step is complete when you have a written visibility matrix for each test article as a portal user.
Verify visibility as an internal user
Sign in as an internal test user with the access level you expect for support agents and confirm they can see all test articles, including drafts and expired ones, according to their permissions. Open the test case and confirm the linked article displays correctly. Then edit the published article, save it, and reload the portal as the portal test user to confirm the change appears. The step is complete when the internal and portal results match your intended access model, and you have saved the matrix with the test date, the user and the result for each article.
How support, content owners and administrators use the knowledge base
Support agents use the Knowledge Base while working a case. Their job is to find the article that answers the customer's question, link it to the case so the history is recorded, and send the customer to the right answer without rewriting it each time. They need search that returns articles they are allowed to see, and a fast way to attach an article to the case they are working on.
- Searching by topic: agents look up articles by subject, keyword or product area before drafting a reply.
- Linking articles to cases: a linked article shows which answer was given, which helps when the case is reviewed or reopened.
- Spotting stale content: when an article no longer matches the product, agents should flag it to the content owner instead of working around it.
- Seeing internal-only material: agents may read articles that are not in any customer portal, so the role they hold determines what they can link.
- Confirming access: check with the administrator which entities and fields agents can use when linking, since permissions are set per role.
Before relying on this workflow, confirm in a test instance that the case layout exposes the article link for your support role.
Content owners write, review and retire articles. They decide when an article is ready to publish, which portal it belongs to, and when it should stop appearing. Their work is ongoing, because every product change can make an article wrong. They need a clear status model, a review routine and a way to set end dates so outdated guidance is hidden without manual cleanup.
- Publishing status: an article shows in a portal only when it is Published and assigned to that portal, so drafts stay out of view until review is complete.
- Expiration dates: an article is hidden automatically after its Expiration Date, which suits time-limited guidance such as a version-specific procedure.
- Ordering: owners arrange articles so the most common answers are easy to find within a category.
- Review cycles: agree how often each article is checked against the current product, and who signs off changes.
- Retirement: remove or unpublish articles that no longer apply, and record why, so the change is traceable.
Ask your implementation partner to confirm how article ordering and expiration behave in the EspoCRM version you run, because these details are documented in the knowledge base guide.
Administrators decide which audiences can read which articles. They configure the portals, assign articles to them, and set the portal roles that control access to the Knowledge Base. Their work is mostly setup and periodic review, but mistakes here expose internal content to customers or hide public answers from them, so the access model needs to be designed before content is loaded.
- Portal setup: create the portal, decide its audience, and confirm which articles are assigned to it.
- Portal roles: grant Knowledge Base read access to portal users only where the business requires it.
- Separation of duties: keep article authors, publishers and administrators distinct where your controls require it.
- Access reviews: check role assignments on a set schedule and after staff or customer changes.
- Testing as a portal user: log in as a representative customer account to confirm that only published, assigned articles appear.
Before go-live, document the access matrix and ask your security team to review it against your data classification rules, since portal visibility is the main control here.
Protecting unpublished content and portal access
A knowledge base only helps support when the right articles reach the right people. The risks below share one root cause: visibility in a portal depends on several settings working together, and a mistake in any one of them can expose content. Check each control and test it from a portal user account.
Draft and internal articles leaking
An article reaches a portal only when it is Published and assigned to that portal. Internal runbooks, pricing notes and drafts are often created in the same entity, so a missing status or portal assignment is the usual cause of exposure. Before launch, confirm which articles carry the portal assignment, and keep internal material in a separate article set that is never assigned to a portal. Review new articles against this rule as part of your publishing process.
Overly broad portal roles
Portal users are governed by the portal role assigned to them, and that role determines which entities and fields they can read. A role that grants wide read access to other entities can expose customer records alongside articles, even when the articles themselves are correct. Build the portal role from the minimum needed to read published articles, and list every entity the role can read before go-live.
Stale articles still visible
Articles do not disappear on their own once their content goes out of date. Setting an Expiration Date hides an article automatically after that date, but only if the date is entered. Decide who owns each article, how often it is reviewed, and which expiration date applies to time-bound content such as pricing or product versions, so that outdated guidance does not keep reaching customers.
Testing access with a portal user
Administrator views show everything, so they cannot confirm what a customer sees. Create a dedicated test portal user with the same portal role as real customers, then check that published articles appear, drafts and internal articles do not, and expired articles are hidden. Repeat the check after any change to roles, portals or article status. Ask your implementation partner to include this test in the acceptance criteria.
Shared access model with roles and teams
Portal visibility sits on top of the broader access model of roles, teams and user types. Users who hold internal roles, or who move between internal and portal accounts, can carry permissions you did not intend to give a customer. Review how internal roles, teams and portal roles interact, and use the EspoCRM roles, security and access topic to plan those rules before you assign portal users.
Questions teams ask before setting up the EspoCRM knowledge base
How much effort does an EspoCRM knowledge base setup take?
The effort depends mostly on how many portals you run, how many article types and categories you need, and how much existing content must be moved in. A single portal with a short list of help topics is a small configuration task. Several portals with different audiences, article review rules and case linking take more design and testing. Ask any partner to split the quote into configuration, content structure, access testing and training, so you can see which part of the effort your team could absorb.
What drives the cost of an EspoCRM knowledge base project?
Cost follows the design decisions that the work must cover. The main drivers are the number of portals and their audiences, the number of roles that need different visibility, the volume and quality of existing help content, links between articles and cases, and the review process your support leaders want. One-time work includes design, configuration and content migration. Recurring work includes publishing, reviewing expiration dates and adjusting access as staff change. Ask for each cost line to name who performs it and whether it is one-time or ongoing.
How long does an EspoCRM knowledge base setup usually take?
The timeline depends on scope, not on the EspoCRM feature itself. Publishing articles to a portal is quick to configure once the portal exists, so most of the calendar time goes to deciding who sees what, writing or migrating content, agreeing on review and expiration rules, and testing as each portal role. Delays usually come from waiting on approvals for content or from unresolved questions about which team owns each topic. Ask for a written plan with milestones and the client decisions each milestone depends on.
What does the work need from our support and IT teams?
Your support leaders must define the topics, the article owners and the review cycle, because those decisions shape the configuration. Your IT or platform team must provide a working EspoCRM instance, the portal domain, and access to a test environment where changes can be checked before go-live. Someone must also confirm which identity and access rules apply to portal users. Expect support staff to review draft articles and approve the final structure. Agree these responsibilities in writing before the build starts.
Can an internal EspoCRM administrator set up the knowledge base alone?
A trained administrator can configure the basics: create articles, set status to Published, assign them to a portal, add expiration dates and link articles to cases. Difficulty rises when the design needs portal role access that differs by audience, custom fields, or changes that touch layouts and workflows. Those changes need careful testing because a wrong role setting can expose internal articles. Confirm that your administrator has time for testing and that a second person can review permissions before anything is published to customers.
What changes when the knowledge base grows to many articles?
Growing content volume makes structure more important than the initial setup. Categories, ordering, naming rules and owner assignments must stay consistent, or customers will struggle to find answers and staff will publish duplicates. Expiration dates matter more because each expired article is hidden automatically, so a missed review can quietly remove guidance that customers still need. Plan a recurring review schedule, a list of article owners and a periodic check of which articles are linked to active cases. Ask for these practices in the handover documentation.
How do portal roles control what customers can read?
Knowledge Base articles appear in a portal only when they are Published and assigned to that portal, so portal assignment is the first control to check. Portal role access then determines which portal users can reach the Knowledge Base at all. Test each role with a sample portal user before launch, and confirm the exact permissions against the current EspoCRM documentation for your version. Internal-only guidance should live in a separate status or portal, and that separation must be verified rather than assumed.
What happens to articles after their expiration date?
An article with an Expiration Date is hidden automatically once that date passes, which keeps outdated guidance away from customers without manual removal. The risk is that nobody notices content disappearing, especially if a product change makes a topic relevant again. Ask your partner how expiration dates will be set for each article type, who receives reminders before they lapse, and how replacement articles will be linked to related cases. Confirm the behavior in your own test instance before relying on it for regulated or safety-related guidance.
How DeployOpen scopes and delivers a knowledge base setup
DeployOpen treats the EspoCRM knowledge base as part of the support process, not a publishing afterthought. We agree the article structure, portal access and case links in writing first, then build, test and hand over the setup inside infrastructure you control.
How we scope
- We agree in writing which portals, article categories and audiences the knowledge base must serve.
- We map which roles can view, create and publish articles, and which portal roles see published content.
- We confirm how expiration dates and case links will be governed, and who owns article review.
How we build
- We configure article statuses, portal assignment and expiration dates to match the agreed publishing rules.
- We set portal role access to the Knowledge Base and test visibility as each agreed role.
- We link sample articles to cases and check that support staff and portal users see the intended content.
How we hand over
- We document the publishing workflow, status meanings, expiration rules and portal access settings for your team.
- We walk your support leads through creating, reviewing, ordering and retiring articles on your own instance.
- We deliver a written configuration record so your administrators can audit and repeat the setup later.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask any partner to confirm how changes to portal access and expiration rules will be reviewed and tested.
