Tenant & Partnership Branding

Tenant & Partnership Branding

Every tenant has a branding record — logo, colors, skin, font, custom CSS, and a white-label toggle — that skins the Designer, the tenant’s public login page, and its deployed packs. A partnership (see Operator Roles) can also carry its own branding record, which its member tenants use as their default look.

The nine fields

Field	What it controls
Logo kind, logo image, logo background	The mark shown in the header — a default mark, an uploaded image, or the tenant’s initials on a chosen background color
Primary color, accent color	The two brand colors used across the UI
Skin	Light or dark base theme
Font	The typeface used across the UI
Custom CSS	Free-form CSS injected on top of everything else
White-label	Hides Greentic’s own branding from the shell

Setting a tenant’s branding

Open a tenant’s Branding tab in the admin console and edit any field. Each field is independent — you can set a logo without touching colors, or change the font without touching anything else.

Partnership branding and inheritance

If a tenant belongs to a partnership, and the partnership has set its own branding, the tenant inherits any field the tenant itself hasn’t set. Resolution runs field by field, in this order for every one of the nine fields: tenant’s own value → the partnership’s value → the platform default.

Field-by-field is the important part. A partnership that has only set its two colors does not blank out the platform’s font for its tenants — they keep the platform font until either the partnership or the tenant sets one. And a tenant that overrides only its logo still shows the partnership’s colors underneath it, not the platform’s.

Astuce

Think of “unset” as “I have no opinion, keep asking the layer below” rather than “empty”. A field is only ever really empty — logo cleared, custom CSS cleared — if you explicitly clear it; see below.

Two fields — logo image and custom CSS — support an explicit cleared state in addition to “not set”: clearing a logo or the custom CSS at a given level means “show nothing here,” and that decision is final at that level — it is not overridden by whatever the partnership or platform would otherwise supply. The other seven fields (colors, skin, font, logo kind, logo background, white-label) have no such state, because there’s no value for them that means “blank” the way an absent logo or absent CSS does; for those, not setting a field always means “keep inheriting.”

Custom CSS is also the one field that is never combined across layers — the value that wins (tenant, partnership, or platform) is used whole, rather than having each layer’s CSS stacked on top of the others in an order you can’t predict from the form.

Locking partnership branding

A partnership admin (or platform admin) can set a partnership’s branding to locked. A locked partnership’s member tenants can no longer set their own branding overrides — every field falls straight through to the partnership’s (or, where the partnership hasn’t set it, the platform’s) value. Locking does not restrict the partnership itself: the partnership admin can still edit the partnership’s branding at any time, locked or not — it only closes the door to tenant-level overrides underneath it.

A disabled partnership cannot have its branding edited by its partnership admin (matching the rest of the disabled-partnership freeze — platform admins are unaffected), but a disabled partnership’s existing branding still applies to its member tenants; disabling a partnership is not the way to reset its tenants back to the platform look.

Seeding partnership branding from a tenant

Rather than filling in a partnership’s branding field by field, an admin can copy one member tenant’s current (already-resolved) look into the partnership record as a starting point, then adjust from there.

Where partnership branding shows up

• Every member tenant — the Designer, the tenant’s deployed pack, and its public tenant page all use the resolved branding automatically; nothing about them needs to know a partnership is involved.
• The admin console itself — an operator who administers exactly one partnership sees that partnership’s colors, logo, skin, and font in the console shell. An operator who administers two or more partnerships, or a platform admin, always sees the platform’s own look — there’s no non-arbitrary way to pick between several partnerships, so the console doesn’t try.
• The public login page, via a ?partner=<slug> link, or automatically when the visitor is on a partnership’s own custom domain (see below). An unrecognized slug is not an error — the login page just falls back to the platform look, so a stale or mistyped link never breaks sign-in.

Note

If a partnership owns a custom domain and the link also carries a ?partner= parameter for a different partnership, the domain wins. A visitor’s own hostname is never overridden by a query string somebody else put in a link.

Partnership custom domains

A partnership can claim its own domain — for example app.acme-partners.com — and serve every one of its member tenants from it, each still at its own /t/<slug> address, skinned automatically with the partnership’s branding. No ?partner= link is needed once the domain is live: visiting the partnership’s domain resolves its look on its own.

This is the same claim flow tenants already use for their own custom domains — add the domain, publish the DNS records it gives you at your DNS provider, then verify:

1. Open the partnership’s Branding tab and find the Custom domain card.
2. Enter the domain and add it. The card shows the DNS records (a routing record and an ownership record) you need to publish at your DNS provider.
3. Once the records are live, click Verify. This can take a few minutes to propagate — if it’s still pending, wait and verify again.
4. Once verified, the domain shows Active, and the partnership’s login page and member-tenant pages are served from it immediately.

Only a platform admin can claim, verify, or remove a partnership’s custom domain — a partnership admin can edit everything else about its own branding, but claiming a domain registers it with an outside provider and carries real DNS risk, so that one step goes through a platform admin. A partnership admin won’t see the Custom domain card at all; a platform admin sees it on every partnership’s Branding tab.

A partnership’s domain only ever serves that partnership’s own member tenants — visiting app.acme-partners.com/t/<some-other-tenant> for a tenant that isn’t a member of Acme Partners behaves exactly as if that tenant didn’t exist.

A domain can belong to exactly one tenant or one partnership at a time — the same domain can’t be claimed twice, whether by two tenants, two partnerships, or one of each.