Permission Model Summary
Findable uses a single, consistent permission structure across the entire application. The previous chat-specific roles of owner / contributor / user have been fully removed. In their place, four app-level roles are configured in Admin → App Roles ([#/admin/roles]):
These roles map into three effective entitlement levels that flow through every entity in the system:
Permissions inherit automatically from app settings down through the entity hierarchy:
Access Control Model
Access is enforced at two layers:
App-level access is determined by the Access Control section in Admin → App Roles ([
#/admin/roles]):
- Owners (Administrators) — Full admin access including app settings (required; at least one must be configured)
- Content Managers — Can create and manage all shared entities (chats, pages, flows, prompts). Automatically treated as owners on all entities that inherit permissions from app settings, giving them full management access throughout the inheritance chain. Content Managers do not have access to admin settings pages.
- Default Contributors — Default contributor principals inherited by entities through the entitlement system. Entities that inherit permissions will include these contributors in their ACL. This is an ACL default, not a standalone app-level role.
- Users — Basic read/use access to the application
- Allow all authenticated tenant users — When enabled, all internal tenant users automatically receive User-level access without being explicitly listed. The Users picker remains visible so administrators can add guest or external users who need access. Guest/external users are not covered by this toggle — they must be added explicitly. When the toggle is off and no users or groups are configured, a warning appears: only Administrators and Content Managers will be able to access the application.
- Block external / guest users — When enabled, external users (identified by
#EXT#in UPN) receive a 403 regardless of any role assignments.
entitlementservice.ts). Each entity (chat, page, prompt, flow, etc.) has its own owners, contributors, and users principal lists. When allowAllAuthenticatedUsers is enabled, non-external tenant users also receive User (read) access to all shared-scope entities, even if they are not in the entity’s ACL. Entity-specific ACLs always take priority — if a user is listed as an owner or contributor on an entity, they keep that elevated role.
Roles
Note: “Default Contributors” configured in Admin → App Roles ([#/admin/roles]) are not a standalone role. They are ACL principals that are injected into thecontributorslist of entities that inherit permissions from app settings. A user who is only a Default Contributor does not get the Content Manager role — they only appear as a contributor on inheriting entities.
Content Manager Inheritance
Content Managers receive ownership through the ACL inheritance chain, not through an admin bypass flag. The entitlement service merges Content Managers into theowners principal list at the app-settings level. This propagates naturally:
Per-Field Inheritance
Entities support granular inheritance control via theinheritEntitlements field:
This allows patterns like:
- Inherit owners and users from the parent page, but set custom contributors on a specific chat
- Override only the users list while keeping owners and contributors inherited
IEntitlementInheritance interface on chats, pages, prompts, flows, and all other entitled entities.
Hide from Catalog
Every entitled entity (chats, prompts, prompt groups, pages, flows, datasources, MCP servers, tools, AI search/model endpoints, etc.) supports an optionalhideFromCatalog: boolean field on IEntitledEntity / EntitledEntityBase.
Where it applies:
- Entitlement service (
entitlementservice.getEntitledEntities()) — automatically filters hidden entities out ofuser-only results so they never appear in any endpoint built on top of the service. - AI Recommendation service (
recommendationService.ts) — applies a stricter rule: hidden entities are dropped from the prompt / chat / page catalogs sent to the LLM for everyone (including admins and owners), so they are never recommended as a starting point.
- Flow-internal prompts (entry prompts referenced by
entryPromptId) that are never invoked directly. - Repeater sub-prompts referenced by parent prompts via
promptTemplateId. - Admin-only or backend / 2nd-tier entities that should not pollute end-user discovery surfaces even when a viewer happens to be entitled to them.
Navigation Drawer (Pages, Chats, Groups)
Per-entity checks use the
owner, contributor, and unsecured flags from IEntitledEntity (computed server-side by the entitlement service).
Flow Designer
Admin Pages
Admin pages are split into two categories: Settings pages (modifyappSettings) — Admin only:
AI, Sources, Security, Profile Sync, Memory, Feedback, Notification Providers, Look & Feel, SharePoint Entitlement, Translations, System Health, Bootstrap Assets, Chat History, Feedback Analysis
Entity list pages (CRUD on individually permissioned items) — Admin + Content Manager:
Model Endpoints, AI Search Endpoints, Database Connections, MCP Servers, Tools Registry, Flow Designer