Keep each audience's knowledge in its own project
Your customers should not be answered from your HR policy, and one client's runbook should never turn up in another client's answer. Projects keep the boundaries clear without running separate systems.
- Own sources, widget and keys
- Customer-tagged content
- Team chat across all of them
What is a knowledge project in SupaCortex?
A project is a self-contained body of knowledge inside your workspace - one per product, team, audience or client. Each project has its own documents and feeds, its own chat widget and settings, its own connector to your systems, and its own grants on API keys. A question asked through a project's widget or through an API key is answered only from the projects that channel is allowed to reach.
- Each workspace has its own business database and a separate vector database.
- A project key (a short slug) names the project in the widget and the API.
- API keys are limited to the projects you choose.
- Documents can carry a customer ID, so one customer's content is answered only for them.
- Team chat searches every project, or one, and every citation names its project.
- Admins create projects; Editors manage documents and feeds; Viewers ask.
Setting up a project
-
01
Create it
Give it a name and a key such as "billing-help" or "client-acme". The key never changes, so snippets and integrations keep working.
-
02
Fill it
Upload files, add a website or Drive feed, or approve answers mined from past tickets. Each source can set a category, tags and a trust tier.
-
03
Open a channel
Switch on the project's widget, grant an API key to it, or point your help desk at it for reply drafts.
-
04
Watch it answer
Conversations, ratings and unanswered questions are kept per project, so you can see which documents are missing.
Where the boundaries are drawn
One project per audience
The simplest rule that works: if two groups of people should never see each other's answers, give them two projects.
- A public help-centre project for the website widget, and a separate internal project for staff policies.
- One project per client for an MSP, so each client's runbooks answer only that client's people.
- One project per product line for a manufacturer or a SaaS company with several apps.
- Each project has its own widget title, colour, greeting and allowed websites.
Anything indexed into a project can be answered for anyone who can ask that project - including visitors of a public widget. Keep internal material out of public projects.
Customer-specific content inside a project
Sometimes the split is not by audience but by account: the same product, with one customer's contract or configuration on top.
- Tag a document, a pushed record or a whole feed with a customer ID.
- Tagged content is searchable only when that customer is asking; shared content is searchable for all.
- In the widget, the customer comes from a token your backend signs - never from what the user typed.
- With no customer in the request, only shared content is searched.
Keys, connectors and plans per project
Everything that can reach knowledge or your systems is tied to a project, so it can be granted and revoked one at a time.
- An API key lists the projects it may use; any other project answers "not found".
- Each project has its own connector to your systems and its own custom API endpoints.
- Projects per plan: 1 on Starter, 5 on Growth, 20 on Business, unlimited on Enterprise.
- A project cannot be deleted while it still holds documents, so nothing disappears by accident.
Related
Questions people ask before they start
Sketch your projects on one page. We will set them up with you.
Book a 30-minute demo on your own documents. We set up a 14-day trial workspace for you - no credit card, no setup fee.
Questions first? Email info@greatdevelopers.com or call +91 8585953085.
ChatGPT
Claude
Perplexity
Grok