Multi-portals at a Glance - Fluid Topics - Latest

At a Glance

Business value

The multi-portal mode allows users with the CONTENT_PUBLISHER, ADMIN, or KHUB_ADMIN role to manage one central portal and automatically publish to different portals or environments.

For example, from one central portal, users can:

A cloud labelled "Knowledge Hub" has three arrows pointing outwards to three computers: one is called "A-Brand Portal", another "B-Brand Portal", and the last one is called "Master Portal". Each computers has its own database icon, and the mention "Look and Feel". The "Master Portal" also has the "KHub Admin" label.

The multi-portal mode is a premium feature. Contact a Fluid Topics representative with the Fluid Topics Help Desk for more information.

Features overview

A multi-portal architecture consists of:

  • One "Manager" tenant, to view or publish content from.
  • One or more "Consumer" tenants, to view a part of the content of a "Manager" tenant.

Users with the ADMIN or PORTAL_ADMIN role can customize both types of portals independently, with their own:

  • Theme
  • Homepage
  • Print templates
  • Logos
  • Header

All portals also have their own set of users, allowing for complete control over authentication (independent single sign-on methods, for example).


It is necessary to have the ADMIN or PORTAL_ADMIN user role to customize portals.


Create brand-specific portals

It is possible to use the multi-portal mode to set up a specific portal for a given brand or product.

Content creators can publish documents to a single portal, with various tools, and Fluid Topics can dynamically route the content to multiple individual portals. This enables the centralization of documentation in one place, while also preserving separate outputs.


The Example company has three brands: brand A, B, and C.

Each brand has a specific documentation format:

  • Brand A: DITA (XML)
  • Brand B: Markdown
  • Brand C: Adobe FrameMaker

With multi-portals, technical writers and subject-matter experts can publish to a single source of truth: It is the "Manager" tenant.

The Knowledge Hub of the "Manager" tenant processes the different formats and publishes the documentation on the portal. Since authentication is portal-specific, the company restricts access to to its employees.

Each brand has its own "Consumer" tenant:


Each "Consumer" tenant reads the same content as the "Manager" portal. Each "Consumer" tenant also has a filter limiting its access to the content matching a specific value of the brand metadata key.

Unlike the "Manager" tenant, the company decides to make all its "Consumer" tenants public.

Customization and authentication control allow the users of each brand to benefit from a documentation experience tailored to their needs.

  • A "Consumer" tenant with a metadata filter only hides content with different metadata from its search results. Users of a "Consumer" tenant can still access hidden content available in the common Manager tenant by entering its URL, for example.
  • ADMIN and KHUB_ADMIN users can only restrict content access by the use of access rules.

Create an inline help portal

It is possible to configure a "Consumer" portal for inline help.


The Example company wishes to embed documentation in its new product.

To do so, the company first sets up a "Consumer" portal, mirroring the content of its main documentation portal ( dedicated to this product.

Then, an ADMIN customizes the appearance of the "Consumer" portal to match the look and feel of their new product.

This allows the Example company to manage inline help content more easily, while providing their users with a seamless experience.

For an example of inline help, see Sonic Screwdriver Parts Catalog.
Inline help makes use of the Get a topic's styled content web service.

Enable and configure multi-portals

To enable and configure the multi-portal mode, contact a Fluid Topics representative with the Fluid Topics Help Desk.