1. Overview
  2. Admin Guides
  3. Branding
  4. Branding Best Practices and Common Scenarios

Branding Best Practices and Common Scenarios

This guide provides practical strategies, recommendations, and solutions for common branding scenarios in Yurbi. Whether you're setting up a multi-tenant environment, implementing tiered pricing, or just want to create a polished branded experience, these best practices will help you make the most of Yurbi's branding capabilities.

Getting Started: The Right Order

When implementing branding for the first time, follow this sequence for the smoothest setup:

1. Set Your Product Name

Start with the global setting: Settings → Server Settings → Application Settings → Product Name

This establishes the basic identity that appears in browser tabs for all logged-in users. Choose something that represents your product or service.

2. Create Default Login Page Branding

Set up Settings → Branding → Login Branding with a default/fallback policy (leave Domain Name blank).

This ensures users see your brand from the very first interaction, even if you add domain-specific policies later.

3. Configure Guest Branding (if applicable)

If you're sharing public reports or dashboards, set up Guest Branding next. This is global, so you only need one policy.

4. Create Your First Application Branding Policy

Start with a single policy for all users: Settings → Branding → Application Branding

Name it something like "Default" or "All Users," assign it to ALL USERS, and configure the basic appearance.

5. Refine and Segment

Once the basics work, create additional policies for different groups, tenants, or tiers as needed.

Multi-Tenant Strategies

Multi-tenant environments are where Yurbi's branding really shines. Here are proven approaches:

Strategy 1: Custom Domain Per Tenant

Setup:

  • Each tenant has their own custom domain (e.g., customer-a.yourapp.com, customer-b.yourapp.com)
  • Create one Login Branding policy per domain
  • Create one Application Branding policy per tenant group

Benefits:

  • Complete isolation of branding from login through application
  • Professional appearance for each customer
  • Easy to manage and troubleshoot

Implementation:

  1. Set up CNAMEs for each customer domain
  2. Create Login Branding with each domain specified
  3. Create Application Branding policies assigned to each customer's group
  4. Test each domain independently

Strategy 2: Shared Domain with Group-Based Branding

Setup:

  • All tenants access via the same domain (e.g., reports.yourapp.com)
  • One default Login Branding policy
  • Multiple Application Branding policies per tenant group

Benefits:

  • Simpler domain management
  • Still provides customized experience after login
  • Lower maintenance overhead

Implementation:

  1. Create one default Login Branding
  2. Create Application Branding policies for each customer group
  3. Assign policies carefully to ensure proper grouping

Trade-off: Users see generic branding at login, but get their custom branding once authenticated.

Strategy 3: Hybrid Approach

Setup:

  • Most tenants use shared domain (Strategy 2)
  • Premium or enterprise customers get custom domains (Strategy 1)

Benefits:

  • Flexibility for different customer tiers
  • Cost-effective for most customers
  • Premium feel for high-value customers

Tiered Pricing and Feature Access

Use branding to implement feature-based tiers without managing separate codebases.

Example: Three-Tier Model

Free/Basic Tier:

Policy Name: "Basic Tier Users"
Assigned to: Basic Customer Group

Feature Options:
- Show Allow Anonymous: OFF
- Show Allow Embedding: OFF
- Show View SQL: OFF
- Show Send to Email: OFF
- Show Schedule: OFF

Library Options:
- Show Report Details Export: OFF
- Show Report Details Create Chart: OFF

Embed Options:
- Show Embed Export Icon: OFF
- Show Embed Print Icon: OFF

Professional Tier:

Policy Name: "Professional Tier Users"
Assigned to: Pro Customer Group

Feature Options:
- Show Allow Anonymous: OFF
- Show Allow Embedding: OFF
- Show View SQL: OFF
- Show Send to Email: ON
- Show Schedule: ON

Library Options:
- Show Report Details Export: ON
- Show Report Details Create Chart: ON

Embed Options:
- Show Embed Export Icon: ON
- Show Embed Print Icon: ON

Enterprise Tier:

Policy Name: "Enterprise Tier Users"
Assigned to: Enterprise Customer Group

Feature Options:
- All enabled

Library Options:
- All enabled

Embed Options:
- All enabled

Progressive Feature Unlocking

As customers upgrade tiers:

  1. Update their group assignment to the new tier's branding policy
  2. Have them log out and back in
  3. They immediately see their new features

Marketing benefit: You can demonstrate feature differences during sales conversations by temporarily assigning prospects to higher-tier policies.

Embedded vs. Full Application Strategy

Most customers both embed reports and provide full application access. Here's how to optimize each:

The Clean Embed Approach

In Embedded Content (Embed Options):

  • Hide complexity: Turn off Add Widget, Reorder, Save Views
  • Focus on data: Keep Refresh, maybe Export if needed
  • Simplify visualization: Hide Create Chart
  • Remove administrative options: Hide Schedule, Email

In Full Application:

  • Enable power features: Create Chart, Schedule, Email
  • Allow customization: Save Views, Add Filters
  • Provide full control: All dashboard editing options

Why this works: Embedded content typically has limited screen space and appears in your product's context where users are focused on specific tasks. The full application is where power users go to do deeper analysis and administration.

Example Configuration

For a typical customer:

Embed Dashboard Options:
- Show Embed Dashboard Details Title: ON
- Show Embed Save This View: OFF
- Show Embed Saved Views: OFF
- Show Embed Add New Filter: ON (useful for filtering data)
- Show Embed Refresh Icon: ON
- Show Embed Print Icon: OFF
- Show Embed Export Icon: OFF (maybe ON for premium)
- Show Embed Add Widget Button: OFF
- Show Embed Widgets Reorder Icon: OFF
- Show Embed Widgets Actions Icon: OFF

Dashboard Options (Full Application):
- All enabled for power users

Common Scenarios and Solutions

Scenario: Internal Team Needs Full Access

Problem: You're creating restricted policies for customers but need your team to have everything.

Solution:

  1. Create a comprehensive "Internal Team" policy with all features enabled
  2. Assign it to your internal user group
  3. When assigning customer policies, use SELECT ALL then uncheck your internal group

Scenario: Customer Wants Minimal Interface

Problem: A customer finds Yurbi "too busy" and wants the simplest possible interface.

Solution: Create a minimalist policy:

  • Hide Action Menus where possible
  • Hide Created By, Status columns
  • Hide all editing and customization features
  • Keep only Refresh and viewing capabilities
  • Use Custom CSS to further simplify if needed

Scenario: Compliance Requires Export Restrictions

Problem: Some customers can't allow data exports due to compliance requirements.

Solution:

  1. Create a "No Export" policy
  2. Hide all Export options (both embed and application)
  3. Hide Print options (as they can save-as-PDF)
  4. Hide Schedule options (emails could forward data)
  5. Document this restriction for customer's compliance team

Scenario: Gradual Feature Rollout

Problem: You want to test new features with a subset of users before enabling broadly.

Solution:

  1. Create a "Beta Features" policy
  2. Enable the new feature only in this policy
  3. Assign to your internal team and a few friendly customers
  4. Gather feedback
  5. Gradually add more users to the policy
  6. Eventually merge into your standard policy

Scenario: White Label for Resellers

Problem: You have resellers who want to brand Yurbi as their own product.

Solution:

  1. Create a policy per reseller
  2. Use their logos, colors, terminology
  3. Set Header Logo URL to point to their application
  4. Customize Support and Documentation links to their resources
  5. Use Custom CSS/JS for any additional tweaks
  6. Set up custom domains per reseller for complete white-labeling

Testing and Troubleshooting

Testing Checklist

Before rolling out new branding:

  • [ ] Test with a user in each affected group
  • [ ] Verify logout/login applies changes
  • [ ] Check embedded content if applicable
  • [ ] Test all custom links (Support, Documentation, Logo URL)
  • [ ] Verify logos display correctly at different screen sizes
  • [ ] Confirm colors are readable and accessible
  • [ ] Test any Custom JS for errors in browser console
  • [ ] Validate Custom CSS doesn't break layout

Common Issues and Fixes

Issue: Branding changes not appearing

  • Solution: Have users log out completely and log back in. Branding applies at login time.

Issue: Logo not displaying

  • Check: File format is JPG, PNG, or SVG (not WebP)
  • Check: URL is accessible if using linked images
  • Check: File size is reasonable for web display

Issue: Some users see old branding

  • Check: Policy is set to Active
  • Check: Users are assigned to the correct group
  • Check: Only one policy applies to each user (newer policies override older ones)

Issue: Custom CSS not working

  • Check: CSS syntax is valid
  • Check: Selectors are correct (use browser developer tools)
  • Check: No conflicting CSS elsewhere
  • Consider: Using !important flags for overrides

Issue: Features hidden in embed but need them

  • Remember: You can override branding on individual dashboards/reports
  • Or: Create a separate policy for users who need those features in embeds

Issue: Session timeouts showing login page in embeds

Performance Considerations

Logo File Sizes

Keep logo files reasonably sized (under 500KB) for fast loading. SVG is ideal for logos as it scales perfectly.

Custom JS

  • Test custom JavaScript thoroughly
  • Avoid heavy operations that slow page load
  • Use async loading for external scripts when possible

Custom CSS

  • Keep CSS efficient and targeted
  • Avoid overly broad selectors
  • Test across different browsers

Documentation for Your Team

When managing multiple branding policies, maintain documentation:

For each policy, document:

  • Policy name and purpose
  • Which groups/users it applies to
  • Why specific features are enabled/disabled
  • Any custom code and its purpose
  • When it was created and by whom
  • Any special testing requirements

Template example:

Policy: Premium Enterprise Customers
Created: 2024-01-15
Created by: [Admin Name]
Assigned to: Enterprise Customer Group

Purpose: Full-featured experience for enterprise tier

Features Enabled:
- All standard features
- Export in all contexts
- Scheduling and email
- View SQL (for power users)

Custom JS:
- Analytics tracking (Google Analytics)
- Chat widget (Intercom)

Notes:
- This is our highest tier
- All new enterprise customers should get this policy
- Review quarterly for new feature additions

Upgrading and Maintenance

When Adding New Features

As Yurbi releases new features:

  1. Review all branding policies
  2. Decide which tiers should see new features
  3. Update policies accordingly
  4. Test with representative users
  5. Communicate changes to affected users

Regular Policy Reviews

Schedule periodic reviews (quarterly or semi-annually):

  • Are policies still aligned with business needs?
  • Are there unused or redundant policies?
  • Have customer tiers or offerings changed?
  • Is documentation up to date?
  • Are there new use cases to support?

Deprecating Policies

When removing a policy:

  1. Identify affected users
  2. Assign them to a different policy
  3. Communicate the change
  4. Wait for all users to log in at least once
  5. Verify no one is still assigned
  6. Then delete the policy

Advanced Techniques

Using Custom JS for Conditional Logic

You can add logic based on user attributes:

// Example: Show a notification for admin users
if (window.currentUser && window.currentUser.isAdmin) {
  // Add a custom notification
  document.addEventListener('DOMContentLoaded', function() {
    // Your custom code here
  });
}

Dynamic Branding Based on Date

Use Custom JS to change branding for special events:

// Example: Holiday branding
var today = new Date();
if (today.getMonth() === 11) { // December
  document.body.classList.add('holiday-theme');
}

Then use Custom CSS to style .holiday-theme.

Integrating with Your Application

Use Custom JS to communicate with parent windows when embedded:

// Post message to parent window when report loads
window.parent.postMessage({
  type: 'yurbi-report-loaded',
  reportId: window.currentReport.id
}, '*');

Your application can listen for these messages and react accordingly.

Getting Help

If you're stuck with a branding scenario:

  1. Check the specific articles for detailed configuration steps
  2. Review this best practices guide for similar scenarios
  3. Test with a single user before rolling out broadly
  4. Contact support with specific details about what you're trying to achieve

Key Takeaway: Yurbi's branding capabilities are powerful and flexible. Start simple, test thoroughly, and iterate based on your specific needs. The investment in proper branding pays off with a professional, cohesive experience for your users.

Related Articles