Per-group and per-user branding — custom domains and login pages
Same DashboardFox instance, different look per audience. Branded login pages by domain, then per-group Application Branding for partners, customers, and tenants — each with their own colors, logos, and which features they can see.
By the end of this lesson
- A default Login Page Branding live (applies to anyone hitting the login page)
- A domain-specific Login Page Branding for a partner or customer access point
- A per-group Application Branding policy with its own logo, colors, and feature toggles
You'll need
- Lesson 1 (branding basics) completed
- A custom domain configured for your tenant — covered in server settings
- Groups already created for the audiences you'll target — see groups & folders
- Additional branding policies licensed if you'll have more than one Application or Login policy
Background
Lesson 1 covered the universal layer — one Application Branding policy, assigned to ALL USERS, that everyone sees. This lesson is about splitting that. Two distinct mechanisms, useful in different ways:
Login Page Branding — keyed by domain
The login page is anonymous. Before someone signs in, DashboardFox has no idea who they are or what group they belong to — so it can't pick a branding policy based on the user. Instead, Login Branding is matched by the domain name they're hitting your DashboardFox instance through. Two access points (analytics.acme.com and partners.acme.com) can show two completely different login pages.
The lookup order:
- Exact domain match — if a Login Branding policy has the user's domain filled in, that's the winner.
- Default policy — if no domain matches and a Login Branding policy has a blank Domain Name, that's the fallback.
- Stock DashboardFox — if neither, the default DashboardFox-branded login page shows.
Most organizations want at least the default policy filled in (so users see your brand from the very first page), plus optional domain-specific policies for partner or customer portals.
Per-group Application Branding — keyed by user
Once a user is signed in, DashboardFox knows their groups. Now branding can be selected based on who they are, not what URL they came in through. Create a second (third, fourth) Application Branding policy, assign it to a specific group only, and members of that group see their own colors, logos, and feature set.
The most common shape: an "internal company" policy assigned to your staff groups, plus one additional policy per external customer or partner tenant. Each tenant sees their own branding when they log in, completely independent of yours.
When changes take effect — a key timing difference
Out of the box, every tier includes one Application Branding policy and one Login Branding policy. If this lesson sounds like what you need, you'll likely need to license additional policies before you can create them. Hit "Create Branding" when you're already at the limit and you'll see: "DashboardFox only allows one branding record." Contact team@dashboardfox.com to discuss — pricing is reasonable and a one-time discussion.
Stuck on which domain to put where, or seeing the wrong branding when you log in as a test user? Email team@dashboardfox.com with screenshots of your Login Branding list, your Application Branding list (with assignments visible), and which user you're testing as. Real human, same business day.
Before you start
- Lesson 1 done. Your universal Application Branding policy exists and works. You're adding here, not starting from scratch.
- Custom domain set up (if you want domain-specific login branding). Custom domains are configured at the server level — covered in server settings. Without a custom domain, you can still set a default login branding, but you can't differentiate by URL.
- Groups created for your target audiences. A "Customer Acme" group, a "Partners" group, a department-specific group — whatever maps to "people who should see this branding". See groups & folders. You'll be assigning policies to these groups, not to individual users (usually).
- Licensing confirmed. The default tier is one Application Branding policy and one Login Branding policy. If you're creating more, contact team@dashboardfox.com first so the additional policies are unlocked.
- At least one test user per audience. Verification is the meaningful step. Have a user in the partner group (and one outside it) ready to log in once policies are in place.
Do it
-
Part A — Create your default Login Page Branding
Start with the default policy: the one users see when they hit your DashboardFox URL on any domain that isn't partner-specific. Most teams want this set even if they have no partners — it replaces the stock DashboardFox login.
Navigate to Settings → Branding → Login Branding → Create Branding.
- Title — the text that appears in the browser tab on the login page. Use your company name.
- Domain Name — leave blank. That's what makes this the default/fallback.
- Logo — upload or hyperlink. Same format rules as Application Branding: PNG, JPG, or SVG, not WebP.
- Footer Text + Footer Link — optional, but useful for things like "© Acme Corp, 2026" or a link back to your company site.
Click into Feature Options:
- Primary Button Color — the color of the Login button.
- Secondary Button Color — secondary accents.
- Favicon — shows in the browser tab. Upload your icon-style mark.
- Background Image — optional. Be careful with readability — busy backgrounds make the login form hard to read.
- Custom CSS — escape hatch for anything the toggles don't cover.
Save. The change is immediate — refresh the login page in a new tab and you'll see it.
-
Part A continued — Add a domain-specific Login Branding
Now create a second Login Branding policy, this time tied to a specific custom domain.
Click Create Branding again. Same fields as before, with one critical difference:
- Domain Name — enter the exact domain users will hit.
partners.acme.com— just the host, nohttps://, no trailing slash, no path.
Upload that partner/customer's logo, set their colors, and save. Test by visiting that domain in a private browser window — you should see their branding, not the default.
Domain matching is exactacme.comandwww.acme.comare different domains for matching purposes. If users access both, either pick the one users actually hit, or license a second policy and create both. There's no automatic www-stripping. - Domain Name — enter the exact domain users will hit.
-
Part B — Create a per-group Application Branding policy
Now the second mechanism: a different Application Branding policy for one specific audience. Same idea as Lesson 1's policy, but assigned to a single group rather than ALL USERS.
Navigate to Settings → Branding → Application Branding → Create Branding. Configure it just like Lesson 1's policy:
- Name — match the audience. "Acme Partner Branding" reads better than "Branding #2".
- Description — note who this is for and why it's different from the default.
- Active Status — ON.
- Is Guest — OFF.
Now the important difference — scroll to Assigned Groups. Instead of ALL USERS, check only the specific group this policy is for. (You can also use the search box if you have many groups, or use Assigned Users for individual exceptions.)
Configure Feature Options as needed — this is where partners often get a more restricted view:
- Different colors and logo (theirs, not yours)
- Hide Schedule and Send to Email (partners often don't need these)
- Hide Show Private Library (partners share team-only views)
- Hide Created By column (no need to expose your internal team names)
- Hide View SQL (partners don't typically need raw query access)
Save.
-
Critical — go back and edit your original policy
This is the step everyone forgets.Your Lesson-1 policy is still assigned to ALL USERS. That includes the partner group you just configured a separate policy for. With both policies trying to apply, the user might see either one — and the result is unpredictable.
Open your original company policy. Scroll to Assigned Groups. Uncheck ALL USERS and instead check the specific groups your company users belong to — your internal team groups, your departments — but not the partner group you just created the second policy for.
The shape you want, after this step:
- "Company Standard" policy — assigned to internal company groups (Engineering, Sales, Operations, Admin, etc.) but NOT the partner group.
- "Acme Partner" policy — assigned to ONLY the Acme partner group.
Every user falls into exactly one policy. No overlap. No ambiguity.
Save the original policy.
-
Verify — sign in as a partner user
Application Branding loads at sign-in, so testing means a fresh login.
Sign out of the admin account. Hit the partner's domain (if you set up domain-specific Login Branding) — you should see their login page. Sign in as a partner user. Once logged in:
- Logo and colors should be the partner's, not yours.
- The features you turned off should be gone (no Schedule menu, no Email, no Created By column, etc.).
- Their library should look slimmed-down — exactly the focused experience you configured.
Then sign out and sign back in as one of your own users — you should see your company branding, untouched by the partner work. The two policies coexist, each scoped to its audience.
You have a working connection. Below is what to tighten before real users see it. Skip if you're just testing.
Make it real
Three patterns most teams use for assigning Application Branding policies, plus a worked example of what an external-partner feature config typically looks like.
Three common assignment shapes
One policy assigned to ALL USERS. Simplest case. Covered in Lesson 1. Use this when everyone in the instance sees the same experience.
Your company policy assigned to most internal groups (manually, not via ALL USERS), plus one or more per-tenant policies for partners. Every group has exactly one policy assigned. The default policy gets every group except the carved-out ones.
Every group has its own dedicated policy. Used by agencies, white-label setups, or organizations where every audience is a "customer". No "default" — each group is its own brand.
Shape 2 is by far the most common. Most teams have one internal company experience and a handful of external-facing per-tenant policies.
A worked example — external partner policy
What a typical "partner / customer tenant" Application Branding policy looks like, top to bottom:
- Name — "Acme Partner Branding"
- Description — "External-facing policy for Acme's users. Restricted feature set, Acme's branding."
- Active Status — ON
- Is Guest — OFF
- Assigned Groups — "Customer Acme" group only
- Primary Color — Acme's brand color (not yours)
- Big / Small Logo — Acme's logos
- Show View SQL — OFF (partners don't need raw queries)
- Show Allow Anonymous — OFF (control public sharing centrally)
- Show Allow Embedding — OFF (same reasoning)
- Show Send to Email — OFF if you don't want partners auto-emailing reports
- Show Schedule — OFF if scheduled exports aren't part of the deal
- Show Private Library — OFF (partners use shared content only)
- Show Created By Column — OFF (don't expose your internal team's names)
- Header Logo URL — Acme's main portal (so clicking the logo returns them home, not to your site)
- Custom HTML — drop in Acme's preferred analytics or chat widget if they ask
The result: when an Acme user logs in, they see what looks like an Acme product, with a focused feature set. Your internal users, in parallel, see the full toolset.
A note on the Embedded scenario
Lesson 1 mentioned the Embed Dashboard / Embed Report options — they're configured inside an Application Branding policy. When you create a per-group policy, those embed options apply to that group's embedded content too.
A real-world pattern: hide the visualization builder, save-as-view, and export in embedded dashboards (where screen space is tight), but leave them visible in the full DashboardFox interface (where analysts have more room). One policy, two audiences served — embedded portal users see a stripped-down view, while the same users (or others on the same policy) see the full app when they log in directly.
If you're embedding DashboardFox content in your own application, also consider adding this to Custom JS in Advanced Customizations — it redirects users away from the DashboardFox login page if their session expires inside an iframe:
Custom JS — graceful session timeout in embedded scenarios
custom_handleexpired_session = function() {
window.location = "./index.html"; // Replace with your portal's URL
};Without this, an embedded report whose session has timed out shows the DashboardFox login screen inside the iframe — confusing for end users. With it, they bounce back to your application instead.
When the audience isn't authenticated at all — anonymous, public, no login — that's the third and final branding lesson: guest library setup and branding.
If you're stuck
What goes wrong with per-group branding, in roughly the order it shows up.
Some users see one branding, others see a different one — it's inconsistent
You forgot to remove ALL USERS from your original policy after creating the per-group policy. Both policies are trying to apply. Open the original company policy, scroll to Assigned Groups, uncheck ALL USERS, and instead check your internal company groups one by one — making sure to not check the partner group. Every group should have exactly one policy assigned.
My partner's domain isn't getting their login branding
Three common causes. (1) The Domain Name field has https:// or a trailing slash — strip it down to just the host. (2) The user is hitting www.acme.com but the policy is set for acme.com (or vice versa) — these are different. (3) The custom domain itself isn't actually set up at the server level — Login Branding can't route to a domain that doesn't exist for your instance. Verify the custom domain works first (covered in server settings), then re-check the Login Branding entry.
"DashboardFox only allows one branding record" when I try to create my second policy
You're at the default tier's policy limit (one Application Branding, one Login Branding). Either (1) edit your existing policy to be the new one, (2) disable the existing policy first (toggle Active Status off), or (3) contact team@dashboardfox.com about licensing additional policies. The third option is what you actually want for per-group branding — the first two are workarounds that don't scale.
I saved the Application Branding change but the partner says nothing changed
Application Branding applies at sign-in. The partner needs to log out completely and log back in — refreshing the page is not enough. (Login Branding, by contrast, is immediate — that's why login changes feel instant and application changes feel slow.)
The wrong logo is showing for some logged-in users
A user is in two groups, each assigned to a different Application Branding policy. The "tie-breaker" behavior isn't predictable — clean it up. Decide which policy each group should belong to, and remove the duplicate assignment. Every user should fall into exactly one branding policy.
I want to delete a branding policy but it's "in use"
Toggle Active Status OFF first — that disables it without deleting. If you genuinely need to remove the record, ensure no groups or users are assigned to it (unassign them first), then delete. Disable-rather-than-delete is the safer pattern in any case — keeps the configuration around for reference.
None of these match my situation
Email team@dashboardfox.com with screenshots of your Application Branding list (with Assigned Groups visible for each policy), your Login Branding list, and a description of which user sees what when they log in. Same business day reply.
