Introduce Project-Level Home and Inherited Site Configuration for Workspaces
I
International orange Turtle
In our Document360 project, we have several workspaces.
Maintaining the different workspaces and related site customizations is quite cumbersome.
• Each workspace has its own ‘Home’ site, which can be turned off.
• One workspace is the ‘main’ workspace.
• Each workspace has its own ‘Site header & footer’ settings.
• etc.
Issues:
This setup causes several issues. For example:
• Set up ‘Site header & footer’ separately for each workspace. Running the risk of inconsistencies.
• Breadcrumbs are not project based (generic).
o Breadcrumb ‘Home’ icon leads to the workspace ‘Home’ instead of a project ‘Home’.
o When workspace ‘Home’ is switch off, no home icon is shown in breadcrumbs, breaking the navigation.
o There’s a ‘Documentation’ part in the breadcrumbs, that should show the workspace name.
Solution:
To solve this, an architectural change is required for the Document360 platform.
The solution for this would be to introduce a project ‘Home’.
Benefits would, for example, be:
• One site setup (headers, footers, etc.) that can be inherited by the project workspaces. (You can still keep the workspace-specific site setup, but make it by default inherit the project site setup)
• Project-based breadcrumbs:
o ‘Home’ icon always can be shown and navigates to the project Home.
o Workspace names can be shown in the breadcrumbs.
• Improved ‘workspace’ switch in the published sites.
• More flexibility (less restrictions) in the documentation web site setup.
• No need to mark one workspace as ‘Main’, with all related technical consequences and limitations.
Log In
K
Kavya
Hi International orange Turtle,
Thank you for sharing this detailed and well-thought-out request — this is very helpful.
To better understand the requirement and evaluate the scope of such an architectural change, could you please clarify a few points:
When you mention a project-level “Home”, do you expect this to act as a central landing page across all workspaces, independent of individual workspace home pages?
Should the project-level header/footer:
Fully override workspace-level settings, or
Act as a default that workspaces can optionally inherit/override?
For breadcrumbs:
Should the structure always be something like Project Home → Workspace → Category → Article?
Should this behavior apply to both KB site and widget?
Regarding the workspace switcher, are you expecting:
A more visible/global switcher across all pages, or
A navigation model similar to multi-product documentation sites?
Are all your workspaces closely related (same product ecosystem), or do they serve distinct audiences/products?
Do you currently rely on any workspace-specific branding or customization that should remain independent?
Understanding these aspects will help us assess whether this should be approached as:
A configuration enhancement, or
A broader platform/architecture change
Looking forward to your inputs so we can evaluate this further.