Multiple Customer Portal Domains With Business Units

[Dan_At_TrueVyne]

It seems to me that "business units" has a whole lot of potential for imporovement. 

Realistically, it's a huge financial investment for a company to add this to their subscription, and I feel that it's significantly underdeveloped for the price.

I'd really like the ability to customize separate customer portals for each business unit within Service Hub.

I have a client with a parent company + 2 completely different child organizations that will now need to somehow share branding in the customer portal. 

This is going to lead to quite a bit of confusion.

Please consider working on this functionality!!

[AEryorulmaz]

This woul be a helpful feature for us as well.

We do not have multiple brands, but different business units.

HR Team has it's own ticketing inbox, Customer Service has it's own ticketing inbox.

[APequeño]

This woul be a helpful feature for us as well. Please!

[SMurray9]

Same here! At the moment, only one business unit has access to the portal that links to their inbox, and it's impacting clients in other business units massively. Consolidating it to one inbox doesn't work unfortunately, as each business units have different workflows and pipelines. 

[AGonzalez2]

Esto sería muy útil para múltiples equipos internos, espero pronto puedan tener una actualización con este tema.

[rogermcnall]

I addition to being able to control the ticket properties displayed, and the filters, and even without "Business Units" since at present this has not been a need for our instance, there would also be value to be able to create different Portal Subdomains based on the ticket pipeline, as we have subsets of users who would need different access to different types of tickets. As well as the ability to control visibility into the different types of tickets and ticket pipelines.

Some examples from our use case would be:

1. portal.benefitbay.com/applications
2. portal.benefitbay.com/support
3. portal.benefitbay.com/terminations

We have Enrollers who process applications and would only need to be able to see and interact with the application tickets they are responsible for assisting with enrollment.

We have a different subset of users who would need access to view and see the support tickets, for themselves and for their organization

And maybe a different subset to view and manage terminiations.

Happy to provide more detail or context to this idea, if needed.

[Michael98]

Would be really helpful!

[TomPfaff]

Yes, please!

[ADaCosta7]

Please ! I need it 🙂

[AStanley8]

We have business partnerships where we whitelabel our services, including our support team. We really need the ability to have a differently branded customer portal from others with slightly different language, warranting multiple portals. Another person here saying please add this feature!

[WEvans-V0L7]

+ 1 for me amigos!

[DWebster3]

I have multiple brands and would like this feature!

[LM-JSand]

Doesn't look this is coming anytime soon, but I will add my support asking for this feature.

Multiple customer portals would help ownership to different sides of our business. 

[PRendschmidt]

+1 for the idea, I have multiple Customers that need this. If you are using several brands, you can't use a single domain for all of them.

[jeremyminor]

100% agree this is a much-needed feature.

[RUSH_WP]

Agree, but ensure that where multiple brands are used, admin can assign the appropriate domain for system messages (e.g. password reset, system emails, default page redirects) for contacts' private access. 

Explanation for this issue follows (from previous tech support request): 

We have already customised each domain, despite this, the problem below continues:

1. Customer (associated with XYZ) forgot password for private content;
2. CSR goes into "manage memberships" and goes actions -> password reset;
3. AMPS Customer receives the email from the abc.company.com.au domain (not as preferred from the xyz.company.com.au domain); 
4. They follow the password reset link, and it redirects to abc.company.com.au after being filled; and
5. The new password confirmation email is also within the wrong domain (and won't automatically match their branding without smart rules). 

The above issue apparently sometimes also presents on some other system emails (such as registration emails).

Although we could set up smart rules for the generic / domain system emails that some customers are defaulting to (i.e. abc.company.com.au / www.company.com.au), attempting redirect rules on fixed Hubspot password reset link / registration email is extremely difficult and hasn't worked upon initial testing - these appear completely fixed, basically hardcoded and read-only. 

"internally reference the default domain preferred for each customer by association / special contact property"

See we have 24,000 customers, and each has a value in the custom property "association_membership" which reflects their membership in the various union / professional association they are in. I've also generated a custom property that generates based on their union/association membership "union_redirect_url" (e.g. nmo.company.com.au). This should be the domain that is used for system messages (not "hs_content_membership_registration_domain_sent_to" which is usually wrong, read-only, and doesn't operate). 

Without this, the only fix is to create one domain without a fitting custom URL, or emails that allow one member to select their union (amongst 15 others – messy), We will likely do the first option, but this limitation may be a pitfall for other enterprises with multiple branding and domains to match.