Portals and Branding

Shapeshift can support multiple separate learning Portals using the same underlying codebase.

A Portal is a separately deployed Shapeshift environment with its own:

Database
Learners and administrators
Organizations and Sub-Groups
Courses and Learning Paths
Enrollments and progress
Reporting data
CMS content
Branding
Environment configuration
Integrations and external services

This allows a client to operate multiple distinct learning experiences while still benefiting from a shared Shapeshift codebase.

A Portal should be thought of as a separate instance of the platform, not as a section or audience within an existing LMS.

Why use multiple Portals?

Portals are useful where two learning experiences need to be meaningfully separate.

Examples might include:

Different brands within the same parent company
Separate regional learning platforms
White-label learning products
Different commercial propositions operated by the same business
Separate academies with their own users, content and branding
Platforms that need stronger operational or data separation than Organizations provide

The important question is whether the learner experiences should operate as separate platforms.

If the requirement is simply to divide learners, customers, departments or teams within one LMS, Organizations are usually the more appropriate solution.

Portals vs Organizations

Portals and Organizations solve different problems.

Organizations

Organizations exist within one Shapeshift Portal.

They can be used to:

Group learners together
Give managers access to particular learners
Control access to learning content
Segment reporting
Create Sub-Groups for teams, departments or other structures

Organizations share the same:

Database
CMS
Frontend application
Platform branding
Environment configuration
Integrations

A learner can potentially belong to different Organizations or Sub-Groups within the same Portal.

Portals

A Portal is a separate Shapeshift environment.

Each Portal has its own:

Database
CMS content
Learner accounts
Organizations
Learning content
Enrollments
Reporting data
Platform configuration

Two Portals can use the same underlying Shapeshift codebase, but their data is not shared by default.

A learner in one Portal is therefore not automatically a learner in another Portal.

For example, if the same person needs access to two Portals, they would normally have separate user records in each environment unless a bespoke integration has been implemented to coordinate them.

Shared codebase, separate environments

One of the main benefits of the Portal architecture is that multiple learning platforms can reuse the same underlying Shapeshift codebase.

This means improvements to shared Shapeshift functionality can potentially benefit all Portals using that codebase.

However, each Portal still runs as a separate environment with its own database and configuration.

A useful way to think about this is:

Shapeshift codebase

The shared application and product functionality.

Portal

A separately deployed instance of that application.

Organization

A way of segmenting learners and management inside that Portal.

Branding

Where Portal branding is enabled, the CMS includes a Brand area.

This controls visual settings for that Portal, including:

Platform title
Logos
Browser and device icons
Splash images
Fallback imagery
Color palette
Typography

These settings override the default branding provided by the shared frontend.

The Brand area is therefore one part of a Portal's configuration, but it does not define the Portal itself.

A Portal also includes its own data, environment settings, integrations and operational configuration.

Frontend and user experience

Portals will typically reuse the same core frontend structure and functionality.

This means the overall LMS experience can remain consistent while each Portal uses its own:

Branding
Content
Learners
Organizations
Learning Paths
Reporting
Configuration

In many implementations, the layout, navigation and core interaction patterns will therefore remain broadly consistent across Portals.

If one Portal requires significantly different navigation, workflows or functionality, this may require additional frontend development rather than simple Brand configuration.

Content

Each Portal has its own CMS and content.

This means Courses, Lessons, Quizzes, Learning Paths, Organizations and other content are not automatically shared between Portals.

Where the same learning content is required in multiple Portals, the implementation needs to determine how that content should be maintained.

For example, content could be:

Created separately in each Portal
Imported or migrated between Portals
Maintained through a bespoke synchronization process
Managed through another shared content workflow

There is no assumption that updating content in one Portal automatically updates another.

Users

User accounts are separate between Portals.

This provides clear separation of:

Personal information
Enrollments
Progress
Certificates
Reporting data
Organization membership
Account access

The same email address could potentially exist as a user in more than one Portal because those accounts belong to separate databases.

Authentication requirements should be agreed as part of the Portal implementation.

For example, Portals might use:

Separate username/password accounts
The same SSO provider
Different SSO providers
Separate identity configurations

Using the same identity provider does not automatically make the learner records shared.

Domains and URLs

Each Portal will normally have its own URL or domain.

These are deployment settings rather than Brand settings in the CMS.

Plume will normally configure these as part of the environment setup.

A Portal might therefore have its own:

LMS domain
CMS domain
API domain
Other service URLs

The exact domain structure depends on the client's implementation.

Email configuration

Email sender configuration is also managed at environment level rather than through the Brand area.

Each Portal can therefore have its own sender configuration where required.

This includes settings such as:

Sender email address
Sender verification
Email service configuration
Notification delivery environment

If multiple Portals should send from the same domain or email service, that needs to be agreed and configured appropriately.

Integrations

Integrations are one of the most important considerations when introducing additional Portals.

Because each Portal has its own environment and database, an existing integration does not automatically work across a new Portal.

For every integration, the implementation needs to determine whether the new Portal should:

Use the same external account
Use the same API credentials
Use different API credentials
Write into the same external dataset
Maintain completely separate data
Require additional synchronization or mapping

For example, a CRM, payment provider or identity provider might support several Portals using the same account, but this could merge data from those Portals.

Alternatively, each Portal might need its own account or credentials to preserve separation.

This should be agreed during implementation rather than assumed.

Payments and ecommerce

Where a Portal uses paid learning, payment configuration also needs to be considered separately.

A new Portal may need:

Its own payment provider account
Separate products or price IDs
Different currencies
Different tax configuration
Separate transaction reporting

Alternatively, several Portals could potentially share a payment account if the commercial and reporting model supports it.

This is an implementation decision rather than a standard Portal behavior.

Reporting

Each Portal has its own reporting data because each Portal has its own database.

Reporting can therefore be configured independently.

If a client needs consolidated reporting across several Portals, this would require an additional reporting or data integration layer.

It should not be assumed that a dashboard in one Portal automatically includes data from another.

Feature configuration

Portals can also differ in which Shapeshift capabilities are enabled or exposed.

Examples might include:

Course Library
Organizations and Sub-Groups
Learning Paths
Notes and Bookmarks
Certificates
CPD Hours or CEUs
Quizzes
Surveys
SCORM
Reporting
Impersonation
Ecommerce

However, the amount of variation supported without development depends on how the shared codebase has been implemented.

If one Portal requires functionality that the others do not use, Plume may need to configure or extend the shared implementation accordingly.

Data isolation

One of the most important characteristics of the Portal architecture is data separation.

Each Portal uses its own database, so learner and learning data is isolated from other Portals.

This is different from Organizations, which provide logical segmentation within one shared Portal database.

This distinction is important when deciding which architecture is appropriate.

If the requirement is:

"These users should only see their own learners and content"

an Organization may be sufficient.

If the requirement is:

"This needs to operate as its own platform with its own users, content, configuration and data"

a Portal is more likely to be appropriate.

What is shared?

A Portal setup can potentially share:

Shapeshift application code
Product improvements
Common components
Deployment processes
Development practices
Some third-party services
Some integration logic

What is normally separate?

A Portal normally has separate:

Database
CMS content
Learners
Organizations
Enrollments
Progress
Certificates
Reporting data
Branding
Environment settings
Domains
Integration credentials where required

Implementing a new Portal

Shapeshift provides the architecture required to support multiple Portals, but creating a Portal should be treated as an implementation project rather than a simple CMS configuration task.

Plume will normally work with the client to agree:

Branding
Domains
Content requirements
User migration or account creation
Authentication
Notifications and email sender configuration
Reporting
Integrations
Payments
Environment settings
Any differences in functionality or user experience

The effort required depends largely on how closely the new Portal can follow an existing implementation.

A Portal using the same features, integrations and overall workflow may require relatively little additional development.

A Portal with different integrations, authentication, ecommerce, navigation or workflows may require significantly more implementation work.

When should I use a Portal?

A Portal is most appropriate where the requirement is for a genuinely separate platform experience.

Use Organizations when you need to segment users within one platform.

Consider Portals when you need separation of:

Brand
Data
Content
Users
Integrations
Reporting
Platform configuration

If it is unclear which model is appropriate, Plume can help determine whether the requirement is better solved through Organizations, Sub-Groups, configuration or a separate Portal.