Unique AI Documentation

How to set up personal Knowledge Bases

4 min read

Overview

Implementation Managers

Use this when a customer wants a shared Knowledge Base folder, with one private folder per person. Each user manages only their own folder. Nobody except admins should upload, edit, or create folders in the parent.

You set this up. Users cannot create their own folders in the parent. Creating a folder needs Write on the parent, and Write also lets them upload there.

What you need

You need chat.admin.all, chat.knowledge.read, and chat.knowledge.write.

Each end user needs chat.knowledge.read to open Knowledge Base, and chat.knowledge.write to upload into their folder. Folder access alone is not enough.

Roles: Understand Roles and Permissions

Target setup

Knowledge Base              (app root, already there)
  └── Knowledge Base        (parent: All Company can view only)
        ├── Alice           (Alice can manage)
        └── Bob             (Bob can manage)

Create a new folder under the app root. Do not use the app root itself. It often already has All Company write.

Folder

All Company

The user

You

Parent (/Knowledge Base)

View / Read only

Nothing extra

Manage

Personal folder

No access

Manage, that person only

Optional. Remove yourself if they want it fully private.

All Company is labelled All Company in the UI. In the backend it is Root Group.

Two rules (both cases)

  • Create every personal folder as Private. Shared copies the parent access, so everyone would see everyone else's folder.

  • When you give All Company view on the parent, leave Apply to all subfolders unchecked. Otherwise you open every personal folder.

Users need view on the parent so they can click into their folder. Without it they can only find it through Search.

More on Private vs Shared: Personal Knowledge Folders

Which section you follow depends on FEATURE_FLAG_ENABLE_TIERED_ACCESS_PERMISSIONS_UN_13846.

Flag on: tiered access

The Access panel shows one dropdown: Can view, Can edit, Can manage. You pick one role. The UI then stores the stack behind it.

You pick

What gets stored

Can view

READ

Can edit

READ + WRITE

Can manage

READ + WRITE + MANAGE

If you later drop someone from Can manage to Can view, the UI also removes Write and Manage. You cannot set a custom mix (Write without Read) in this mode.

UI

  1. In Knowledge Base, create a folder named Knowledge Base. Set it to Private.

  2. On that folder, add All Company and pick Can view. Leave Apply to all subfolders unchecked. If they already show Can edit or Can manage, change them down to Can view.

  3. Inside the parent, create a folder for the person. Set it to Private.

  4. On that folder, add the user and pick Can manage.

  5. Repeat for each person. Do not give them Can edit or Can manage on the parent.

API

Public Folder API, version 2023-12-06. Tokens: Managing scopes & access via API

To match the UI, send the full stack. Can view is READ only. Can manage is all three types. The API does not fill in Read or Write for you.

Authorization: Bearer <token>
x-api-version: 2023-12-06
Content-Type: application/json

Find the user: GET /public/users?email=alice@company.com

Create the parent:

json
POST /public/folder
{
  "paths": ["/Knowledge Base"],
  "inheritAccess": false
}

Give All Company Can view on the parent only. Get the group id from the Access panel. If they already have Write or Manage, remove those. Adding Read does not drop the others.

json
PATCH /public/folder/add-access
{
  "folderPath": "/Knowledge Base",
  "applyToSubScopes": false,
  "scopeAccesses": [
    { "entityId": "<all-company-group-id>", "entityType": "GROUP", "type": "READ" }
  ]
}

Create the personal folder, then give that user Can manage (all three types):

json
POST /public/folder
{
  "paths": ["/Knowledge Base/Alice"],
  "inheritAccess": false
}

PATCH /public/folder/add-access
{
  "folderPath": "/Knowledge Base/Alice",
  "applyToSubScopes": false,
  "scopeAccesses": [
    { "entityId": "<alice-user-id>", "entityType": "USER", "type": "READ" },
    { "entityId": "<alice-user-id>", "entityType": "USER", "type": "WRITE" },
    { "entityId": "<alice-user-id>", "entityType": "USER", "type": "MANAGE" }
  ]
}

Check with GET /public/folder/info?folderPath=/Knowledge Base and the same for /Knowledge Base/Alice.

Flag off: checkboxes

The Access panel shows three independent checkboxes: Can read, Can write, Can manage. Nothing is implied. Tick exactly what you want stored.

You tick

What gets stored

Can read

READ

Can write

WRITE only, unless you also tick Can read

Can manage

MANAGE only, unless you also tick the others

Always tick all three for the folder owner. Can write without Can read means they can upload but cannot see the folder. Can manage without the other two means they can change access but may not see or edit files.

UI

  1. In Knowledge Base, create a folder named Knowledge Base. Set it to Private.

  2. On that folder, add All Company and tick Can read only. Leave Can write and Can manage off. Leave Also add access to all subfolders unchecked. If they already have write or manage, revoke those two and keep Can read.

  3. Inside the parent, create a folder for the person. Set it to Private.

  4. On that folder, add the user and tick Can read, Can write, and Can manage.

  5. Repeat for each person. Do not give them write or manage on the parent.

API

Same endpoints as above. Send only the types you want. Adding Read does not remove Write or Manage.

Authorization: Bearer <token>
x-api-version: 2023-12-06
Content-Type: application/json

Find the user: GET /public/users?email=alice@company.com

Create the parent:

json
POST /public/folder
{
  "paths": ["/Knowledge Base"],
  "inheritAccess": false
}

Give All Company Can read on the parent only. If they already have Write or Manage, call remove-access for those types.

json
PATCH /public/folder/add-access
{
  "folderPath": "/Knowledge Base",
  "applyToSubScopes": false,
  "scopeAccesses": [
    { "entityId": "<all-company-group-id>", "entityType": "GROUP", "type": "READ" }
  ]
}

PATCH /public/folder/remove-access
{
  "folderPath": "/Knowledge Base",
  "applyToSubScopes": false,
  "scopeAccesses": [
    { "entityId": "<all-company-group-id>", "entityType": "GROUP", "type": "WRITE" },
    { "entityId": "<all-company-group-id>", "entityType": "GROUP", "type": "MANAGE" }
  ]
}

Create the personal folder, then send all three types for the owner:

json
POST /public/folder
{
  "paths": ["/Knowledge Base/Alice"],
  "inheritAccess": false
}

PATCH /public/folder/add-access
{
  "folderPath": "/Knowledge Base/Alice",
  "applyToSubScopes": false,
  "scopeAccesses": [
    { "entityId": "<alice-user-id>", "entityType": "USER", "type": "READ" },
    { "entityId": "<alice-user-id>", "entityType": "USER", "type": "WRITE" },
    { "entityId": "<alice-user-id>", "entityType": "USER", "type": "MANAGE" }
  ]
}

Check with GET /public/folder/info?folderPath=/Knowledge Base and the same for /Knowledge Base/Alice.

Check it

As the end user:

  • They can see the parent, but cannot upload or create folders there.

  • They only see their own personal folder.

  • Inside it they can upload and change access.

  • They cannot open someone else's folder.

Last updated