Plan requirement
| Subscription | Suite Growth or higher, Support Enterprise |
| Access | Admin |
Rules written before your second brand existed apply to both. Reviewing them is the real work in a multibrand setup.
Add brand to your conditions
- Open the trigger, automation or view.
- Add a condition on Brand.
- Save and test with a ticket from each brand.
Brand is available as a condition everywhere, which makes the mechanics easy. Knowing which rules need it is the harder part.
Taking a brand out of a rule you did not write
The reverse case is easy to miss: a rule that names no brand at all still catches your tickets, because a rule without a brand condition applies to every brand. Rather than rebuilding it, add one condition under Meet ALL of the following conditions: Ticket > Brand > Is not > your brand. The rule keeps working for everybody else and stops touching yours.
Which rules need reviewing
Work through these in order, because they are the ones that show.
- Anything that sends a message. Notifications carrying your company name reach the wrong customers under the wrong name.
- Routing rules. A trigger assigning everything to one group sends the new brand's tickets there too.
- Service level agreements. Two brands rarely have identical promises.
- Views. Agents working one brand want their queue, not everything.
- Macros. The wording usually names a brand somewhere.
Use placeholders instead of names
The better long-term answer for messages. {{ticket.brand.name}} means one trigger serves every brand and keeps working when you add a third. Hard-coding the name means a rule per brand and a set of near-duplicates that drift apart.
Every ticket carries a brand, so the placeholder always resolves to something. Placeholders are case sensitive, which is the usual reason one comes out blank.
Test from each brand
Send a genuine ticket to each brand's address and follow it through. What routes, what the customer receives, and which name is on it. That is fifteen minutes and it catches what reading conditions does not.
Comments
0 comments
Article is closed for comments.