Some organizations sync user data into Continu from more than one source — different brands, different regions, different companies under one parent, or systems consolidated after a merger. This guide covers how to design that setup so the brands stay clean and reporting works at every level.

This applies to any combination of source systems — multiple HRIS instances of the same product, different HRIS products in different brands, a mix of HRIS and IdP-based sync, or a combination including a custom data warehouse. The decisions below are the same regardless of which systems are involved.

When this guide applies

You have more than one source system feeding users into one Continu instance, and at least one of these is true:

• Different brands or business units run on separate HRIS instances
• Different countries or regions run on separate HRIS instances
• A merger or acquisition brought systems together but they haven’t been unified
• One brand uses a full HRIS feed and another uses a smaller team or contractor feed
• You have internal employees on an HRIS sync plus external partners or customers on a separate feed

If you’re running a single source feed into Continu, you don’t need this guide — the standard SFTP setup covers you.

Single Continu instance vs multiple

The first question is whether you want one Continu instance with everyone in it, or separate Continu instances per brand.

One Continu instance for everyone is the right answer when:

• Learners may move between brands and you want their history to follow them
• You want a single source of truth for organization-wide reporting
• Content libraries are shared across brands, even partially
• Compliance reporting needs to roll up to a parent organization

Separate Continu instances is the right answer when:

• Brands are legally separated and cannot share user data
• Each brand needs its own branded learner experience that can’t be achieved with theming alone
• Compliance or data residency requirements forbid combining the data
• Each brand operates fully independently with no shared workflows

The rest of this guide assumes one Continu instance with multiple sources. If you went with separate instances, each instance is a standard single-source setup — see HRIS Integration (via SFTP) - Field Guide for each one.

Align on field structure across sources

The single biggest cause of operational pain in multi-source setups is misaligned field structures. Brand A puts office location in Location 3, Brand B puts it in Location 2, and now every cross-brand report needs custom joins to make sense.

The fix is process, not technology: align field structures across all sources before anyone builds.

Run a single field-design session with HRIS leads from every source in the same meeting. Walk through every field in the standard template together and agree on:

• Which fields are populated, which are intentionally left blank
• Which hierarchy level each concept maps to (Department 1 = function, Department 2 = sub-function, Department 3 = team — or whatever you agree on)
• Which field is the unique identifier (the answer should be the same for everyone)
• Which fields drive segmentation and which are reporting-only
• How status values map to Continu’s active, suspended, and terminated states

A brand can leave a field empty if it doesn’t apply. They cannot use the field for a different concept than the other brands. The latter breaks reporting.

This conversation will surface real disagreements — different brands genuinely have different ways of thinking about employee data. The job of the alignment session is to land on a structure that every brand can live with, even if it isn’t anyone’s first choice. Continue with the field design only after that’s settled.

Per-source SFTP endpoints

Continu supports a separate SFTP endpoint per source. Each source gets:

• Its own credentials and drop folder
• Its own delivery schedule
• Its own status-value mapping
• Optionally, its own slightly different file format

When to use separate endpoints:

• Always, if the sources have different schedules or formats. A single endpoint forces all sources to align on timing.
• Always, if different teams own the different sources. Separate endpoints mean each team operates their own integration without coordinating daily file timing.
• Often, when status-value mappings differ. Separate endpoints let each mapping live with its source.

When a single endpoint could work:

• If you have one HRIS team that owns every source feed and the formats are identical, you can sometimes simplify to a single endpoint. This is rare.

Status-value mapping per source

Different HRIS systems represent employment status differently. Some use single-character codes (A, T, S), some use descriptive strings (Active, Terminated, On Leave), some use compound values.

For each source, document the mapping from that source’s values to Continu’s three states (active, suspended, terminated). Get this mapping confirmed in writing before the first file load. It’s tedious to debug a sync where status mappings are wrong and harder to retroactively fix records that were terminated when they should’ve been suspended (or vice versa).

JIT provisioning conflicts with SFTP

If SSO Just-In-Time (JIT) provisioning is enabled at the same time as SFTP, users can log in via SSO and self-create accounts before the daily HRIS file arrives. When the file then tries to create the same user with the HRIS identifier, the identifiers don’t match and the record fails.

This shows up most often in multi-source setups because day-one users at any source brand can hit the SSO sign-in before that brand’s file runs, and different brand sign-in flows may not all share JIT settings.

Recommendation: disable JIT provisioning anywhere SFTP is the source of truth. Make the HRIS file the only path through which users are created. JIT and SFTP both creating users for the same population is the architectural problem; turning off JIT removes it.

Reporting across sources

A multi-source setup gives you reporting flexibility you wouldn’t have with separate instances — but only if the data structure supports it.

Per-source reporting — Each brand wants to see “their” data without the other brands’ noise. Achieved by filtering reports on the source prefix in the user ID (or a dedicated source/brand field). Easiest when the prefix convention is consistent.

Cross-source roll-up — The parent organization wants global numbers. Achieved by leaving the filter off and aggregating across all users. Easiest when the field structure is aligned and the same concepts are stored in the same fields across brands.

A custom Source or Brand field is a cheap way to make per-source filtering robust. Populate it from the source export step. Use it in reports and audience rules wherever you need brand-level scoping.

Governance — who owns what

Multi-source setups need explicit ownership decisions or they drift. Three roles need clear owners:

Field structure owner. One person (usually a CS or L&D lead at the parent org) owns the canonical field map. When a brand wants to add a new field or repurpose an existing one, this person makes the call. Without a single owner, brands diverge.

Per-source HRIS lead. Each source has its own HRIS lead who owns the file from their side — schedule, format, data quality, status mapping. They don’t need to coordinate with each other on day-to-day operations, but they do need to coordinate with the field structure owner when changes affect everyone.

Continu admin team. Manages users post-sync, handles role assignments and content access, and is the escalation point when sync issues surface. Usually centralized at the parent org so cross-brand patterns get spotted.

A weekly or biweekly sync between the field structure owner and the per-source HRIS leads catches drift before it becomes a problem. Most multi-source setups that fall apart did so because that conversation stopped happening.

Common setups

Multi-brand under one parent

Several brands operate under one parent org. Each brand has its own HRIS instance. Employees rarely move between brands but compliance reporting rolls up to the parent.

• One Continu instance, multiple SFTP endpoints
• Brand-prefixed user IDs
• Aligned field structure across brands
• Brand field populated for per-brand filtering
• Compliance reports aggregate at the parent level

Multi-region for one global brand

One brand operates in multiple regions on separate regional HRIS instances (often for data residency reasons). Employees may move between regions occasionally.

• One Continu instance, multiple SFTP endpoints
• Region-prefixed user IDs (NA_, EU_, APAC_)
• Aligned field structure
• Region field populated
• Plan for intra-region rehires: same prefix, reuse ID. Plan for cross-region transfers separately.

Internal employees plus external partners or customers

The main population comes from the HRIS. A second population — contractors, partners, customer learners — comes from a different source (a CRM, a manual CSV, or a separate access portal).

• One Continu instance, separate sync mechanism for the external population (often a CSV upload or API push rather than SFTP)
• Different prefix convention (EXT_ or PARTNER_)
• External user visibility setting on content (separate from internal segmentation)
• Status lifecycle managed by whoever owns the external relationship, not by HRIS

Post-merger consolidation

Two organizations merged. The acquiring org has its HRIS; the acquired org is still on its own. Eventually they’ll consolidate; in the meantime, both feed Continu.

• One Continu instance, two SFTP endpoints (one per legacy HRIS)
• Acquiring-org prefix for the parent population
• Acquired-org prefix for the integrated population
• When the HRIS consolidation completes, plan a one-time migration: re-prefix the acquired users, point everything at the new HRIS feed
• Document the cut-over so future audits can trace identifiers back

Pre-flight checklist for a multi-source setup

• One vs many Continu instances decided
• All sources identified and HRIS leads named
• Field structure aligned across sources (single design session run)
• User ID prefix convention defined for each source
• Per-source SFTP endpoints set up
• Status-value mapping documented per source
• JIT provisioning disabled (or scoped to populations not on SFTP)
• Reporting strategy planned — per-source filtering and cross-source roll-up
• Field structure owner identified
• First file run per source in test, validated before going live

Common pitfalls

See Also

• HRIS Integration (via SFTP) - Field Guide — field-by-field reference for the SFTP file
• Provisioning and Sync: How User Data Flows Into Continu — the strategic anchor for user provisioning
• Continu Glossary — canonical vocabulary for the sync and provisioning terms used here