Freshdesk Multiple Portals

One account can serve several Freshdesk multiple portals, each branded. What confuses people is which settings split per portal and which stay stubbornly global.

How Freshdesk multiple portals actually work

In Freshdesk, a second portal comes from the multiple products capability. You define a product, and that product gets its own customer-facing portal: its own URL, its own branding, its own support email address, and its own slice of the knowledge base.

Behind that, you still have one Freshdesk account. One agent pool, one ticket table, one set of contacts, one bill. Tickets carry a product attribute that says which portal they arrived through, and everything else, routing, SLAs, automation, reporting, works off that attribute.

That architecture is the whole story. Multiple portals are a presentation layer over one help desk, not several help desks in a trench coat. Once you internalise that, most of the surprises stop being surprising.

It sits on the higher plans rather than the entry ones. Confirm which tier includes it before you promise a second brand a launch date.

What is separate, and what is shared

Separate per portal:

The portal URL and branding. Each product gets its own address, and you can point a custom domain at it with a CNAME so customers never see a freshdesk.com URL.
The support email address. Mail to that address creates tickets already tagged with the right product.
Theme, logo and portal content. Different look, different wording, different landing page.
Which knowledge base categories appear. You map solution categories to portals, so brand A customers don't browse brand B articles.
Portal language settings, where you support more than one.

Shared across all portals:

Agents and groups. One agent pool. You control who sees what through groups and scope, not through portal boundaries.
Contacts and companies. One customer database. A person who contacts two brands is one contact record with tickets from both.
Ticket fields, forms and statuses. Largely global. A field you add for one product exists everywhere, which is why field sprawl is the classic multi-portal failure.
Automation rules and SLA policies. Global objects, filtered by product conditions. There's no per-portal ruleset.
Reporting. One analytics surface. You segment by product rather than switching accounts.

Where the setup hurts

Four things bite, and all of them bite at month three rather than day one.

Ticket forms get crowded. Every custom field you add for one product exists on the ticket object. Without conditional logic you end up with a form asking brand A customers about brand B hardware. Plan your field set across all products before you launch the second one, not after.

Automation conditions multiply. Every rule now needs a product condition, or it fires across brands. The rule you wrote last year, before the second portal existed, definitely doesn't have that condition. Audit the whole ruleset when you add a portal.

Contacts are genuinely shared. If two brands are meant to be commercially separate, agents on one can still see the customer record and its tickets from the other. Scope controls what agents see at group level. Test exactly what a brand A agent can reach before anyone assumes isolation exists.

Email deliverability doubles. Each portal address needs its own DNS records for the sending domain. Skip SPF and DKIM on the second brand and half its replies land in spam, while the first brand works perfectly and everyone blames the new portal.

When you should not do this

Multiple portals solve a presentation problem. They don't solve a separation problem.

If two businesses need separate data, separate agents, separate billing and separate contracts, they need separate Freshdesk accounts, not separate portals.

The test is whether an agent seeing the other brand tickets would be a problem. If the answer is "that would be a compliance issue", stop. One account with two portals isn't a security boundary.

Equally, don't spin up a portal for something that's really a category. Two product lines sold to the same customers, supported by the same team, answered from the same knowledge base, do not need two portals. They need a ticket field and a saved view. A portal you launched for tidiness is a portal you maintain forever.

The related decision is covered in multiple products in Freshdesk, and the portal itself is worth reading about in the customer portal guide.

A launch checklist for portal number two

Map the knowledge base first. Decide which categories appear on which portal before you write a line of theme code.
Set up the email address and DNS, then send a real test message from an outside account and confirm both creation and threading.
Audit every existing automation for a missing product condition.
Decide the group model. One team for both brands, or separate groups with scoped visibility. Test what each group can actually see.
Check reporting segmentation by building one report filtered to the new product on day one, so you know it works before anyone asks for numbers.
Point the custom domain and verify the certificate, because a browser warning on a support portal destroys trust faster than a slow reply.
FAQ

Frequently asked questions

Is a portal per product the same as multi brand?

Yes. Freshdesk multi brand, Freshdesk multibrand support and Freshdesk multiple customer portals all describe the products feature, and a Freshdesk portal per product is the most common way teams use it.

Can Freshdesk run multiple portals?

Yes, through the multiple products capability. Each product gets its own portal URL, branding, support email and knowledge base categories, all inside one Freshdesk account.

Which plan do I need for multiple portals?

It sits on the higher tiers rather than the entry plan. Confirm the current plan table before committing to a launch date for a second brand.

Do agents work across all portals?

Yes. There's one agent pool and one ticket queue. You control visibility with groups and agent scope, not with portal boundaries.

Are contacts separate per portal?

No. Contacts and companies are shared across the account. A customer who contacts two brands has one record holding tickets from both.

Can I use a custom domain for each portal?

Yes, by pointing a CNAME at the portal and completing the certificate setup. Each portal also needs its own SPF and DKIM records for outbound mail.

More portals, more duplicates

The same customer contacting two brands, or emailing twice, creates two tickets. Ticket Merger detects and merges them automatically.

Start free trial

14-day free trial. No credit card required.