The multi-portal mode allows users with the
KHUB_ADMIN role to manage one central portal and automatically publish to different portals or environments.
For example, from one central portal, users can:
- Publish to portals dedicated to each brand of their company.
- Customize a portal for the publishing of inline help content.
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
PORTAL_ADMIN role can customize both types of portals independently, with their own:
- Print templates
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
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:
docs.example.com. 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
docs.example.com 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.
KHUB_ADMINusers 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 (
docs.example.com) dedicated to this product.
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.