Skip to main content
PORTAL is the client-facing surface of CyberOS. If you run a consultancy, agency, or professional services firm, PORTAL gives each of your clients a branded web portal where they can see the projects you are running for them, review and pay invoices, access signed contracts, and ask a branded AI assistant questions grounded in their own project history — all without ever seeing the CyberOS product name unless you want them to. Every client’s view is isolated from every other client at three independent layers, and clients log in through their own identity provider so you never manage their passwords.
PORTAL is a P4 module. Contact sales for early access.

What clients see in their portal

Projects (PROJ)

All PROJ projects where the client’s Engagement is the parent, filtered to items marked client-visible. Clients see status, milestones, and progress — not internal comments or private issues.

Invoices (INV)

All invoices scoped to the client’s account, with outstanding balance, payment history, and a direct pay link to Stripe or VietQR. Clients never see invoices for other accounts.

Documents (DOC)

Signed contracts and agreements the client is party to. Clients can view signing status, download executed copies, and see personalised signing links for documents awaiting their signature.

CHAT threads

Any CHAT threads the client is a member of — typically threads for project updates or support conversations started from the portal itself.

Branded AI assistant

A CUO variant pre-loaded with the client’s project history. Clients can ask questions like “What’s our SOW spend so far this quarter?” and receive grounded answers with citations to the actual invoice or project data.

White-label branding

Your clients see your brand in the portal, not CyberOS.

Custom subdomain

By default, your client portal is available at clients.<your-slug>.cyberos.world. To use your own domain:
1

Claim your CNAME

In Settings → Portal → Branding, enter the domain you want to use (e.g. portal.acmecorp.com). The system issues a DNS TXT challenge for ownership verification.
2

Add the DNS TXT record

Add the provided TXT record at your DNS provider under _cyberos-challenge.<your-domain>. This proves you own the domain.
3

Verify and activate

Click Verify in the portal settings. CyberOS validates the TXT record, requests a TLS certificate from AWS ACM, and activates your custom domain. The process takes approximately 3–5 minutes after DNS propagation.

Brand pack

Configure your brand pack in Settings → Portal → Branding:
Upload your logo (SVG or PNG, max 2 MB). Displayed in the portal header and client-facing email templates. SVG files are sanitised automatically.
accent_color
string
Your brand’s primary colour as a hex code. Used for buttons, links, and highlights throughout the portal.
typography_pack
string
default:"Inter"
Font family for the portal UI. Supported packs: Inter, Plus Jakarta Sans, Geist, DM Sans.
email_templates
object
Override the default transactional email templates (invite, invoice notification, document signing) with your own branded versions.
powered_by_cyberos
boolean
default:"false"
Show or hide the “Powered by CyberOS” attribution in the portal footer. Defaults to hidden — your brand is front and centre.

Client authentication via their own IdP

Clients log in through their own identity provider. You configure the connection once per client; after that, their IdP manages all access — including removals.

Supported protocols

  • SAML 2.0 — works with Okta, Azure AD, Google Workspace, OneLogin, Ping Identity, and any other SAML 2.0-compliant IdP
  • OIDC — works with Okta, Azure AD, Google Workspace, Auth0, and any OIDC-compliant IdP

Configuring a client’s IdP

1

Add the client account

In Settings → Portal → Clients, click Add Client. Enter the client’s organisation name and slug.
2

Configure their SSO

In the client’s settings, select SSO → Configure SAML or Configure OIDC. Enter their IdP metadata URL (for SAML) or their discovery URL (for OIDC). The portal generates an Assertion Consumer Service (ACS) URL to give to the client’s IT team.
3

Test the connection

Click Test SSO. You are redirected to the client’s IdP login page. A successful login confirms the configuration.

JIT provisioning

When a client user logs in for the first time, the portal automatically creates their account (a ClientMember) using attributes from the SSO assertion — typically email address, display name, and role. You do not need to pre-create user accounts. Role mapping is configured in the client’s SSO settings. If the IdP assertion does not contain a recognisable role claim, the user is provisioned with the lowest-privilege viewer role by default.

No orphan accounts

When you remove a user from the client’s IdP (or the client offboards an employee), their next login attempt is denied automatically. There is no separate step required on the CyberOS side. For clients using SCIM 2.0, deprovisioning events revoke the session within 30 seconds.

Data isolation

Each client’s portal data is isolated from every other client at three independent layers: The three-layer approach means a single misconfiguration at any one layer is caught by the other two.

Setting up a client portal

1

Configure your brand pack

Set your logo, accent colour, and typography in Settings → Portal → Branding. Optionally configure a custom CNAME (described above).
2

Add the client account

In Settings → Portal → Clients, click Add Client. Enter the client organisation name and assign the PROJ engagements, INV invoices, and DOC documents that should be visible to this client.
3

Set up the client's SSO IdP

Configure SAML or OIDC for the client as described in the authentication section above. The client’s IT team provides their IdP metadata; you enter it in the client’s SSO settings.
4

Invite the first client admin

For clients without SSO configured yet, or as a fallback, send a magic-link invite to the client’s primary contact. They log in, set up the portal, and can invite their colleagues once SSO is active.

Client-initiated workflows

Clients can initiate requests directly from the portal. Each request type materialises as a CHAT thread on your side and is automatically routed to the right Account Manager by CUO.
The client fills out a brief form describing the project they want to start. This creates a CHAT thread in your workspace tagged with the client account, pre-routed to their Account Manager.
The client flags a question about a specific invoice. This creates a CHAT thread linking directly to the invoice in question, routed to your finance team or their AM.
The client describes an issue or question about a running project. Creates a CHAT thread in the #<client>-portal channel, automatically routed to the responsible Account Manager based on CRM ownership.
Your team responds in CHAT as usual. If the client is a member of the thread, they see the response in their portal’s CHAT section.

Client lifecycle

1

Provisioned

You create the client account. The default subdomain is assigned and default branding is applied.
2

Active

The client’s first SSO login succeeds. The portal is live; the data lens, AI assistant, and client-initiated workflow channels are all active.
3

Offboarding (if engagement ends)

Trigger offboarding from Settings → Portal → Clients → [client] → Offboard. The client retains read-only access for 30 days, during which they can export their data. After 30 days, data is wiped per your tenant’s retention policy.