Brands

What Are Brands?

Brands represent different customer-facing identities within a single Zendesk account. Each brand can have its own help centre, email addresses, support portal, and visual identity. Multi-brand setups are common for companies that support multiple products, regions, or business units from one Zendesk instance.

What Configly Captures

For each brand, Configly stores a complete snapshot of its configuration:

• Basic Information

  • Brand name
  • Subdomain -- the brand's Zendesk subdomain (e.g., support.yourproduct.com)
  • Host mapping -- custom domain configuration
  • Active status -- whether the brand is currently enabled
  • Default status -- whether it's the default brand for new tickets

• Branding

  • Signature template -- the email signature associated with the brand
  • Brand URL and help centre URL

• Metadata

  • Zendesk ID
  • Created and updated timestamps

Viewing Brands

Navigate to Brands from your connection dashboard to see all your brands. You can:

• Browse all brands with their active/inactive status
• Search brands by name
• See total and active counts on the dashboard card
• Click any brand to view its full details and reverse dependencies

Common Dependencies

Brands are referenced by other configuration objects to create brand-specific workflows:

Use dependency mapping to see which configuration objects reference each brand.

Tips for Admins

Before Making Changes

• Before deactivating a brand, check its reverse dependencies. Triggers with brand conditions will stop matching, and views filtered by that brand will show no results.
• Before changing a brand's subdomain, ensure any external integrations or bookmarks are updated.
• Before adding a new brand, plan the triggers, views, and SLA policies you'll need to support it.

Common Patterns

• Product-based brands -- Separate brands for each product with dedicated trigger rules and SLA targets
• Regional brands -- Brands for different markets with localised help centres and region-specific routing
• B2B / B2C split -- One brand for enterprise customers with stricter SLAs, another for consumer support

Maintenance

• Review brand-specific triggers when deactivating a brand -- they won't fire but will still exist
• Check that SLA policies cover all active brands -- a missing brand condition can mean tickets fall through without SLA coverage
• Verify that ticket forms are associated with the correct brands

Using Configly

• Use snapshot comparison to track when brands are added, deactivated, or reconfigured
• Use dependency mapping to see all triggers, views, and SLAs that reference a brand
• Use What-If simulation to test the impact of deactivating or adding a brand before making changes

Example Use Cases

New Product Launch

You're adding a brand for a new product line:

1. Sync your current configuration to capture the "before" state
2. Create the brand in Zendesk
3. Add triggers, views, and SLA policies for the new brand
4. Sync again and compare snapshots to verify everything was set up correctly

Brand Consolidation

You're merging two brands into one:

1. Check reverse dependencies for both brands
2. Identify all triggers, views, and SLAs that reference the brand being retired
3. Update those objects to reference the surviving brand (or remove the brand condition)
4. Deactivate the old brand and sync to verify

SLA Audit

You need to verify that every brand has appropriate SLA coverage:

1. View all brands in Configly
2. For each active brand, check which SLA policies reference it
3. Identify any brands without SLA coverage
4. Add missing SLA policy conditions for uncovered brands

Related Objects

• Triggers -- automated rules with brand-based conditions
• Views -- filtered lists that can filter by brand
• SLA Policies -- service level targets that may vary by brand
• Ticket Forms -- forms that can be associated with specific brands
• Macros -- agent actions that can be brand-specific