Branding basics — logos, colors, and your first brand policy
Branding in DashboardFox is more than logos. It's colors, terminology, and what users can even see and do inside the app. This lesson is the universal foundation — the policy everyone sets up first.
By the end of this lesson
- Your organization's name in every user's browser tab
- A company-wide Application Branding policy live for all users
- A clear sense of which feature toggles to flip — and which to leave alone
You'll need
- Admin role in DashboardFox
- Logo files in PNG, JPG, or SVG (WebP is not supported)
- Your primary and secondary brand hex colors
Background
The default DashboardFox install is generic on purpose — neutral logo, neutral colors, every feature switched on. Branding is how you make it yours: visual identity, terminology, and crucially, which features users can even see. The same policy that swaps the logo can also hide the SQL view button, the schedule action, and the Created By column from your library list. Branding and feature control share one screen.
The three scenarios DashboardFox serves
Every DashboardFox deployment fits one or more of three shapes. The branding tools are organized around them:
Reports and dashboards live inside your intranet, portal, or product. Users never see the full DashboardFox interface — only the chart or report itself.
Users sign in to DashboardFox itself and work in the Dashboard, Library, and Builder sections. The most common pattern, and where this lesson focuses.
Reports are shared publicly — no login required. Covered in detail in the guest library lesson.
Four areas of branding to configure
Underneath those three scenarios sit four distinct branding areas in Settings → Branding. You don't need them all — most organizations only touch two — but knowing the map helps you find the right knob:
- Application Branding — logged-in experience. Colors, logos, sidebar links, feature toggles for the Dashboard / Library / Builder. This lesson focuses here.
- Login Page Branding — the page users see before authenticating. Domain-based, anonymous. Covered in the next lesson.
- Guest Branding — what anonymous users see when they hit a publicly-shared report. Covered in the guest library lesson.
- Embedded Content — a subset of Application Branding controlling what shows when reports/dashboards are embedded. We'll touch it lightly here.
One important global setting first
Before opening Branding at all, set the Product Name in Settings → Server Settings → Application Settings. This is the text that appears in every user's browser tab. Defaults to "DashboardFox"; change it to whatever you call the application internally — "Acme Analytics", "Finance Reporting", "Insights". This is one of two truly global settings (the other is Guest Branding) — every user, every tab, every time.
Out of the box, every tier includes one Application Branding policy. Most organizations only ever need one. If you eventually need different policies for different departments, partners, or customer tenants, that's a licensing upgrade — covered in the next lesson.
Stuck on which feature toggles to leave on, or seeing something different in your instance than the video shows? Email team@dashboardfox.com with a screenshot of what you're seeing and what you expected. Real human, same business day.
Before you start
- Admin role. Settings → Branding is admin-only. If you don't see Settings in your sidebar, you don't have access — talk to whoever installed DashboardFox.
- Logo files in the right formats. PNG, JPG, or SVG. WebP is silently rejected — the upload appears to work but the image won't render. SVG is best for logos (scales cleanly); PNG is fine if you don't have an SVG; JPG works for non-transparent images. Keep files small (under ~500KB) — they load on every page render.
You'll typically want a big logo (wide horizontal version, shown when the sidebar is expanded) and a small logo (square or icon-only, shown when the sidebar is collapsed).
- Hex colors. Primary (main accent — buttons, links, highlights) and secondary (subtler accents). Six-digit hex codes like
#005FAC, not five-digit; the browser silently ignores invalid hex and you'll wonder why nothing changed. - A short feature inventory. Spend two minutes thinking through what your team actually uses: scheduling? email exports? SQL view? The visualization builder? Anonymous sharing? Knowing which to leave on and which to hide is the meaningful part of this exercise — branding is mostly about not showing things.
- A product name decided. What's the application called inside your organization? "DashboardFox" is fine but generic. Something like "Acme Insights" or "Operations Reporting" reads better in a browser tab.
Do it
-
Set the Product Name
Navigate to Settings → Server Settings → Application Settings. Find the Product Name field. Enter whatever you want users to see in their browser tab — "Acme Insights", "Finance Reporting", anything you call the app internally. Save.
This is global. Every user sees this text. If you ever rebrand or change the internal name, this is the one field to update.
-
Create your first Application Branding policy
Navigate to Settings → Branding → Application Branding. You'll see two tabs at the top — Application Branding and Login Branding. Stay on Application Branding for now.
Click Create Branding. A side panel opens with two tabs at its top: Application Branding and Guest Branding. We're configuring the Application Branding tab; ignore Guest for now (and leave the Is Guest toggle off — that's reserved for the guest library lesson).
-
Name it, describe it, assign it
At the top of the panel:
- Name — descriptive, future-you should be able to read it and remember what it's for. "Company-Wide Standard" or "Corporate Branding" are good defaults for your first policy.
- Description — optional but recommended. One line on purpose and audience.
- Active Status — leave ON. Toggling off is useful later for testing without deleting.
- Is Guest — leave OFF. (You'll only turn this on when creating a guest branding policy — see the guest library lesson.)
Scroll to the Assigned Groups section. For your first policy, check ALL USERS. That single checkbox applies this branding to your entire DashboardFox instance — the simplest, most common starting point. (You can get more selective later; the next lesson covers per-group assignment.)
-
Set colors and logos in Feature Options
Scroll down to Feature Options. Top of the section:
- Primary Color — main accent. Click the swatch and either pick a color or paste a hex code like
#005FAC. - Secondary Color — subtler accents and highlights.
- Big Logo — wide horizontal version. Two options for every logo field: upload the file (stored on the DashboardFox server) or paste a hyperlink to a logo hosted elsewhere (your CDN, your website). Uploading is simpler; hyperlinking is useful if your logo changes centrally.
- Small Logo — square or icon-only version, shown when the sidebar is collapsed. Often a favicon-style mark.
Image format reminderPNG, JPG, or SVG. WebP is not supported — the upload appears to succeed but the image won't render and you'll spend twenty minutes wondering why. If you only have a WebP, convert it first.
- Primary Color — main accent. Click the swatch and either pick a color or paste a hex code like
-
Decide which features to hide
Below the colors and logos, Feature Options has a row of toggles — all enabled by default. Hiding features here removes them from the UI for users covered by this policy. Consider turning off:
- Show View SQL — only useful for SQL-literate users. Most teams hide this to prevent confusing non-technical users with raw queries.
- Show Allow Anonymous — controls whether users can publish reports for public/guest access. Usually safer to centralize that decision; hide here and grant via specific people.
- Show Allow Embedding — same reasoning. Control embedding centrally rather than letting every Composer mark reports for embedding.
- Show Send to Email — only if you're not configuring SMTP. Otherwise users will see the action and get errors when they try it.
- Show Schedule — same reasoning. If scheduling isn't set up at the server level, hiding the button avoids dead-end clicks.
The rule of thumb: hide features your installation doesn't actually deliver. Visible-but-broken is worse than not visible at all.
Below Feature Options are three more sections worth a glance:
- Sidebar Options — the Header Logo URL field is useful: when a user clicks your logo, send them where they actually want to go (your intranet, your main portal). Support and Documentation toggles can point at your internal help system rather than DashboardFox's.
- Dashboard Options and Library Options — fine-grained toggles for individual buttons and columns. The defaults are sensible; come back here if specific elements feel cluttered.
- Embed Dashboard Options and Embed Report Options — parallel sets of toggles that apply only when content is embedded. The point: you can show the visualization builder in the full app but hide it in embeds, where screen space is tighter. Different audiences, different controls, one policy.
-
Save and apply
Scroll to the bottom and click Save. The policy appears in your Application Branding list.
Branding applies at loginSaving the policy is not the same as seeing it. Application Branding loads at user sign-in. To see your changes: sign out, then sign back in. Refreshing the page is not enough.
You should see your colors, your logos, and the features you left enabled. If something's wrong, edit the policy, save again, and log out / log back in. Tweaking is normal — most teams iterate three or four times in the first week.
You have a working connection. Below is what to tighten before real users see it. Skip if you're just testing.
Make it real
Two adjacent features worth knowing about before you finish: the Phrase Manager (for renaming the words inside DashboardFox) and the Advanced Customizations (CSS, JS, HTML — for everything the toggles don't cover).
Rename DashboardFox's labels with the Phrase Manager
The Phrase Manager — Settings → Phrase Manager — lets you change the words DashboardFox uses throughout the interface. Don't like "Library"? Call it "Reports". Don't like "Composer"? Call it "Builder". Every text label is editable.
It's tied to language files, and there's a tier wrinkle worth knowing:
- All tiers can select from the out-of-the-box languages DashboardFox ships with. Assign a user's language under Settings → Security → Users → Edit → Additional Settings → Language.
- Growth tier and above unlocks the Phrase Manager itself — meaning you can edit the existing language files to use your own terminology.
- Growth tier customers can also request brand-new language files via support — useful if you serve a language DashboardFox doesn't ship.
The most common use case: white-label and agency setups. Different tenants (or different departments inside one organization) want to see the same product with different terminology. Phrase Manager makes that possible at the language-file layer, complementing what branding policies do at the visual layer.
One catch the video doesn't show: like Application Branding, phrase changes only appear on the user's next login. Edit a phrase, save, and log out / log in to see the difference.
Advanced Customizations — Custom CSS, JS, and HTML
At the bottom of every branding policy is an Advanced Customizations section with three big text boxes: Custom CSS, Custom JS, and Custom HTML. These are the escape hatches — anywhere the built-in toggles don't go, these will.
Common uses for each:
- Custom CSS — style any UI element. Grid column headers (example below), filter buttons, action menus, the spacing between widgets, font choices, anything you can target with a selector.
- Custom HTML — drop in third-party SaaS widgets. Live chat (Intercom, Drift, Crisp), analytics tags (Google Analytics, Mixpanel, Heap, Plausible), custom banners or announcements, support widgets — anything that comes as an HTML snippet to paste into a page.
- Custom JS — anything more behavior-driven. Session timeout handlers for embedded use, custom interactions, integration with parent windows when DashboardFox is embedded inside your own app.
Because CSS, JS, and HTML live inside a branding policy, and policies are assigned to groups and users, your customizations are scoped to whoever the policy is assigned to. Add Google Analytics to one customer's policy without polluting another's. Drop a holiday banner into Finance's policy and nowhere else. Run a chat widget for external partners but not internal staff. This is the kind of segmentation other BI tools either don't offer or charge separately for.
A worked example — bold, branded grid column headers
The most-requested CSS tweak: making grid column headers stand out. Default headers are subtle; you can make them bold, recolored, and brand-aligned in a few lines. Two snippets are needed because DashboardFox uses two different grid components — paste both into the same Custom CSS box and the right one will apply automatically:
Custom CSS — styled grid column headers
/* Default Data Grid headers (used by most reports) */
.jqx-grid-column-header {
background-color: #48cae4 !important;
color: #ffffff !important;
font-size: 14px !important;
font-weight: bold !important;
}
/* Aggregate Grid headers (used by aggregate visualizations) */
.dx-datagrid-headers {
background-color: #005fac !important;
}
.dx-datagrid-headers .dx-header-row > td,
.dx-datagrid-headers .dx-header-row > td > .dx-datagrid-text-content {
color: #ffffff !important;
font-size: 14px !important;
font-weight: 700 !important;
}Swap the hex codes for your own brand colors. The !important flags are necessary because the default DashboardFox stylesheets are highly specific — without !important, your rules lose the cascade and silently fail.
Paste into Advanced Customizations → Custom CSS, save, log out and back in. Full write-up with screenshots: the grid header styling KB article.
Picking a starting strategy
If you're not sure how aggressive to be on Day 1:
- Logos and colors are safe. Set them. Everyone benefits.
- Hide features your install doesn't deliver. SMTP not configured? Hide email and schedule. SQL view not relevant? Hide it. These are net-positive changes.
- Leave Dashboard and Library options alone at first. The defaults are reasonable; revisit individual toggles only after users complain about specific clutter.
- Hold off on Custom CSS / JS / HTML until you have a specific need. A blank branding policy with good logos and colors covers 80% of organizations.
When you need different branding for different audiences — partners, customers, internal departments — that's the next lesson: per-group branding, custom domains, and login pages.
If you're stuck
What goes wrong with branding, in roughly the order you'll hit it.
I saved my branding policy but nothing changed
Branding applies at login. Saving the policy isn't the same as seeing it. Log out completely (not just close the tab), then log back in. If you still see the old branding, confirm the policy is set to Active and that ALL USERS (or your specific group) is assigned.
"DashboardFox only allows one branding record" error
You've hit the default policy limit (one Application Branding policy per tier). Two options: (1) Edit your existing policy instead of creating a new one. (2) If you genuinely need multiple policies for different groups, contact team@dashboardfox.com about licensing additional policies — that's covered properly in the next lesson.
My logo uploaded but doesn't show
Almost always one of three things. (1) WebP — silently rejected. Convert to PNG or SVG. (2) The hex code or file path is malformed (5-digit hex, missing slash, broken URL). (3) The file is unusually large (multi-megabyte) and is timing out or being blocked. Resize down — under 500KB for raster logos, under 50KB for SVG.
My hex color doesn't apply
Confirm you have exactly six hex digits — #005FAC, not #05FAC. Browsers silently ignore invalid hex codes. Re-open the policy, re-paste the code, save.
Users say the app is showing too much / too little
Too cluttered: revisit Feature Options and the Sidebar/Library options — turn off what your team isn't actually using. Too sparse: a previous admin turned off something you need. Both are quick edits — open the policy, flip the toggle, save, ask the user to log out and back in.
The Phrase Manager is greyed out / I don't see it
The Phrase Manager itself is a Growth-tier-and-above feature. All tiers can assign existing languages to users (Settings → Security → Users → Additional Settings → Language), but only Growth tier and up unlocks editing phrases or requesting new language files. If you need Phrase Manager access, contact team@dashboardfox.com about your tier.
None of these match my situation
Email team@dashboardfox.com with a screenshot of your branding policy, a screenshot of what you're seeing, and what you expected. Same business day reply.
