Skip to main content
Wildo.ai Coming soon

Organisations and members

Give each organisation its own identity

Keep company information and branding together, ready for the application surfaces that present the customer.

Acme's logo and blue palette carry from its profile to its sign-in screen.

Give each organisation its own identity

Each organisation has a profile for its business information: name, contact details, location and social links. Its identity stays separate from the people who administer it.

Store a customer logo and primary colour alongside that profile. The standard sign-in page can present the identified customer when the public brand header is enabled. Custom layouts can use the same presentation contract.

Example — Recognise the customer workspace

A customer adds its logo without choosing a colour. After identification, the enabled sign-in brand header displays the customer logo and keeps its existing colour treatment when the tenant has supplied none.

For engineers

Update the profile, not the tenant’s lifecycle record

The profile is a resource associated with the organisation. This illustrative profile payload shows company information alongside the branding values used by sign-in presentation:

{
  "displayName": "North Studio",
  "website": "https://north.example",
  "branding": {
    "logo": "https://north.example/logo.png",
    "primaryColor": "#234C72"
  }
}

Submit the fields through the organisation profile’s generated update operation, with authority over that organisation. The logo is an absolute URL. A profile edit does not verify ownership of a sign-in domain or change how users authenticate.

Follow branding to its consumer

authentication-orchestrator.backend.service.ts loads branding for the organisation resolved during identification. resolveTenantBrandPresentation resolves fields independently. The caller supplies the application logo as fallback; it supplies no application primary colour for this DTO, so an unset tenant colour remains absent.

The standard AuthPage_Main passes auth.identification?.organizationBranding to its public layout. usePublicShellLayout applies that input only for the login card layout, when no explicit shell identity overrides it. The header must be enabled with publicShellIdentityMode: PublicShellIdentityMode.BRAND_HEADER in the frontend configuration; an absent header is not enabled merely because a profile has a logo.

Reuse the presentation contract in a custom login layout

A custom public-layout implementation can obtain the same resolved identity through the exported hooks:

import { useAuthSession, usePublicShellLayout } from '@wildo-ai/saas-frontend-lib';

export function useIdentifiedLoginLayout() {
  const { auth } = useAuthSession();
  return usePublicShellLayout(
    true,
    auth.identification?.organizationBranding,
  );
}

This illustrative hook belongs in a custom login layout beneath the normal application, UI and authentication providers. Render the returned brandHeader only when it is present. It supplies the resolved name and optional logo; brandAccentColor supplies the optional decorative tenant colour. Keep the existing label beside an unclassified logo and use the application’s design-system colour handling rather than treating an arbitrary profile colour as a text-contrast policy.

SituationResolved login presentation
No identified organizationApplication identity
Identified organization with a logoTenant logo; identified name when supplied
Tenant logo absentApplication logo fallback
Tenant primary colour absentNo tenant accent override
Explicit shell identity presentShell identity takes precedence
Public brand header not enabledNo brand header

A verified organization domain can supply login branding even when SSO is disabled. The name comes from the organization record; the logo and colour come from its profile. This presentation lookup does not select sign-in methods, grant membership or change access rules. Pass identification branding only to the intended login layout; registration and legal pages should not inherit the last login attempt’s tenant.

That is the supported presentation contract here. The stored favicon, secondaryColor and customDomain fields do not imply corresponding sign-in DTO fields or automatic domain provisioning. Business-profile content is available through the resource pipeline; custom screens can choose how to present it.

Keep domain verification in the authentication configuration. A business website or profile domain describes the organisation; it is not proof that the organisation controls that domain.

Building a B2B product or an internal tool?

Wildo is not self-service yet. Tell us what you have in mind and we will say plainly whether it fits, and what happens next.