How settings decisions shape what partners, customers, channel reps, franchisees, and employees actually experience — and why "just a checkbox" is rarely just a checkbox.
Why Settings Matter
Most learning programs treat settings as a one-time configuration task. Set the brand colors, pick the login method, accept the defaults, move on.
The problem with that posture is that nearly every program issue traced back over time — partners complaining about access, customers confused about what they can see, employees getting the wrong notifications, audits surfacing gaps — traces back to a settings decision someone made early and never revisited.
Settings aren't configuration. Settings are program design decisions in disguise. The toggle that controls "who can self-enroll." The dropdown that picks how often a recertification reminder fires. The text field that holds the partner-facing display name. Each one is small. Together, they shape what every learner across every program actually experiences.
This guide is about treating settings with the seriousness they deserve — knowing what lives where, knowing what the downstream consequence is, and revisiting them on a cadence so the program doesn't drift.
What Settings Actually Is
The Settings area in Continu is the place where tenant-wide configuration lives. Not content. Not programs. The decisions about how the platform behaves — for everyone in your tenant — sit here.
Strip away the categories and Settings does three jobs.
Define who can do what. Permissions, roles, user lifecycle, login methods, SSO, password rules. Identity and access are the foundation everything else stands on.
Set the default experience. Branding, notification templates, language, time zones, calendar integration, email-from addresses. Defaults shape what every learner sees before any program-specific configuration touches them.
Wire the system to the rest of your stack. HRIS, PRM, CRM, identity providers, calendar systems, SCIM provisioning. Integrations turn Continu from a standalone LMS into part of a connected operation.
These are different jobs with different stakes. Permissions affect security and compliance. Defaults affect every learner's experience. Integrations affect everything downstream. Conflating them produces sloppy settings decisions.
The strategic question: for each setting you're about to change, who experiences the consequence, and what motion changes for them?
The Main Categories
Continu's Settings area covers several broad domains. Knowing what lives where saves you from changing the wrong thing.
Identity and access. Login methods, SSO providers, password requirements, MFA settings, session timeouts, user provisioning rules. This is where you decide how learners get into Continu and what credentials they use.
User management defaults. Default roles, default permissions, default segment memberships for new users. These shape what a newly-provisioned learner can access on day one.
Branding and tenant. Logos, colors, custom domains, email branding, login page customization. The visual identity of your tenant.
Notifications and email. Email templates for system notifications, from-address configuration, reply-to handling, notification defaults. The voice the platform uses when it talks to learners.
Content defaults. Default content visibility, default categorization, default expiration policies, default reviewer assignments. The behavior content gets when authors don't override.
Integrations. HRIS connectors (Workday, BambooHR, etc.), PRM connectors, CRM connectors, calendar systems, SCIM, webhooks, API tokens. The wiring between Continu and the rest of your stack.
Locales and time zones. Default language, supported languages, default time zone, time zone display behavior. The localization defaults that affect every learner.
Audit and compliance. Audit log retention, data retention policies, GDPR/privacy controls, export configurations. The settings that determine what evidence the system retains.
Each category has different stakeholders. Identity belongs to IT/security. Branding belongs to marketing. Notifications often span L&D and marketing. Integrations belong to IT plus the integration owner. Putting the wrong stakeholder on the wrong category is a common source of bad settings decisions.
Best Practices
Treat settings changes like program changes. Brief the change, identify the downstream effects, communicate it to affected stakeholders, and document it. A casual settings tweak that breaks a partner cohort's access is the same impact as a casual program change that breaks the cohort's access.
Default to the more restrictive option. When in doubt on permissions, visibility, or access — pick the more restrictive setting. Opening up access later is easier than closing it. The reverse is a security or privacy incident.
Document the rationale for every non-default setting. Why is the session timeout set to 4 hours instead of 30 minutes? Why is the password requirement set to 12 characters instead of 8? Write down the answer next to the setting. When someone else inherits the tenant, they need to know.
Pair every integration with an owner. Workday integration broken? Whose problem is it? The integration owner is the person who knows the connector configuration, the source-system credentials, the failure modes, and how to escalate. Without an owner, the integration becomes a hot potato.
Match notification settings to audience tolerance. Internal employees can absorb more notifications than external partners. Defaults that work for HR might overwhelm a channel partner. Tune notification settings by the audience that receives them, not by a single global default.
Review settings on a cadence. Every six months, a settings review — what's changed in the org, what's changed in the audience, what's changed in the compliance posture. Settings drift quietly; the review catches it.
Test settings changes in a non-production way when possible. Continu may not have a full staging environment, but you can pilot a settings change with a small cohort, role, or segment before applying it tenant-wide. Especially for integrations and identity changes.
Identify the audit-relevant settings. Which settings would a regulator, security auditor, or partner-program reviewer care about? Document those. They will be asked about.
Keep the settings owner list current. Who can change what? If the answer is "anyone with admin access," your settings posture is loose. Tighten the role-permission matrix so settings changes are deliberate.
Anti-Patterns
Settings as a one-time task. Configuring everything at launch and never revisiting. The world changes — your team, your partners, your customers, your compliance posture. Settings configured for 2023 reality don't match 2026 reality.
Treating defaults as decisions. Accepting default settings without thinking about whether they fit your program. Defaults are reasonable starting points, not vetted choices for your specific organization.
Changing settings without communication. Toggling a setting that affects a thousand learners on a Tuesday afternoon with no announcement. Tickets start arriving Wednesday morning. The settings change is fine; the communication motion is missing.
Permissions creep. Granting admin-level access to anyone who asks because it's easier than the right scoped permission. Six months later, twelve people have admin access; you don't remember why eight of them needed it.
Branding decisions made in isolation. Marketing changes the tenant colors and login page without telling the L&D team that customer-facing customers are about to see something different. Internal users notice; partners notice; nobody briefed them.
Notification settings tuned for the loudest complainer. One executive said "I get too many emails" and notifications got turned down for everyone. Now the partner cohort that needed those notifications doesn't get them. Tune by audience, not by anecdote.
Integration owners by default. Workday connector belongs to "whoever set it up two years ago" — and that person left. The integration drifts, breaks, and nobody owns the fix. Re-assign integration owners proactively when people leave.
Audit settings configured at minimum. Setting retention windows at the floor of what's legal. When the audit comes, the retention window expired six months before the data was needed.
Different settings for the same program in different tenants. Multi-tenant or multi-instance setups where the same program runs but with different notification cadences, different branding, different access rules. Learners notice when their experience varies for no reason.
Settings sprawl. Adding integrations, customizations, and overrides without sunset discipline. Five years in, the tenant has 30 integrations, half of which aren't actively used, all of which are potential failure surfaces. Periodic settings cleanup.
In the Continu Architecture
Settings affect every other Continu object — that's why they're tenant-wide.
- Content. Content visibility defaults, default categorization, retention policies. The settings determine what authors inherit.
- Tracks and Journeys. Default access rules, default completion behavior. Programs run within the rules settings establish.
- Assignments. Default assignment behaviors, default notification cadence. Assignments live within the notification settings.
- Smart Segmentation. User attribute sources come from integrations configured in settings (HRIS, PRM, etc.). Segmentation is only as good as the source data.
- Eddy. AI scope, content access, conversation logging — all configured in settings. The AI's posture follows the settings.
- Reporting. Audit log retention, export configurations, data warehouse integration. Reporting only goes as far back as settings allow.
- Notifications. Templates, from addresses, delivery rules. Every notification the platform sends inherits from settings.
The principle: a settings decision is never just a settings decision. It propagates through every program, every cohort, every notification, every report.
External Audience Patterns
Partner-facing tenant configuration. Branding, login experience, partner-directory configuration. The settings that determine what a partner sees the first time they log in. Often the partner's first impression of your program.
Customer-facing tenant or customer-portal configuration. When customers use your Continu tenant directly (for customer education), the settings shape their experience. Login experience, branding, content visibility defaults, notification cadence.
Channel-segment configuration. Multi-tenant channel programs where different reseller tiers see different branding, different content defaults, different notification rules. Settings configuration per channel segment.
Franchise corporate-vs-franchisee settings split. Corporate configures the tenant; franchise operators inherit. Decisions about which settings franchisees can override versus which are corporate-locked.
Member portal configuration. Association or community settings — login methods that match the member-management system, branding that matches the parent organization, integrations to the member database.
SSO with customer-side IdP. Configuring SSO so customers, partners, or channel reps use their own identity provider (Okta, Azure AD, etc.) rather than a Continu-managed account. Settings for the SAML/OIDC handshake, attribute mapping, just-in-time provisioning.
Internal Audience Patterns
HRIS integration for the employee lifecycle. Workday, BambooHR, ADP, or other HRIS as the source of truth for employees. Settings configure the integration; the integration drives provisioning, segmentation, and lifecycle automation.
SSO for employees. Internal identity provider configured for employees. Single sign-on, MFA, session policies. Security team owns these settings; L&D inherits the consequences.
Manager hierarchy settings. How manager relationships flow from HRIS to Continu. The manager hierarchy drives manager-of-direct-reports views, escalation paths, and reporting.
Compliance retention settings. Audit log retention, completion record retention, data export configurations. Compliance and legal own these settings; L&D inherits the audit-readiness.
Notification cadence for internal cohorts. Email cadence settings tuned for the internal employee experience — less aggressive than external partner notifications usually need.
Internal branding and tenant. Company logo, color palette, internal portal customization. Maintained by marketing or brand team; visible to every internal employee on every page.
Department or business-unit segmentation. Default segments derived from HRIS attributes — department, location, level, function. Drives who gets what content.
Known Behaviors and Limits
Settings changes propagate, but not always instantly. A change to default access rules takes effect for new content/users; existing content/users may need a separate migration or reprocess to pick up the change.
Integrations have their own lag. When you update an HRIS-driven attribute, the Continu attribute updates on the next sync cycle, not immediately. Plan settings changes around the sync cadence.
SSO testing requires real users. SSO configuration looks fine in admin until a real user from the IdP tries to log in. Test SSO with a representative user from each user type (employee, partner, customer) before tenant-wide rollout.
Default settings cascade to new content, not retroactively. Changing the default content expiration policy applies to content created after the change. Existing content keeps its original expiration. Plan a migration if you need the new default applied universally.
API tokens and webhook secrets need rotation. Settings that hold tokens and secrets have an implicit lifecycle. Documented rotation policy or those credentials get stale, exposed, or breached.
Audit log retention is bounded. Continu retains audit logs for a configured window. If your compliance posture requires longer retention than the platform default, export to a data warehouse or SIEM as part of the settings rollout.
Multi-language settings affect everyone. Adding a language to the supported set affects every learner's language picker; the implications go beyond the cohort that needed the language.
SCIM and HRIS-driven user data is authoritative. When SCIM or HRIS owns a user attribute, you cannot manually override it in Continu — the next sync will restore the source value. Plan settings around which system owns which attribute.
Settings-related errors are often silent. A misconfigured notification setting doesn't throw an error — it just stops sending notifications. A broken integration may continue to "sync" with stale data. Active monitoring (manual or automated) catches what the system won't surface.
Tenant-wide settings have no rollback button. Some settings changes affect a lot of state. Make changes deliberately, with documentation, and ideally with a pilot first.
Where to Go Next
- Provisioning and Sync: How User Data Flows Into Continu — for the upstream integrations that feed Continu user data.
- Notifications: Designing Architecture and Strategy — for the notification settings in deeper detail.
- Smart Segmentation: Designing Populations That Maintain Themselves — for how segmentation depends on attributes set by integrations.
- Compliance Programs: The Audit-Ready Stack — for the audit settings that hold up the compliance motion.
- Reporting: Which Report Should I Use? — for the reporting infrastructure settings affect.
Design first. Click second. Treat every settings change as a program decision, because that's what it is.