Understanding workspaces and portals

A workspace is the top-level container in Storyteq CMP Professional. It represents a single client environment within the platform and connects the CMP Angular application to a LUMA instance, which provides authentication and user management.

Each workspace has two key identifiers: a name (used internally for reference) and a URL (the address users navigate to in order to reach that workspace). Behind the scenes, the workspace holds a link to its associated LUMA deployment and a service account token that authorises CMP to communicate with LUMA.

A single CMP deployment can contain multiple workspaces, each pointing to its own LUMA instance or sharing one, depending on the implementation.

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.

LUMA provides two things that Storyteq CMP Professional depends on: authentication and services.

Authentication controls who can log in to a workspace. When a workspace is created in Storyteq CMP Professional, it is linked to a LUMA instance via a service account token. This token authorises CMP to communicate with LUMA and verify user identities when users log in.

Services control what authenticated users can do. Certain CMP features require specific LUMA services to be enabled for a user. For example, the Shares feature requires the Canopy > Shares service to be enabled on a per-user basis in LUMA.

Portal access is controlled by LUMA user groups. By default, if no groups are assigned to a portal, all users authenticated via the workspace’s LUMA instance can access it. Once one or more groups are assigned to a portal, access is restricted to members of those groups only. This allows implementers to create portals with different audiences within the same workspace. For example, a portal accessible only to an internal marketing team and a separate portal accessible to external clients.

Only the user who created a portal can set or update its permissions.

Lenses are filters defined in LUMA that control which assets or templates are visible in a given context within CMP.

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.

Lenses are configured and managed in LUMA, not within the CMP portal interface. Each lens is assigned to a domain, which means the assets it returns are scoped to that domain’s content.

Domains are organisational units in LUMA 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 configuring list pages within a portal, implementers 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.

The relationship between these concepts follows a clear hierarchy.

A LUMA instance authenticates users and defines what services they have access to. A workspace connects Storyteq CMP Professional to that LUMA instance, providing the environment users log 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. LUMA user groups assigned to portals and pages control who can access them.

Understanding this hierarchy makes the configuration process more straightforward: workspace and LUMA connection first, then portals, then pages and lenses, then permissions.