Understanding workspaces and portals
Storyteq CMP is organised around two foundational concepts: workspaces and portals. This page explains what each of these is and how they relate to each other. It also introduces the supporting ideas, lenses and domains, that control what content users see once they are inside a portal.
What is a workspace?
A workspace is the top-level container in Storyteq CMP. It represents a single client environment: the place your organisation’s users sign in to.
Each workspace has two key identifiers: a name, used internally for reference, and a URL, the address users go to in order to reach that workspace.
|
What you see here depends on your workspace’s configuration. Your workspace is set up for your organisation before you first sign in, including which features are available in it. To change it, contact your administrator. How LUMA connects to workspaces and portals explains how this is configured. |
What is a portal?
Portals live within a workspace and provide structured, audience-specific views into the platform. Where a workspace defines the environment, a portal defines the experience — what users can see, what they can do, and how the interface is presented to them.
Each portal has a type that determines its purpose and the pages and widgets available within it. A workspace can contain multiple portals serving different audiences or purposes. For example, a workspace might contain an assets portal for day-to-day asset browsing, a brand portal for brand guidelines and colour palettes, and a projects portal for campaign management.
Portal types
Six portal types are available, each optimised for a different use case:
-
An assets portal is the most fully featured portal type. It supports all page types — asset list, templates list, user adaptations, and CMS — and all widget types. It is the standard choice for implementations where users need to browse, download, and work with assets and templates.
-
A projects portal is focused on campaign and project management. It supports projects pages and CMS pages, but does not support asset-specific features such as Asset Grid or Asset Search widgets.
-
A brand portal is designed for presenting brand guidelines and identity materials. It supports CMS pages and most widget types, including typography and colour palette widgets, which are not available in other portal types. It is the appropriate choice when the portal’s primary purpose is communicating brand standards rather than providing access to a DAM.
-
An analytics portal connects to a QLIK report and displays analytics data within a dedicated page. It supports a limited set of widgets, and needs additional configuration before it can show a report.
-
A help portal is intended for support and guidance content. It supports CMS pages and a core set of widgets including text, button, image, and video.
-
An orders portal brings asset browsing, ordering, and order management together in one connected journey. It is configurable for Canopy and portals applications.
Portal access
Portal access is controlled by user groups. By default, if no groups are assigned to a portal, everyone who can sign in to the workspace can access it. Once one or more groups are assigned to a portal, access is restricted to members of those groups only. This lets you create portals for different audiences within the same workspace, for example a portal for an internal marketing team and a separate portal for external clients.
Only the user who created a portal can set or update its permissions.
What are lenses?
When an asset list page or templates list page is created within a portal, a lens is assigned to it. This lens determines which assets from which domain appear in that page. Lenses are also used in asset grid and asset search widgets to scope the assets that appear in and are returned by those widgets.
Each lens is assigned to a domain, which means the assets it returns are scoped to that domain’s content. To create a lens, use Create lenses.
What are domains?
Domains are organisational units that group assets, templates, and other content. A portal displays content from whichever domain the user is currently viewing.
Users can switch domains using the domain selector at the top right of the portal. When a user switches domain, the asset and template lists refresh to show only content belonging to the newly selected domain.
When you configure list pages within a portal, you can choose to include assets from subdomains and parent domains in addition to the selected domain. Both options are enabled by default and can be deselected if a more restricted view is required.
How it fits together
The relationship between these concepts follows a clear hierarchy.
Your workspace is the environment users sign in to. Portals within the workspace provide structured views, each with a type that defines its purpose and capabilities. Pages within each portal, such as asset list pages or CMS pages, give users access to specific content or functionality. Lenses assigned to those pages control which assets from which domain are visible. User groups assigned to portals and pages control who can access them.
Understanding this hierarchy makes setting up portals more straightforward: portals first, then pages and lenses, then permissions.