Provisioning and Sync: How User Data Flows Into Continu
Follow

May 10, 2026 14:48

The data foundation underneath every learning program — how partners, customers, channel reps, franchisees, and employees actually arrive in Continu, how their attributes stay current, and how to keep the source data clean enough that segmentation, automation, and reporting all work.

Why Provisioning Matters

Continu is downstream of your source systems.

Every Smart Segmentation rule, every automation trigger, every report, every notification audience — all of them depend on user data that originated somewhere else. A partner record in your PRM. A customer admin in your CRM. An employee in your HRIS. An identity in your IdP.

If that source data is wrong, late, or incomplete, every downstream layer of Continu inherits the problem. Bad sync becomes bad segmentation becomes bad automation becomes bad reporting becomes bad decisions.

Most program failures that admins describe as "the platform broke" are actually data failures the platform inherited. The PRM hadn't synced the partner's tier change. The HRIS hadn't pushed the new hire yet. The CRM had three different spellings of the same plan name. None of those are Continu bugs. All of them produce the same symptom: a learning program that doesn't reach the right people.

This guide is about the layer beneath the platform — how data gets in, how it stays current, and how to design provisioning that produces programs you can trust.

What Provisioning Actually Is

Provisioning is the process by which users and their attributes enter and stay current inside Continu.

Three things happen at provisioning time:

A user is created — a record exists in Continu for the first time.
Attributes are populated — the user's tier, region, role, status, hire date, and other fields are filled in from the source system.
The user becomes addressable — they can now appear in segments, receive assignments, attend workshops, and show up in reports.

After the initial provisioning, the user is also kept current through ongoing sync. When their attributes change in the source system, those changes propagate into Continu — usually quickly, sometimes after a delay, occasionally not at all if the integration is misconfigured.

Provisioning is a contract: source X owns these attributes; Continu inherits them. Get that contract right and the platform stays clean. Get it wrong and you accumulate data debt.

The Provisioning Sources

A typical Continu deployment pulls users from several sources at once. Each has a different cadence, fidelity, and ownership model.

HRIS (Human Resources Information System). Workday, BambooHR, ADP, Rippling, and similar systems are typically the source of truth for employee data — name, email, department, manager, location, hire date, employment status. HRIS sync is usually the cleanest and most reliable provisioning source because it represents an internal system you control.

PRM (Partner Relationship Management). Impartner, Allbound, PartnerStack, Crossbeam, and similar systems own partner data — partner organization, partner contact role, tier, region, certification status, activation date. PRM sync is the foundation of every partner enablement program. It is typically more variable in data quality than HRIS because partner data changes more often and is partly managed by the partners themselves.

CRM (Customer Relationship Management). Salesforce, HubSpot, and similar systems own customer data — customer organization, customer admin contacts, plan, lifecycle stage, contract dates. CRM sync powers customer education programs. Coordinate with the customer success team's data definitions; if they call it "Onboarding" and your sync calls it "Implementation," your segments will lie.

Identity providers and SSO. Okta, Azure AD, OneLogin, Google Workspace, and similar systems may provision users into Continu through SCIM or create them on first login through SSO. The IdP is often the authentication source of truth, and sometimes the user-creation source as well.

Manual creation. An admin creates a user directly in Continu. Useful for edge cases — a contractor who isn't in any source system, a partner contact who needs immediate access before PRM sync catches up, a one-off pilot user. Do not let manual creation become the default; it accumulates debt fast.

API-driven creation. Custom integrations can push users into Continu from any system that exposes an API. Typically used for franchise operations systems, member databases, education platforms, or other systems Continu doesn't have a native integration with.

Most organizations of any size use three or four of these sources at once. Knowing which source owns which population — and which fields — is the first step in designing reliable provisioning.

The Sync Lifecycle

Every sync event moves through a five-step lifecycle. Understanding where each step can fail makes debugging easier.

Source change detected. The source system records that a user was created, updated, or deactivated.
Sync event sent to Continu. The source pushes the change, or Continu pulls it. Timing depends on the integration's configuration.
Attribute mapping applied. Continu translates source fields into Continu fields based on the configured mapping.
User record created or updated. The user appears in Continu, or their existing record changes.
Downstream effects. Smart Segmentation reevaluates. Automations may fire. Reports update on the next refresh.

Failure modes by step: the source may not detect the change (rare); the sync may not deliver (network, auth, rate limiting); the mapping may misroute the field (most common); the record may collide with an existing user; downstream effects may fire unexpectedly when retroactive evaluation kicks in.

If a user "isn't getting the right program," walk the lifecycle from source to downstream and find the broken step.

SSO and Provisioning Are Not the Same Thing

A common source of confusion: SSO and provisioning are related but distinct.

SSO (Single Sign-On) is about authentication — who is allowed to log in, and how their identity is verified. SSO does not, on its own, populate attribute data beyond the basics needed for login (email, name, sometimes a unique identifier).

Provisioning is about user creation and attribute population — who exists in the system and what data they carry.

The two intersect in three common patterns:

SSO with just-in-time creation. The user does not exist in Continu until they log in for the first time. SSO authenticates them and creates a basic record. Attributes beyond the minimum are populated from another sync source (HRIS, PRM, CRM) or remain sparse until the next sync.
SCIM provisioning + SSO. The IdP (Okta, Azure AD) actively pushes users into Continu through SCIM, with full attribute data, before they ever log in. SSO then handles authentication when they show up. This is the cleanest pattern for internal audiences with rich IdP attribute data.
Separate sync + SSO. The HRIS, PRM, or CRM provisions users with full attributes; SSO only handles authentication. The two systems are independent.

Pick the pattern deliberately. Mixing them without intent is how you end up with duplicate user records, partial profiles, or users who can log in but don't have segment-relevant attributes populated.

Sync Cadence and Timing

Different integrations sync at different speeds. Knowing the cadence is critical for designing automations that depend on timely data.

Real-time (near-instant). A change in the source propagates to Continu within seconds or minutes. Most modern HRIS and CRM integrations operate this way for high-priority events. Best for triggers that need to fire on the day of the event — a new hire onboarding rule, a partner activation rule.

Scheduled (nightly, hourly). The integration syncs on a fixed schedule, typically overnight or every few hours. A new partner activated on Monday afternoon may not appear in Continu until Tuesday morning. Plan automation timing accordingly.

Event-driven. The source system pushes specific events (new user, role change, status change) but does not continuously sync everything. Other attribute changes may arrive through a separate scheduled sync.

Manual triggers. An admin runs a sync on demand. Useful for testing or one-time backfills. Not appropriate for production cadence.

The strategic question: does the program I'm designing assume the data is current within minutes, hours, or days? Match your automation timing to your sync timing — or you'll build rules that fire before the data arrives.

Attribute Mapping

Attribute mapping is where most "this segment isn't matching" issues actually live.

Each source-to-Continu sync has a configuration that translates source fields into Continu fields. Source field "Job_Title__c" maps to Continu field "title." Source field "Region_c" maps to "region." Source field "TierLevel" maps to "partner_tier."

Three things to watch:

Field naming differences. A source system's "Plan" field may be Continu's "plan_name" or "subscription_tier." If the mapping is off, the segment that filters on plan won't match.

Value normalization. Source values can drift. The CRM may have "Pro," "Professional," and "professional" all referring to the same plan. Continu's segment looking for "Pro" will miss the other two. Either normalize at the source or build segments that handle the variants.

Required vs. optional fields. Some Continu fields are required for the user to exist. Others can be empty. If a required field has no source mapping, users may fail to provision entirely.

Custom fields. Beyond the standard fields, most organizations need custom attributes — partner_specialty, customer_health_score, certification_expiry_date. Custom fields require explicit mapping. Document them.

Transformations. Some integrations support data transformations — splitting a full name into first/last, converting date formats, deriving a field from multiple sources. Useful but adds complexity. Audit transformations periodically; they're a common source of silent breakage.

The strategic question: when a downstream segment or report looks wrong, the first place to look is almost always the attribute mapping. Confirm the field is mapped, the values are normalized, and the data is actually arriving.

Best Practices

Habits worth internalizing before you configure another integration:

Define the source of truth per attribute. For each attribute Continu uses, decide which source owns it. The PRM owns partner tier. The HRIS owns hire date. The CRM owns customer plan. Document the contract. When two sources both push the same attribute, you've created a fight Continu doesn't know how to resolve.

Document the field mapping. Every source-to-Continu mapping should have a written record of which source fields map to which Continu fields, including any transformations. Six months from now, when an admin asks "where does the partner tier come from?", you should have an answer that doesn't require reverse-engineering.

Audit segment populations regularly. Pick five high-value segments. Run them quarterly. Compare the population to your expectation. If the count drifts, the data is drifting underneath.

Plan for null values and edge cases. What happens when a source attribute is empty? When a value is malformed? When a field changes type? Build segments and automations defensively — assume the source data has gaps.

Test syncs before going live. New integrations should be tested against a small subset of users — a handful of HRIS records, a few partner contacts, a couple of customer admins — before opening the floodgates. Confirm attributes populate correctly. Confirm segments match. Confirm automations behave.

Set a quarterly attribute hygiene review. Once a quarter, sample a few user records across each source. Confirm the data is current and correct. Reconcile any discrepancies at the source, not in Continu.

Use unique identifiers, not display names. When matching users across systems, rely on stable IDs (employee ID, partner ID, customer admin email) rather than display names that can change. Names change when people get married. Email addresses change when companies rebrand. Stable identifiers don't.

Plan reactivation behavior. When a deactivated user comes back — a partner who left and returned, an employee who transferred and was rehired — what should happen? Do they get a new record? Reactivate the old one? Inherit prior assignment history? Decide deliberately.

Coordinate with the systems-of-record team. The Continu admin is rarely the same person as the Salesforce admin or the Workday admin. Build a relationship. When they make a structural change, you need to know before your segments start drifting.

Anti-Patterns to Avoid

The provisioning mistakes we see most often:

Multiple sources of truth for the same attribute. When both the CRM and the PRM push "tier" and they disagree, Continu can't resolve the conflict — and the latest update wins, possibly wrongly. Pick one source per attribute.
Hard-coded field assumptions. A segment that filters on "Plan equals Pro" breaks the day the source renames the plan. Use stable identifiers, build flexible segments, or normalize at the source.
No null handling. Segments that don't account for empty fields silently miss users. A "Partners with active certification" segment that filters on a populated certification_status field will exclude partners whose status hasn't synced yet.
Letting source data go stale. A source system you stopped maintaining is a source you can't trust. The data still flows to Continu, but it represents a past reality. Audit, refresh, or retire.
Treating sync as set-and-forget. Integrations break. Mappings drift. APIs change. Without periodic review, you only find out something's wrong when a downstream program misbehaves.
Building automations on attributes that aren't reliably populated. If an attribute is null half the time, automations keyed to it will fire half-correctly. Either fix the source data or design around the unreliability.
Manual creation as a workaround. When PRM sync is broken, the temptation is to manually create the missing partner contacts. The temptation grows. Six months later, half your partner population is manually maintained. Fix the integration.
Skipping the documentation step. Undocumented integrations work fine until the person who built them leaves. Then they don't work at all, and no one knows why.

Provisioning Across the Continu Architecture

Provisioning sits beneath every other layer of the platform.

Smart Segmentation depends on attributes. Every Smart Segmentation rule reads attribute values populated through provisioning. Wrong values, wrong populations.

Automations depend on segmentation. Every rule-driven assignment, notification, and action is scoped by a segment. The segment is downstream of the attribute. The attribute is downstream of provisioning.

Reporting depends on user populations. Every meaningful report is scoped to a population defined by Smart Segmentation. If provisioning is missing users — or marking them wrong — reports will mislead.

Notifications depend on user data. Email addresses, preferred names, language preferences — all originate in source systems. Bad data means bad sends.

Workshops depend on user identity. Attendance tracking ties workshop participation to user records. If users don't exist in Continu, they can't attend. If they exist with wrong identifiers, attendance won't sync correctly.

A well-designed provisioning practice is clear sources of truth + documented mappings + regular audits + defensive segment design + a relationship with the source-system teams. The platform handles delivery once data arrives. Your job is to make sure the data arrives — and is correct.

External Audience Patterns

External audiences require the most careful provisioning, because the source systems are typically managed by other teams (or by the partners/customers themselves) and the data quality varies more.

Partner provisioning. Build the contract with your PRM team. Source attributes typically include partner organization, partner contact role, tier, region, certification status, activation date, and partner manager assignment. Confirm sync cadence — daily is fine for most partner programs; real-time is better for activation events that should immediately trigger onboarding. Audit partner segments quarterly; partner data changes constantly.

Customer admin provisioning. Build the contract with your customer success operations team. Source attributes typically include customer organization, customer admin role, lifecycle stage, plan, contract dates, and CSM assignment. Coordinate lifecycle stage definitions explicitly — your "onboarding" must mean the same thing as their "implementation" or your reports will diverge.

Channel rep provisioning. Channel programs often pull from multiple sources at once — a master distributor system, individual reseller PRMs, and sometimes self-service registration. Design carefully for de-duplication; the same channel rep may exist in multiple sources with slightly different identifiers.

Franchise operator provisioning. Franchise systems are often custom-built or industry-specific, and the integration is typically API-driven. Source attributes typically include franchise location, ownership type, operator role, regional manager, and audit status. Franchise data changes less often than partner or customer data, but the changes are higher-stakes (a new operator running a location).

A note on data hygiene for external audiences. Every external sync is downstream of a system you don't fully control. Build segments defensively. Plan for nulls. Audit populations regularly. The cleanest external provisioning still produces less reliable data than the messiest internal HRIS.

Internal Audience Patterns

Internal provisioning is typically the cleanest because the HRIS is a single source of truth managed by a team you can talk to.

HRIS-driven employee sync — the standard pattern. Real-time or near-real-time, full attribute set, reliable. Most internal automations should key off HRIS attributes.
SSO/IdP-driven creation — useful when you want users to exist on first login but don't want to wait for HRIS sync (for example, contingent workers or contractors who use SSO but aren't full employees in the HRIS).
Manual exceptions — for users who don't fit any source system (board members, advisors, specific contractors). Document them so they don't accumulate as orphans.

Internal provisioning is typically a "set up well, then maintain quietly" pattern. The hard work is the initial design; ongoing maintenance is mostly about catching field mapping drift when the HRIS team makes changes.

Known Behaviors and Limits

A few things worth knowing in advance:

Sync timing varies by integration type. Real-time integrations propagate within seconds; scheduled integrations may take hours; manual syncs wait until someone runs them. Confirm what your team has configured.
A failed sync may not be loud. Some integrations fail silently. Audit the integration health on a recurring cadence — don't wait for a downstream program to misbehave.
Source-system unavailability does not delete users in Continu. If your HRIS goes down, existing Continu users persist with their last-known attribute values. New users won't provision until the integration is restored.
Reactivation behavior depends on configuration. When a deactivated user is reactivated in the source, Continu may create a new record or restore the old one — depending on how unique-identifier matching is configured.
Bulk syncs take time. A first-time sync of 50,000 users does not complete instantly. Plan integration cutovers with the processing time in mind.
Cross-system collisions can produce duplicates. A partner contact who also appears in your CRM as a customer admin may end up with two user records unless de-duplication is configured. Watch for this in mixed B2B2C deployments.
Field changes at the source can ripple unexpectedly. When the HRIS team renames a field, your mapping may break silently — segments stop matching, automations stop firing. Quarterly audits catch these.
SSO-only users may have sparse attribute data. A user created on first login via SSO carries only the attributes the SSO assertion provides. The rest populate when another sync source catches up — or stay empty.

Provisioning and Sync: How User Data Flows Into Continu Follow