Two access layers
Every permission in Bambu OS lives in exactly one of two layers. Keep them straight and access stays auditable as portals multiply.Who can open each portal: domain grants & fund scoping, companies & roles, per-user overrides, console administrators. Enforced at sign-in by auth.js + Cloudflare Access.
What a user can see and do once inside: an LP's invested funds (Investor), the Moelis allow-list, DMS members & folder grants, CRM deal ownership. Enforced by each portal.
Investor · Moelis · Documents · CRM · Other portals
Portal registry
Live cross-check of the OS chooser against this console. Every portal card must carry adata-portal key (or every role can see it) and every key must be grantable in
Portal Access. New portals that skip a registration step show up here.
Saving Portal Access rebuilds the CF Access allow-policy for Bambu OS in one step
(via CF_ZT_TOKEN). The save toast confirms each sync.
Document Management trusts your Bambu OS sign-in — members managed in Document Access, folder & document grants in Doc Mgmt ↗.
Every save commits a config file to GitHub; deploy-os republishes the OS.
Changes reach every portal in ~90 s.
agent-access.js · portal-config.js · access-roles.js ·
companies.js · team.js · crm-cloud.js — each owned by one
section of this console, each versioned in git (the audit trail).
Portal Access
Grant external placement agents, IR consultants, or co-investors access to specific portals by domain. Each row is a domain — check the portals that domain is allowed to open. For fund-aware portals (Internal, Investor, PortCo, Model, Thesis, Fundraising) a fund selector appears under the check: restrict that domain to All funds, Fund I, or Fund 0. Use the 🔒 Emails button on a row to lock specific portals to specific people within that domain. Individuals still need a Cloudflare Access account; this sets their permission level once they're through the gate.CF_ZT_TOKEN set as a CF Pages environment secret.
- Go to dash.cloudflare.com → My Profile → API Tokens → Create Token → Custom → permission:
Zero Trust: Edit→ Account resource: Bambu Capital. - In the CF dashboard go to Workers & Pages → bambu-os → Settings → Environment variables → Add: name
CF_ZT_TOKEN, value = the token above. Set for Production + Preview. Save. - Redeploy (any commit to main triggers it).
- Come back here, save again — the note above will turn green.
| Domain | Public Site | New Public | Internal | Investor | PortCo | Model | Thesis | Data Room | Doc Mgmt | Fundraising | Moelis | CRM | Tools | Wallet | Admin |
|---|
Companies & Roles
Name each company (by domain) and define the roles people in it can hold. A role sets which portals it opens and a test persona for the View as switcher. Roles are grouped by company; the All scope holds global roles that apply across every company — any role you create also appears under All. Changes drive both the View-as switcher and the real sign-in access (a role's portals = what that role can open).People
The administrators who can use this console and the View as switcher. Per-user portal access is now granted via Companies & Roles (per-email Access Roles) — the legacy per-user override store was retired. The firm's team roster lives under Portal permissions → CRM — deal ownership is a CRM-internal permission, not an OS gate.Investor Portal — LP fund access
Portal permission Which funds each LP is invested in and may see inside the Investor Portal — the fund toggle offers only permitted funds and deep links to others are refused. Whether the LP can open the portal at all is the OS-access layer; a per-user fund override there narrows this list, never widens it. Saves commitassets/lp-access.js and reach the portal in ~90 s.
Moelis — email allow-list
Portal permission The Moelis Scenario model is the most confidential surface in the OS. When this list has entries, only these people (plus console administrators) see and open it — everyone else loses the card even if their role grants Moelis. Empty list = open to every internal role its OS access allows. The list is stored on the domain grants (emails.scenario) — the same data as the 🔒 Emails drawer in Portal Access; saving here re-syncs Cloudflare Access and reloads the console.
CRM — team & deal ownership
Portal permission The firm's people registry — the single source of truth for deal ownership in the CRM. Owner dropdowns (deal record, create deal, bulk reassign) and avatars read this list. Who can open the CRM at all is the OS-access layer. Edits commit to GitHub and reach every portal on the next deploy (~90 s).Team members
Deal owners — live CRM book
Document Access
Members & access for the Document Management system (Portal 11) — fully managed from this console with your Bambu OS sign-in. Approve pending LP signups, set each member's company and role (admin / manager / lp), suspend or reactivate, invite new members, and create companies. Every action is recorded in the DMS audit trail under your name. Folder- and document-level grants live one click away in Doc Mgmt (same sign-in).Other portals — where their permissions live
Not every portal has a separate in-portal permission store. This is the honest map of what governs each remaining surface, so nothing is hidden in code.Fund-scoped only. What a user sees inside is governed by the fund selectors on their domain grant or per-user override (All funds / Fund I / Fund 0). No separate in-portal store.
Company-scoped workspace. Each portfolio-company exec sees only their company's workspace; the demo binds the workspace to the active fund. A per-exec company mapping becomes a panel here when real PortCo logins land.
Own credentialed membership. LP members, companies & roles are managed in Document Access; folder- and document-level grants in Doc Mgmt ↗ (same sign-in). Deny-by-default.
Public is public. The marketing site has no permissions; the CMS editor (edit.bambu-capital.com) is gated by its own Cloudflare Access policy plus the New Public grant for card visibility.