Continu Extend is the way you give partners, customers, and vendors their own learning experience — running on Continu, but branded as yours or theirs. Each Extend portal has its own login page, content library, users, and analytics. This article covers what Extend is, when to use it, and how it fits with your internal Continu instance.

What Extend is

Extend creates white-labelled enablement portals for audiences that aren’t your employees. Each portal is configured independently — its own brand, its own users, its own content, its own reports — but everything runs on the same Continu instance you use internally.

The portal experience looks like the brand whose audience it serves: your brand, your partner’s brand, or a co-branded mix. Learners signing in don’t see Continu’s logo or interface. They see a learning environment built for them.

Behind the scenes, your admins manage every portal from one Continu admin console. You don’t need separate logins, separate billing, or separate platforms.

When to use Extend

Use Extend when you need to train an audience that isn’t on your payroll — and where mixing them with your internal employees would compromise content scope, branding, reporting, or compliance.

Common Extend scenarios:

• Customer education — onboarding customers to your product, ongoing enablement, certification programs
• Partner enablement — channel partners, resellers, system integrators who sell or implement your product
• Vendor training — contractors, third-party support teams, or service providers who need to learn your processes
• Franchise operations — operators of franchise locations who need consistent training under your brand
• Multi-brand parent companies — a single parent training employees across multiple sub-brands, each with its own portal

When Extend is not the right fit: a single small group of external contractors who only need access to a handful of internal courses. For that, use the External User role inside your main Continu instance — it’s lighter weight and doesn’t need its own portal.

The portal model

Each Extend portal is a logically independent learning environment with its own:

• Login page and URL — hosted on its own domain or subdomain (e.g., learn.yourpartner.com)
• Brand — logo, colors, fonts, cover images
• User population — separate from your internal user list; the same person can exist in multiple portals without cross-contamination
• Content library — each portal gets its own; content can be shared across portals or kept exclusive to one
• Reports and analytics — segmented per portal so the data for each audience stays clean

Critical isolation rule: external users in a portal never see internal content, internal users, or analytics. The audience scoping is enforced at the portal level, not just by Smart Segmentation rules.

What each portal includes

How users get into a portal

Admins add users to an Extend portal through manual invite or bulk upload. For individual or small populations, invite users directly from the portal admin. For larger populations, upload a CSV with the user list and the portal will provision accounts and send invitation emails.

Once a user is in the portal, the same user lifecycle rules apply as in your internal instance — suspending, reactivating, role changes, and audience attribute updates all work the same way.

Content flow

Content lives in the portal it was created or assigned to. There are three patterns:

Portal-exclusive content. Content created inside a portal stays inside that portal. Most customer-facing content (product training, certifications specific to one offering) sits here.

Shared content across portals. Some content makes sense across multiple portals — for example, foundational courses you want every partner and every customer to take. Share it once; updates propagate to every portal it’s published to.

Internal-only content. Internal training never crosses into Extend portals. The isolation rule is enforced at the platform level.

Audience scoping is set on the extend account itself, not on individual users inside it. Every user in an extend account inherits the same segmentation. If you need different audience scopes for different cohorts of external users, build a separate extend account for each cohort.

How segmentation works in Extend

Segmentation in Extend behaves differently from segmentation inside your internal instance, and getting this right at design time saves rework later.

Segmentation is applied to the extend account, not to users inside it. The audience rules you build sit on the extend account itself. Every user inside that account inherits the same segmentation — you can’t further split users within a single extend account into different scopes.

If you need different scopes, you need different extend accounts. A partner program with three tiers (Gold, Silver, Bronze) where each tier should see different content needs three extend accounts, not one extend account with three audience segments.

Build the segmentation rules inside the extend account. Audience rules are configured from within the extend account’s admin, the same way Smart Segmentation works inside your internal instance — just scoped to that one account.

This model keeps the data isolation guarantee clean: because every user in an extend account inherits the same scope, there’s no risk of one external user accidentally seeing content meant for a different external population.

Reporting on Extend

Each portal has its own reporting scope. Open the Reports area inside a portal and you’ll see:

• Active learners
• Completion rates by content
• Certification status
• Engagement trends
• Audience-level cuts (by partner tier, customer segment, region)

The same standard report types you use for internal training (completion, learner activity, content performance) are available per portal. Cross-portal roll-ups for executive views are also available — useful for “how many learners have we trained across the whole external ecosystem this quarter” questions.

Extend vs External User role — when each applies

These two concepts are easy to confuse:

If you’re not sure, your CSM or implementation lead can help size the decision against your roadmap.

Setting up an Extend Instance

We've grouped the prep below by when each piece is needed, so your team can sequence the work without waiting on us. The earliest items are decisions your project team can make on its own; the IT and integration items come later, which is the natural point to loop in your internal technical contact.

Step 1 — Decisions your project team can make first

These are scoping and ownership decisions. No technical involvement needed yet.

• Portal audience. Who's signing in to this portal? Internal employees, partners, customers, or a mix. Approximate user count.
• Project owner on your side. The single person we'll coordinate with end-to-end.
• Executive sponsor. The person who unblocks decisions if scope or timeline shifts.
• L&D / training program lead. Who owns the learner experience and content strategy.
• Day-one use cases. Three to five specific learner journeys this portal needs to support at launch.
• Success metrics. Two or three measurable outcomes that define a successful launch.

Step 2 — Information to gather (loop in IT here)

This is the point where your internal IT/integration contact joins. The decisions here drive how users get into the portal and how the portal connects to the rest of your stack.

• Unique identifier. What identifies a user uniquely — customer ID, email, or a vendor-specific ID. It needs to be stable across name changes and email updates.
• Sync mechanism. How users get into Continu — SFTP from your HRIS or CRM, manual upload, or a combination.
• SSO provider. Okta, Azure AD, OneLogin, Google Workspace, or other.
• HRIS or CRM lead. The person who can configure the export from the source system.
• Integration list. Anything else the portal needs to connect to — video, messaging, content libraries, CRM.
• Compliance program list (if applicable).

Step 3 — Brand assets for portal creation

These are the assets we need to build the portal's look and feel. Same package we ask for in any branded Continu setup.

• Brand guidelines or overview — colors, use of logo, dos and don'ts. A one-page summary is fine.
• Logos — all variations in high-resolution .svg or .eps format.
• Primary and secondary brand colors — hex codes.
• Five high-resolution photos for the login screen — minimum 1920 × 1080.

Quick checklist

Everything from Steps 1–3 in a single list:

• Portal audience and approximate user count
• Project owner named
• Executive sponsor named
• L&D / training program lead named
• Three to five day-one use cases documented
• Two to three success metrics defined
• Unique identifier decided
• Sync mechanism chosen
• SSO provider confirmed
• HRIS or CRM lead identified
• Integration list outlined
• Compliance program list (if applicable)
• Brand guidelines/overview ready
• Logos in high-res .svg or .eps (all variations)
• Primary and secondary brand colors (hex)
• Five high-res login-screen photos (1920 × 1080 minimum)

For the standard implementation context behind these items, see Preparing for Your Kickoff — same decisions, more depth on each.

Common pitfalls

See Also

• External Users — for the lighter-weight External User role used inside your main Continu instance
• User Management: Who Has Access to What, and Why — for how user roles work in Continu
• Smart Segmentation: Designing Populations That Maintain Themselves — for the audience rule engine that runs inside each portal
• Provisioning and Sync: How User Data Flows Into Continu — for the broader user lifecycle model
• How Continu Works — for the foundational platform overview