Updates in Adobe Learning Manager

This document summarizes the new features, improvements, and updates in the April 2026 release of Adobe Learning Manager. Use it to plan changes for your organization and understand what’s available for learners, administrators, and authors.

For learners: The Fluidic Player now shows the next module name and a clear Exit button. Player language can be set via LTI for a consistent experience across platforms. Captivate content includes a unified table of contents, slide-level completion ticks, and reliable notes exports. Multi-language support is available for Job Aids, checklist questions, and video text tracks (VTT). The AI Assistant helps learners get answers within the learning experience.

For administrators and authors: The Zoom Connector supports multiple concurrent VILT sessions. Shared courses in peer accounts display the real author instead of “External Author.” Admins can restrict when modules can be started. Learning Object expiry dates are exposed in Learner APIs. Checklist modules support weighted scoring, multilingual question text, and optional reviewer comments. Custom certificates offer a drag-and-drop editor with dynamic fields and AI-generated backgrounds. The non-logged-in Experience Builder lets you build public learning pages without requiring login.

For instructors: Generate QR codes for instance enrollment and session attendance. Add comments or feedback during checklist evaluation.

Reporting and analytics: SCORM content can now report multiple quiz attempts in L2 reporting. Learning time spent calculation is improved in Learner Transcripts. Learning Transcript reports for Administrators are updated. Advanced search enhancements are available.

Fluidic Player navigation: show the name of the next module

Overview

This enhancement was already included in the November 2025 release of Adobe Learning Manager.

The “Next” action in the player indicates what will happen when clicked by displaying the name of the next module or course and by explicitly signaling when the learner is about to exit the player.

What’s new

“Next Module: {ModuleName}” label in the player

The Next icon in the Fluidic Player now shows the name of the next module in the course. For example, Next Module: Lesson 2- Getting started.

This applies wherever the learner is moving from one module to the next within the same course.

Clear exit action on the last module

When the learner is on the last module in a course, a new Exit action button appears, indicating that clicking it will close the player and return them to the course context.

Responsive behavior for mobile and PDF content

On smaller viewports (for example, ~320 px width), the Next label may be shortened or hidden, showing only the icon, to avoid overlapping with PDF controls.

For PDF modules, the player adjusts controls to a separate line, so navigation labels and PDF controls don’t interfere with each other.

Updated Admin > Branding > Player preview

The player preview in Admin > Branding now reflects the new label, for example, Next Module: Lesson 2. This allows administrators to see the updated navigation behavior.

Key benefits

Clearer navigation for learners

Learners no longer have to guess what will happen when they select “Next.” The label clearly specifies what comes next, whether it’s a module or a course. This reduction in ambiguity helps alleviate hesitation and confusion, particularly in large customer education audiences where many learners may not be familiar with LMS interfaces.

Higher course‑completion rates

Clearly stating the next step (Next Module: {ModuleName}) and adding a distinct Exit action for the final module reduces the likelihood of learners abandoning the course or overlooking the last completion step.

More predictable user experience across devices

The updated labels align with the Next or Previous behavior and icons across desktop, tablet, and mobile. Layout constraints are respected across devices and PDF flows so that controls remain usable and accessible.

This is particularly important for headless implementations where the Fluidic Player is embedded inside a custom learning experience.

Use cases

Customer and partner education portals (headless or AEM‑integrated)

Accounts utilizing Adobe Learning Manager in a fully headless setup, directing learners from external marketing channels. These learners:

In these environments, the Next Module: {ModuleName} label:

Compliance and certification courses with ordered modules

In regulated or compliance‑heavy scenarios:

Here, showing Next Module: {ModuleName}:

Learning Paths where courses follow each other

Where Learning Paths or equivalents chain multiple courses. This is useful when building curriculum‑style sequences for large audiences.

Mobile‑first consumption

For learners primarily using phones or tablets:

Zoom Connector - create multiple concurrent Zoom sessions

Overview

The Zoom Connector upgrade enhances how Adobe Learning Manager manages Virtual Instructor-Led Training (VILT). Before, users could only create one Zoom session at a time. With the new update, administrators and authors can schedule multiple Zoom sessions at the same time using standard integration.

What’s new

Support for multiple concurrent Zoom sessions via the connector

Meetings are created using the instructor’s Zoom identity (not the Zoom super admin)

To safely support concurrent meetings, the connector has been updated so that:

Note:

No more manual Zoom URL pasting for concurrent sessions

Previously, when a second or third Zoom session had to run at the same time:

With the updated connector:

Key benefits

Better VILT scheduling at scale

Organizations can now:

Reduced administrator and author overhead

The enhancement eliminates:

Administrators and authors can manage all Zoom sessions from Adobe Learning Manager, using familiar workflows.

Better alignment with Zoom provisioning and instructor roles

By tying meetings to individual instructor Zoom accounts:

Use cases

Multi‑track virtual events and summits

Customer education teams running large events (for example, product bootcamps, partner summits, or certification weeks) can:

Global partner and customer training

Organizations that train customers and partners across regions can:

Internal enablement

Internal enablement teams (sales, support, and so on) can:

Show original author for shared courses in peer accounts

Overview

When a course is shared through the catalog to a peer account, Adobe Learning Manager currently labels the author as “External Author” in the Learner, Administrator, and Author views of the receiving account. This can create challenges for learners and administrators, particularly in large enterprises, as it becomes difficult to identify and contact the appropriate content owner when issues or questions arise.

The enhancement ensures that author information is preserved and surfaced for shared courses in peer accounts, rather than being replaced by a generic placeholder.

What’s new

Show actual author name for shared courses in peer accounts

For courses shared via external or peer catalogs, the original author name from the source account is now displayed in the receiving account instead of “External Author”.

This applies to:

Key benefits

Direct owner visibility for shared content

Learners and administrators in peer accounts can now:

More consistent multi‑tenant and peer‑account experience

For customers running multi‑tenant or extended‑enterprise scenarios:

Use cases

Large enterprise with peer accounts

The enterprise uses ALM with:

Learners in peer accounts need to know which enterprise team authored a course to route questions or improvement suggestions correctly.

With this enhancement:

Internal multi‑BU sharing

Where one business unit curates learning for others:

Expose Learning Object expiry (auto‑retire) date in Learner APIs

Overview

This enhancement makes the auto‑retire date of a Learning Object (LO) available directly through Adobe Learning Manager’s Learner‑facing APIs. When a course, learning path, or certification is configured with an expiry or auto‑retire date, that information is now part of the LO data returned by key Learner endpoints.

What’s new

New expiry/auto‑retire field in Learner LO APIs

Availability in search‑backed learner experiences

Because the expiry date is exposed as part of the search‑backed LO representation, it is now available anywhere ALM or an external platform uses:

Scope and exclusions

The enhancement applies to Learner APIs only.

Key benefits

Expiry‑aware learner experience in custom LXPs

For large and medium enterprises, their custom LXP can now obtain LO expiry information directly from ALM, allowing them to:

This is particularly important for compliance or time‑bound product training, where learning objects are regularly refreshed, and older versions are retired.

Better guidance for learners on which trainings to take now

By exposing LO expiry, the learner experience can:

Consistency with existing completion deadline data

Previously, learner APIs already exposed instance‑level completionDeadline, but not the LO‑level auto‑retire date. With this change:

The following aspects of a training are available:

Use cases

A global enterprise with strict course lifecycle management

Enterprises that regularly retire and replace courses (for example, regulatory, product, or methodology updates) can:

Their custom portals and internal tools can now read the expiry date directly from ALM via the Learner APIs.

External customer or partner academies

For customer and partner education, marketing pages and portals often emphasize up‑to‑date training.

Having expiry dates in the LO API lets experience builders:

Multi‑language support for Job Aids

Overview

The enhancement extends Adobe Learning Manager’s localization model to Job Aids, allowing authors to attach different content files per language to a single Job Aid. Instead of creating separate Job Aids for each language, authors can now manage all localized versions as one logical Job Aid.

What’s new

Language-specific content upload for Job Aids

Authors can attach different files per supported language to a single Job Aid, like courses and other LOs.

The Job Aid creation/edit experience now supports:

Consistent language handling in the player and learner UI

The Fluidic Player has been updated so that when a learner opens a Job Aid, the content variant corresponding to the learner’s language is displayed (where available).

Administrators and authors can view Job Aids as single objects with language variants, rather than separate items per language.

Key benefits

Single Job Aid for all languages

Authors can avoid creating separate Job Aids per language.

All language variants of the same Job Aid (for example, a procedure, SOP, checklist PDF or reference guide) can be managed in one place.

Better experience for global learners

Learners automatically see the Job Aid in their preferred language, which means there is:

This is particularly useful in multilingual organizations where the same process or product documentation must be available in multiple languages.

Use cases

Global roll‑out of reference content

An enterprise needs to provide Job Aids in several languages to learners worldwide, such as:

Instead of creating separate Job Aids like “Product Quick Start – EN”, “Product Quick Start – DE”, “Product Quick Start – JP”, etc., they can create one Job Aid, attach localized files for each language, and let ALM serve the correct version to each learner based on language settings.

Customer or partner‑facing documentation for multiple markets

For customer and partner academies, Job Aids might include:

With multi‑language Job Aids:

Set restriction on module start time

Overview

The enhancement lets authors and administrators in Adobe Learning Manager define a time window during which learners are allowed to start a module. Outside the configured start/end window, the module remains visible in the course structure, but learners cannot initiate it.

This capability is critical for users who need tighter control over when certain content becomes available or should stop being initiated, for example, in timed programs, cohort‑based training, or time‑sensitive exercises.

What’s new

Authors can now configure, at the module level within a course, a start date/time and end date/time that governs when learners are allowed to launch that module. Within this window, the module behaves as usual; before the start time or after the end time, the learner sees the module in the course outline but cannot start it.

The configuration appears in the course authoring user interface as additional scheduling controls for specific module types, such as self-paced content, quizzes, or activities. Administrators can use these controls to create modules that open in phases or to prevent late starts in programs where content must be consumed within a defined timeframe.

Key benefits

The main advantage is the ability to control when modules are accessible. Training teams can synchronize module availability with real-world events, such as new product launches, regulatory deadlines, and internal programs. This ensures that learners complete prerequisite content before they can access later modules.

For instance, cohort 1 can access module 2 only in week 2, while module 3 will remain locked until week 3, eliminating the need to manually hide and unhide content or create separate course versions.

This enhances the learner experience: instead of facing modules that can technically be accessed but shouldn’t be at that time (or should already be completed), learners see a course structure where the modules they are permitted to start are clearly aligned with the intended schedule.

Use cases

Control player language via custom LTI parameter

Overview

The enhancement allows external platforms using LTI (Learning Tools Interoperability) to specify the language for Adobe Learning Manager content at the time of launch. Instead of depending on the learner to change the language within the Fluidic Player, the LTI consumer can send a language code through a custom LTI parameter. Adobe Learning Manager will then use this code to select the appropriate language variant.

What’s new

External platforms that act as LTI consumers can now pass a custom language parameter (and related player settings) when launching ALM content. ALM reads this parameter and:

This means a first‑time learner, who selects French on the external platform, will see the ALM player and module launch directly in French, without having to adjust anything inside ALM.

The enhancement also accommodates scenarios in which the external platform treats ALM as a headless content player. For example, it allows the hiding of navigation elements and the table of contents (TOC) by sending additional custom parameters to adjust certain user interface settings. These settings work in conjunction with the language parameter, enabling the external platform to provide a smooth, branded experience while still utilizing ALM for playback and tracking.

Key benefits

Use cases

Checklist question weightage for instructor evaluations

Overview

The enhancement introduces weighted checklists, allowing instructors and managers to evaluate learners using graded scales and total scores, rather than treating each checklist question as equal. The goal is to facilitate checklist creation by implementing weighted evaluations of questions, which allows the reflection of the relative importance of different actions or skills within a single checklist.

What’s new

Checklists will support the following types:

For all checklist types:

This allows analysis of overall performance and question-specific performance based on the intended weights.

Key benefits

Use cases

Multi‑language support for checklist questions

Overview

The enhancement introduces multi-language support for checklist questions, allowing reviewers to evaluate and score checklists in their preferred language. This feature is particularly useful in multilingual regions and global deployments, as it allows authors to create localized checklist questions for each supported content language while maintaining a single checklist module and a consistent evaluation process.

In Adobe Learning Manager today:

What’s new

Authoring

Review experience

Reporting

The Checklist report will display question text in the user’s content language:

Key benefits

Use cases

Checklist with commenting capability for reviewer

Overview

The enhancement introduces a commenting feature for checklist evaluations, allowing reviewers, such as instructors and managers, to provide qualitative feedback alongside the numeric scores. This feedback can be made visible to learners when necessary.

The goal is to support checklist-based evaluations where mentor feedback is as crucial as the numeric result. This includes highlighting specific strengths, areas for improvement, or providing context for the given score.

Today, reviewers can:

In real-world scenarios, such as aviation, field trainers assess shop-floor agents and airport staff. Similarly, instructors and mentors in small and medium-sized enterprises (SMEs) often use checklists to evaluate job performance. However, these checklists typically do not include a structured section for capturing narrative feedback related to the evaluation.

What’s new

Authoring options

Authors can configure each checklist to:

This allows organizations to tailor comment visibility to their culture and privacy requirements.

Reviewer experience

When commenting is enabled:

If they re‑evaluate a learner, they can update or change comments to reflect the latest assessment.

Reporting and notifications

This ensures feedback is not only stored but actively surfaced to learners.

Key benefits

Use cases

Content‑level multiple attempts and quiz reporting

Overview

Presently, ALM supports multiple attempts at the LMS level via the Multiple Quiz Attempt (MQA) feature:

However, if the content file itself (for example, an Articulate SCORM quiz) implements its own multiple‑attempt logic, ALM’s L2 quiz report does not currently distinguish or track those internal attempts correctly.

This enhancement introduces content-level multiple attempt tracking for quizzes, allowing Adobe Learning Manager to accurately capture each attempt within the content itself in the L2 quiz report. It’s designed for situations where the content authoring tool (such as Articulate SCORM) manages quiz attempts independently. With this feature, attempts are correctly reflected in ALM reporting without depending on LMS-level Multiple Quiz Attempt (MQA) settings.

What’s new

Author flag for content‑level attempts

Course/module behavior

When such content is used in a course:

Reporting

The L2 quiz report treats each content‑level attempt as a separate attempt row:

Key benefits

Use cases

Instructor QR codes for instance enrollment and session attendance

Overview

This enhancement adds the ability for instructors to generate QR codes themselves for:

at the session level. It’s designed for situations where learners enter a physical or hybrid classroom and require a quick, self-service option to enroll and record their attendance using a QR code.

What’s new

Instructor‑generated QR codes

QR code packaging

The exported QR code PDF includes:

These make it easy for instructors and coordinators to identify and print the correct QR code for each session.

Key benefits

Use cases

Captivate and ALM player improvements

Overview

This enhancement improves the experience of playing Adobe Captivate content within the Adobe Learning Manager (ALM) player, particularly following the recent changes to Captivate’s architecture. The aim is to allow learners to engage with Captivate modules natively in ALM while ensuring that navigation, completion tracking, and note-taking are clear, consistent, and reliable.

What’s new

Unified TOC experience

Visual completion feedback

Contextual progress controls

Streamlined navigation

Reliable notes linking

Key benefits

Use cases

Improved learning time spent calculation in Learner Transcripts

Overview

Adobe Learning Manager has revised how it calculates learning time in Learner Transcripts with its April 2026 release. Previously, the reporting logic could lead to inaccurate times if learners left the player open without engaging with the content, causing discrepancies. The new method now tracks active time based on user engagement, specifically when the tab is in focus and when there is user activity. This change results in more accurate data.

This update improves reports and dashboards, helping administrators better ensure compliance and track learner progress. After the release, review your Learner Transcripts to see these enhancements.

The updated calculation method focuses on actual engagement, such as active tab focus and recent user interactions, thereby improving the accuracy of time reporting across the following areas:

What’s changed

The Learning Time Spent column in Learner Transcripts now uses improved logic to calculate time more accurately. Instead of simply tracking player open/close times, the system now distinguishes between active and idle periods based on user engagement.

This applies to most module types, with exceptions for SCORM, Captivate, and XAPI modules, which retain the original logic.

How it works

The new calculation varies by module type:

Idle time is subtracted, ensuring only true engagement time is reported.

Summary table

Note:

Benefits of the new calculation

Reporting and analytics impact

API and connectors

Backward compatibility and data migration

Known limitations

Frequently asked questions

Does this update change historical records?

No. The change applies only to sessions after the feature launch.

How do I verify the changes?

Check Learner Transcripts for recent modules; compare times to expected durations.

Does this affect all accounts?

Yes, it’s a global update for all Adobe Learning Manager accounts.

Do learners need to take action?

No. The change is automatic and transparent to learners.

What if learners leave content open?

Idle time is now excluded, preventing over-reporting.

Are video/audio sessions auto‑paused when the tab is inactive?

No. Playback behavior is unchanged. Time is excluded when paused >10 minutes or when not actively playing.

Will offline mobile activity be reflected?

Yes. Offline usage is included when the device syncs.

What should I do if my dashboards now show lower averages?

This is expected where idle time had previously inflated results. Annotate dashboards and adjust targets as needed.

Are there any prerequisites?

None; the change is automatic.

Update to Learning Transcript reports for Administrators

We are updating the Learning Transcript (LT) reports for Admins to better support checklist-based evaluations and reviewer feedback.

What is changing?

1. Column Rename in Admin Learning Transcript

The existing Submission comment column in the Admin Learning
Transcript is:

Data shown in this column:

This change applies to all Admin LT sources:

After this change, the same column carries: - Submission comments for submission modules

Under the new header name Reviewer’s remarks.

2. New Column in Connector-Based Learning Transcript Exports

For connector-exported Learning Transcripts:

Impact on existing integrations and automations

If you are using Learning Transcript reports in custom integrations, automations, or external reporting tools, please review the following scenarios:

What you should do

If your current implementation relies purely on column positions in Admin LT and does not validate or depend on the column header text, no change is required for the Admin LT itself. Only connector exports need attention when you depend on a fixed layout.

Non-logged-in experience in Experience Builder

The non-logged-in experience in Experience Builder allows organizations to display their learning content and portal pages to all visitors, including those who have not signed in. This feature is designed to attract, inform, and engage prospective learners by offering a smooth and branded preview of your training offerings before requiring them to log in or enroll.

This feature lets you create and customize public-facing pages using the same user-friendly drag-and-drop interface found in the standard Experience Builder. You can showcase course catalogs, categories, paths, and rich static content, including images, text, HTML, and embedded iframes, for anyone visiting your portal. This makes it simple to highlight your learning programs, promote new courses, and provide essential information to a broader audience.

Visitors can browse the catalog, view details about courses and instances, and utilize the global search to explore available training opportunities. However, actions that require a user’s identity, such as enrolling in a course, accessing personalized features (like, Calendar, Compliance, Leaderboard, or Social Learning), or consuming training, will prompt the visitor to log in. This approach ensures that sensitive and personalized information remains secure while still allowing for a comprehensive preview experience.

Administrators have the ability to configure which pages and widgets are visible to users who are not logged in, ensuring that only suitable content is displayed. Pages can be set to be accessible to both logged-in and non-logged-in users, or exclusively for one of these groups. The Experience Builder offers a preview mode, allowing you to see exactly how your pages will appear to visitors before they are published.

To enable this feature, your ALM integration administrator must activate the Training Data Access Connector. This connector ensures that course metadata is publicly accessible.

Branding and localization are fully supported, enabling you to customize page titles, favicons, and language settings to align with your organization’s identity and meet your audience’s needs. As part of the transition to this enhanced experience, the legacy homepage feature for non-logged-in users will be deprecated. Therefore, all new public content should be created using Experience Builder.

Purpose of the feature

The non-logged-in experience in Experience Builder allows organizations to publicly showcase their learning content and portal pages to anyone, without requiring users to log in. This helps attract, inform, and engage potential learners by providing a preview of available training and resources before enrollment or authentication is needed.

Real-world use cases on non-logged-in experience

Key concepts of non-logged in experience

Experience Builder’s non-logged-in experience lets you publicly showcase learning content and portal pages, allowing visitors to browse without logging in.

Prerequisites for non-logged in experience

Training Data Access connector initialization

The Training Data Access (TDA) connector is a critical prerequisite for enabling the new non-logged-in experience builder feature in ALM. This connector facilitates the export of training metadata, allowing your portal to display course information to users who are not logged in.

What visitors can do without logging in

On a non-logged-in Experience Builder site, visitors can browse the training catalog by opening the catalog page for public catalogs. They can use filters such as catalog, product, role, type, skills, and tags, depending on how you have configured the site. Visitors can also search for trainings using the global search bar in the header (if enabled), and view search results directly on the catalog page.

Visitors can view training details by opening overview pages for courses, learning paths, and certifications. These pages display key metadata, including the title, description, author, duration, format, tags, and skills.

In addition, visitors can explore static and promotional content. They can read text and rich content blocks, view banners and image tiles, and interact with embedded iframes such as external microsites, videos, or tools.

If a visitor clicks enroll or tries to start training, the system prompts them to log in or sign up. After successful login, the visitor is redirected to the appropriate page, whether it is the home page, a custom page, or the specific training they selected.

What’s not available without logging in

On a non-logged-in Experience Builder site, visitors cannot access features or content that require user authentication. They are unable to enroll in trainings, start or consume courses, or access personalized widgets such as My Learning, Calendar, Compliance, Leaderboard, or Social Learning. These widgets depend on user-specific data and are only available after logging in.

Visitors also cannot perform actions like enrolling in a course or accessing any content that requires tracking progress or user context. Attempting to enroll or start a training prompts the visitor to log in or sign up before proceeding.

Supported widgets in non-logged-in mode

In non-logged-in mode, only widgets that do not require user-specific data are supported. These include:

Pages and menus in non-logged-in experience

Search and catalog behavior

In non-logged-in mode, users can access the catalog page and use search to browse available courses and learning paths. The catalog page displays all public courses, along with filters and search functionality, following the same account settings as in logged-in mode. When a user searches, the results appear on the catalog page, and users can view course and instance overview pages without logging in. However, actions like enrollment require login.

If a user attempts to enroll, the system requires them to log in first. The search for non-logged-in users is simpler than that for logged-in users and does not include advanced features like AI Assistant integration.

Technical implementation

Training data access connector setup

You must enable the training data access connector in the integration admin panel before you can use the non-logged-in experience builder feature. This connector exports training metadata from ALM to a public repository, making it accessible via APIs for your non-logged-in pages. The connector setup is a prerequisite for activating the feature and ensures your portal displays up-to-date training information.

Metadata export and synchronization

The connector exports key metadata fields such as course name, overview, description, rating, duration, and skills. You can schedule exports (for example, daily) to keep your portal synchronized with ALM. Not all metadata fields may be included; consult engineering for a complete list. Exported data is used to populate non-logged-in pages, and changes in ALM will appear after the next export cycle.

Caching and export frequency

The system uses backend export frequency and frontend caching to manage data updates. Changes made in ALM are reflected on your portal after the scheduled export and cache refresh. Some updates may not appear immediately due to these mechanisms. If you need faster updates, adjust the export schedule or clear the cache as needed.

CSS/JS customization support

You can apply custom CSS and JavaScript to both logged-in and non-logged-in pages using the customization tab. This allows you to maintain consistent branding, add custom UI elements, and enhance user experience across your portal. All customizations are applied globally, ensuring a unified look and feel.

URL differences and branding (favicon, page title)

Non-logged-in and logged-in pages may have different URLs to distinguish user states. You can customize the favicon and page title for your portal, helping reinforce your brand identity. These features are available in the experience builder; check with engineering for the latest status on non-logged-in support.

Performance and scalability

Shared stack vs premium stack

The shared stack allows multiple customers to use the non-logged-in experience builder on common infrastructure, supporting standard traffic levels. The premium stack is a paid option that provides dedicated resources, real-time features, and higher seat limits for customers with advanced needs. Select the stack based on your expected traffic and business requirements.

Traffic limits and rate limiting

The shared stack enforces traffic limits to ensure fair usage among customers. Engineering will implement rate limiting to prevent any single customer from consuming all resources. If you plan marketing campaigns or expect high traffic, coordinate with engineering to understand your limits and avoid service disruptions. Rate limiting helps maintain system stability and performance for all users.

Multi-tenancy and SEO considerations

The platform supports multi-tenancy, allowing multiple customers to host their portals on shared infrastructure. Non-logged-in pages are SEO-friendly, along with sitemap.xml and robots.txt to optimize search engine visibility. This ensures your portal is discoverable and indexed appropriately by search engines.

Migration and deprecation

Transition from existing non-logged-in homepage

You should recreate your homepage using the new experience builder for enhanced flexibility, widget support, and improved user experience. The transition plan ensures minimal disruption and continued support.

Communication plan

Customers using the legacy homepage will receive clear communication about the deprecation timeline and migration steps. Support will be provided to help you move your homepage to the new experience builder platform, ensuring you benefit from new features and ongoing updates.

Localization and login support

Locale fallback logic

The system displays pages in the locale they were created. If a user’s locale is unavailable, the system uses a fallback logic to select the next best available locale. This ensures users always see content in a supported language, improving accessibility and user satisfaction.

Supported login types

The non-logged-in experience supports all login types available in ALM, including SSO and standard login. Users can browse content without logging in and will be prompted to log in when required, such as enrolling in a course or accessing personalized features. This provides a smooth transition from browsing to engagement.

Non-logged in APIs

Admin Learning Object API

Non-logged-in Experience Builder pages and headless portals often organize or filter courses based on product and role. The Admin LO API has been enhanced to ensure that these associations are consistently accessible for back-end and headless integrations, as well as for the TDA connector.

Endpoint and behavior

You continue to use the existing Admin LO endpoint:

GET /primeapi/v2/learningObjects/{loId}?enforcedFields[learningObject]=products,roles

Where:

This is fulfilled by ensuring that the LO’s product and role associations are present in the response when requested through enforcedFields. The response then contains, in attributes, the product and role metadata needed to compute or expose the recommended products (rec_products) and roles (rec_roles) for Experience Builder and other consumers.

A typical call from an admin or integration looks like:

url -X GET \
 "https://{your-domain}/primeapi/v2/learningObjects/course:12345?enforcedFields[learningObject]=products,roles" \
 -H "Authorization: Bearer {admin\_token}" \
 -H "Accept: application/vnd.api+json

The returned LO JSON is the same basic structure as before, but now you can rely on product/role fields being present when you request them with enforcedFields. Integrations that do not use enforcedFields continue to behave as before.

Learning Objects Listing – JobAid Support in effectiveModifiedDate Filter

Purpose

The Training Data Access (TDA) connector and headless implementations often need to perform incremental synchronization, based on the effective modification date of learning objects. Until this release, JobAids (LO type jobAid) were not correctly handled when combined with the effectiveModifiedDate filters. This release fixes this so JobAids can be synced incrementally like courses and learning paths.

Endpoint and behavior

You use the existing LO listing endpoint with date filters and LO type:

GET /primeapi/v2/learningObjects
 ?filter.effectiveModifiedDate.fromDate=2025-03-15T13:14:56.000Z
 &filter.effectiveModifiedDate.toDate=2025-03-20T13:14:56.000Z
 &filter.loTypes=jobAid

Previously, when filter.loTypes=jobAid was combined with an effectiveModifiedDate range, the filter effectively excluded JobAids, and the call behaved as though JobAids were not supported.

From this update onwards, the call returns only JobAid learning objects whose effectiveModifiedDate falls inside the specified window.

{
 "links": {
 "self": "https://acapapiserver/primeapi/v2/learningObjects?page[limit]=10&filter.effectiveModifiedDate.fromDate=2026-01-19T13:14:56.000Z&filter.effectiveModifiedDate.toDate=2026-01-21T13:14:56.000Z&filter.loTypes=jobAid"
 },
 "data": [
 {
 "id": "jobAid:144968",
 "type": "learningObject",
 "attributes": {
 "authorNames": ["Author"],
 "dateCreated": "2026-01-20T08:48:55.000Z",
 "datePublished": "2026-01-20T08:48:55.000Z",
 "dateUpdated": "2026-01-20T08:48:55.000Z",
 "effectiveModifiedDate": "2026-01-05T07:31:18.000Z",
 "loType": "jobAid",
 "loFormat": "Content",
 "loResourceType": "Content",
 "localizedMetadata": [
 {
 "description": "Link jobAid new",
 "locale": "en-US",
 "name": "Link jobAid new"
 },
 {
 "description": "Link jobAid new fre",
 "locale": "fr-FR",
 "name": "Link jobAid new fre"
 }
 ],
 "relationships": {
 "authors": {
 "data": [
 { "id": "13385176", "type": "user" }
 ]
 },
 "instances": {
 "data": [
 { "id": "jobAid:144891\_-1", "type": "learningObjectInstance" }
 ]
 }
 }
 }
 }
 ]
}

This means you can now safely implement incremental JobAid syncs based on effectiveModifiedDate, in the same way you already do for other types.

If you omit filter.loTypes=jobAid, the behavior for other LO types is unchanged; the change only affects the combination of JobAid with that filter.

Menu API: Non-logged-in menu filter

Purpose

Experience Builder and headless frontends need a straightforward way to retrieve the non-logged-in menu , the one that defines navigation for public visitors. Before this release, you had to fetch all menus and then apply custom logic to identify which one represented the non-logged-in navigation. This release adds a simple server-side filter.

Endpoint and behavior

You use the existing Menu listing endpoint with a new query parameter:

GET /primeapi/v2/templates/menus?include=pages,subMenus.pages&isNonLoggedIn=true

The key points:

Without the isNonLoggedIn parameter, the endpoint behaves exactly as before and returns menus according to the existing default behavior. With isNonLoggedIn=true, it typically returns the single menu used by the non-logged-in experience for your account (since there is normally one non-logged-in menu per account).

In practice, a client can now issue:

curl -X GET \
 "https://{your-domain}/primeapi/v2/templates/menus?include=pages,subMenus.pages&isNonLoggedIn=true" \
 -H "Authorization: Bearer {admin\_token}" \
 -H "Accept: application/vnd.api+json"

and get back the non-logged-in navigation structure in one call, with all the pages that should be visible to anonymous visitors.

This is particularly useful when you are building a headless non-logged-in site and want to mirror the same navigation that Experience Builder uses, or when you are debugging whether the non-logged-in menu has been configured correctly.

Allow listing of custom domains

The non-logged-in stack consists of:

When you introduce a custom domain, it works seamlessly without any additional effort following the existing process for adding a custom domain.

Prerequisites

Before whitelisting a custom domain for non-logged-in:

These steps ensure that:

How allow-listing works

The allow-list is stored in the configuration that TDA exports and the non-logged-in stack reads. That configuration includes:

For non-logged-in Experience Builder to work on a custom domain:

This release adds a new non-logged-in CDN domain, cpcontents.adobe.com, and specifies that it must be placed into the allow-listed domains in the TDA connector. For existing non-logged-in native users, this requires an update.

Allow-list a custom domain

Configure the custom domain in ALM

Work with Adobe to register your domain, for example, academy.yourcompany.com, as the custom domain for your ALM account. You update DNS to point to Adobe Akamai as instructed and wait for SSL and routing to complete.

At this point, both logged-in and non-logged-in traffic can reach ALM through that domain, but non-logged-in search and catalog calls may still be blocked if the domain is not allow-listed.

Enable TDA and non-logged-in Experience Builder

Ensure that:

Enabling TDA creates or updates the non-logged-in account JSON. For new accounts, the process also allow-lists the new non-logged-in CDN domain (cpcontent.adobe.com) by default, so the public ES endpoint expects calls from that domain.

For accounts that were already using the older non-logged-in stack, existing connectors must be deleted and recreated to pick up the new domain.

Add the custom domain to the allow-list

The critical part is telling the non-logged-in ES stack that academy.yourcompany.com is an approved origin. There are two common paths.

Existing native non-logged-in users will need to delete and re-enable the TDA connection so the new domain is automatically allow-listed. Doing this achieves two things:

This is recommended when you have a small number of accounts and can tolerate temporarily disabling and re-enabling the connector.

After allow-listing, open your non-logged-in site on the custom domain and inspect the browser network calls.

You want to see:

If these calls return 4xx or explicit errors suggesting “untrusted domain” or “origin not allowed,” the allow-list is incomplete or misconfigured and Support needs to adjust it.

The non-logged-in LLD also notes that the account config can hold an expected domain value. At runtime, the site checks that the domain in the URL matches what is set in the config; if it does not, the user can be redirected to an error page. This protects against one customer’s configuration being accessed via another customer’s domain.

Using recommendations in the non-logged-in Experience Builder

The non-logged-in Experience Builder lets you build public learning pages where visitors can browse your catalog and see highlighted content before they sign in. Even though these visitors are anonymous, you can still present recommended trainings by using metadata and widgets.

In the logged-in learner app, recommendations can be personalized: they can depend on the learner’s profile, history, skills, and progress. In the non-logged-in experience, there is no learner identity yet, so the platform cannot personalize per user.

Recommendations in non-logged-in mode are therefore:

Metadata and APIs that support recommendations

Behind the scenes, non-logged-in pages use:

In this release, the Admin LO API was extended so that product and role associations are reliably available:

GET /primeapi/v2/learningObjects/{loId}?enforcedFields[learningObject]=products,roles

This allows widgets and headless integrations to build rule-based recommendations using products, roles, catalog labels, tags and other fields consistently.

Designing recommendation sections with Experience Builder widgets

You create recommendation sections on non-logged-in pages by combining Experience Builder widgets with metadata filters.

Courses and Paths widget

Use the Courses and Paths widget when you want to show a row or grid of recommended items. In its configuration you can choose:

For example, you can create:

The widget is not learning from behavior; it is showing whatever matches the metadata rules you define. From a visitor’s point of view, however, it looks like a recommendation strip.

Categories widget

Use the Categories widget to help visitors navigate into “recommended” sets of content, even if they do not know your product names.

You can configure tiles that each represent a segment such as:

Each tile can link either to:

This gives you a “recommended paths by segment” experience without personalization.

Building segment-based recommendations

Because non-logged-in visitors have no ALM profile yet, it is useful to design recommendations by segment and let visitors self-select.

Visitors perceive that they are seeing recommendations tailored to their situation, even though the logic is defined at design time via metadata.

Transitioning from non-logged-in to personalized recommendations

Non-logged-in recommendations are mainly about discoverability and conversion. Once visitors decide to enroll or start training, they will log in and become full learners with a profile and history.

The usual flow is:

In other words, the logged-in recommendations help them decide what to do next and keep going.

How job aids can be used in the new non-logged-in Experience Builder

On the User Interface, job aids participate in non-logged-in experiences mainly through the widgets that can show learning objects:

For example, on a public landing page you might configure one strip titled “Helpful resources” that shows job aids only, and another strip titled “Recommended courses” that shows courses and paths.

How job aids are exposed through non-logged-in APIs

On the API side, job aids are supported by:

GET /primeapi/v2/learningObjects
 ?filter.effectiveModifiedDate.fromDate=2026-01-19T13:14:56.000Z
 &filter.effectiveModifiedDate.toDate=2026-01-21T13:14:56.000Z
 &filter.loTypes=jobAid

Before this change, combining effectiveModifiedDate with loTypes=jobAid did not reliably return job aids. That means:

Note:

In the non-logged-in state:

Changes in brief description in LO search (non-logged-in)

In the non-logged-in stack, search and listing of learning objects (LOs) are powered by the Training Data Access (TDA) connector and a public Elasticsearch index. Historically, this stack used a single overview/description field for each LO. Customers building headless non-logged-in portals wanted to show the same short description on LO tiles that the logged-in learner UI shows, rather than only the long overview.

The change introduces support for the LO brief description in non-logged-in search and listing APIs:

Other changes

Restriction that no two accounts can share the same custom domain

In the non-logged-in and logged-in architectures of Adobe Learning Manager, a custom domain (for example, academy.example.com) is treated as a globally unique key that must map to exactly one ALM account, so the platform enforces a hard restriction that no two accounts can share the same custom domain. This is required for security, routing, and SEO: the routing layer and non-logged-in stack use the domain to look up the correct account configuration (including its non-logged-in account JSON, Experience Builder menus, branding, and TDA/search endpoints),

Allowing the same custom domain on two accounts would make it impossible to guarantee which account’s data is returned, could cause cross-tenant leakage, and would also corrupt generated artifacts such as sitemap.xml and robots.txt that are produced per account but discovered by search engines per host. Operationally, this means that when you assign or move a custom domain you must first ensure it is not attached to any other account (or de-register it there), and Adobe’s internal tooling will reject attempts to bind the same domain to multiple accounts.

Browser caching of resources in the non-logged-in experience

In the non-logged-in experience of Adobe Learning Manager, browser caching of resources is a core part of the performance and scale strategy, because public pages must handle large, sometimes spiky marketing traffic with low latency and minimal origin load. Static and semi-static assets such as the non-logged-in HTML shell (for example, index.html/guest.html), account-level configuration JSON (account.json or config.json), Experience Builder page layout JSON (menus, widget layouts, card settings), CSS, JS, images, and favicons are served from an Akamai CDN (cpcontents.adobe.com / cpcontent.adobe.com) with cache headers that encourage both CDN-side and browser-side reuse, so that after the first page load the browser can render subsequent non-logged-in pages largely from its cache, revalidating only when needed via ETag or Last-Modified.

Multi-lingual Job Aids

Introduction

Multilingual Job Aids in Adobe Learning Manager (ALM) let authors and administrators provide supporting documents, guides, or resources in multiple languages within a single job aid entry. Learners across different regions can access relevant materials in their preferred language, which improves comprehension, compliance, and user experience.

Previous behavior

Previously, job aids in ALM supported only a single content file per job aid, even when the name and description could be localized. To provide the same resource in multiple languages, authors had to create separate job aids for each language. This led to duplication, confusion, and increased administrative overhead. There was no unified way to manage multilingual resources, which made it difficult to ensure consistency and track usage.

Use cases

Key features

Create a multilingual job aid

Add additional languages

Edit and manage languages

Publish and learner experience

Reporting

Best practices

Troubleshooting

Multilingual Job Aids let you deliver supporting resources to a global audience in a single entry, reduce duplication, and ensure every learner receives the right information in their preferred language. This feature improves accessibility, compliance, and administrative efficiency in Adobe Learning Manager.

Get answers with AI Assistant for learners

AI Assistant for learners is a conversational, AI-driven assistant within Adobe Learning Manager designed to guide you to the information you need faster. By asking questions in natural language, you can get contextual explanations, surface relevant courses, and retrieve insights from learning content — without manually browsing through catalogs.

Capabilities

Benefits

Learn more about AI Assistant for learners.

Multi-lingual Video Text Tracks (VTT) support

Multi-lingual Video Text Tracks (VTT) support in Adobe Learning Manager enables authors to provide subtitles and captions for video and audio content in multiple languages. This feature streamlines localization, making training accessible to a global audience and ensuring compliance with accessibility standards. Authors can auto-generate, translate, review, and edit VTT files directly within the platform.

Use Cases

Key features

Upload content and generate VTT

Monitor progress

Review and edit VTT files

Publish captions

Additional Information

Best Practices

Troubleshooting

Multi-lingual VTT support enables you to deliver accessible, localized video learning experiences efficiently. By using auto-generation, translation, and in-app editing, you can ensure your content reaches and supports all learners, regardless of language.

Design custom certificates

Custom Certificates in Adobe Learning Manager (ALM) let administrators and authors design, manage, and issue personalized certificates for learners. The feature includes a drag-and-drop editor, dynamic fields, multilingual support, and AI-generated backgrounds so organizations can create branded certificates without technical expertise.

Previous behavior

Previously, certificate creation in ALM was limited by template rigidity, lack of customization, and technical barriers (such as HTML editing). Customers requested simpler ways to design certificates, add dynamic fields (such as learner name or instructor), and support multiple languages, all while maintaining brand consistency and visual appeal.

Use cases

Access custom certificates

Create a certificate

Add dynamic fields

Dynamic fields in Adobe Learning Manager custom certificates are placeholders that automatically populate with relevant information, such as learner name, instructor name, or other account-specific data—when the certificate is generated, allowing for personalized and context-aware certificates without manual editing.

Multilingual support

Preview and publish

Apply certificates

Manage certificates

Custom Certificates in ALM provide a flexible way to design and issue personalized, branded, and multilingual certificates. The feature simplifies certificate management, improves learner recognition, and supports global compliance and branding needs.

Multi-lingual Job Aids

Multilingual Job Aids in Adobe Learning Manager (ALM) let authors and administrators provide supporting documents, guides, or resources in multiple languages within a single job aid entry. Learners across different regions can access relevant materials in their preferred language, which improves accessibility, compliance, and user experience.

Previous behavior

Previously, ALM allowed only one content file per job aid, even though the name and description could be localized. To provide the same resource in multiple languages, authors had to create separate job aids for each language. This led to duplication, confusion, and increased administrative effort. There was no unified way to manage multilingual resources, which made it difficult to ensure consistency and track usage.

Use cases

Create a multilingual Job Aid

Add additional languages

Edit and manage languages

Publish and learner experience

Reporting

Multilingual Job Aids in ALM let you deliver supporting resources to a global audience in a single entry, reduce duplication, and ensure every learner receives the right information in their preferred language. This feature improves accessibility, compliance, and administrative efficiency in Adobe Learning Manager.

Playback improvements for Captivate generated courses

The update significantly improves the playback experience for Adobe Captivate content within ALM by introducing a unified and streamlined interface.

The ALM player now displays a single, consolidated TOC, hiding the Captivate TOC, and provides clear slide-level completion indicators, including green tick marks for visual progress tracking.

The system simplifies navigation by merging module and course controls into one intuitive bar, reducing learner confusion.

Context-aware progress controls enhance usability by displaying video progress bars only on video slides and slide navigation controls only on non-video slides.

Additionally, the system now links notes to slide numbers instead of timestamps, ensuring reliable PDF exports and resolving prior format inconsistencies.

Checklist enhancements

Multi-language support for checklist

This feature lets you create and manage checklist modules in multiple languages. Each checklist question, instruction, and evaluation criterion can be translated so reviewers and learners interact with the checklist in their preferred language. The system displays the checklist in the user’s selected content language, which improves accessibility and compliance for global teams.

Checklist question weightage for instructor evaluations

This feature lets you assign different maximum scores (weightage) to each checklist question. You can reflect the varying importance or difficulty of each question, which supports more accurate and meaningful evaluations. The system calculates the total score based on your input and determines if the learner passes or fails according to the criteria you set.

Checklist with commenting capability for reviewer

This feature lets reviewers add comments or feedback during checklist evaluation. You can provide personalized, actionable feedback for each learner. You can also choose to display your name with your comments for transparency. All remarks are saved in the learner’s transcript and included in checklist reports.

Advanced search enhancements

This release includes improvement in in-content search by showing the courses with content match with query higher in rank. Also, Job Aids are now included in advanced search ranking.

Equivalents and alternates

Overview

In many organizations, learners encounter training situations where different courses can legitimately satisfy the same requirement?for example, when a new course replaces an older one, when a more comprehensive course can stand in for a shorter one, or when a special substitute course needs to be offered.

The Alternate Courses or Learning Path feature gives ALM a formal way to say:

“If the learner completed this training, treat them as having satisfied that related training requirement.”

The feature works across courses and Learning Paths, ensures downstream requirements such as prerequisites and compliance rules are honored, and does this without forcing learners to sit through redundant content. It also keeps reporting accurate by recording what was completed directly versus what was satisfied via an alternate.

At the core, the feature introduces the concept of an alternate completion: a special completion state created automatically when a learner finishes a configured source training that counts towards another target training.

Equivalence vs. alternates

Some training relationships are bidirectional, meaning each course can satisfy the other’s requirement. This is effectively a scenario where two trainings are treated as mutually substitutable. In contrast, unidirectional relationships allow one training to satisfy the requirement for another, but not vice versa. ALM models both scenarios using the same underlying alternate*completion mechanism.

Alternates are most often used in unidirectional scenarios?for example, when a more comprehensive superset course covers everything in a simpler subset course. Completing the superset should satisfy the requirement for the subset, but not necessarily the other way around.

In Alternates, the relationship is normally one*way. If Course A is an alternate for Course B, completing A can satisfy B’s requirement, but completing B does not necessarily satisfy A.

Both equivalence and alternate share the same underlying mechanism in ALM: when a configured source training is completed, ALM automatically produces an alternate completion for one or more target trainings.

What problems does this solve?

Without Alternates and Equivalence, administrators and learners face several recurring issues:

The Alternates and Equivalence feature addresses these issues by:

How the feature works conceptually

The feature is built on three main ideas: relationships, alternate completion, and downstream behavior.

Relationships between trainings

Administrators define relationships between courses and Learning Paths. For each relationship, they choose a source and one or more targets. A single course might have up to 30 targets depending on how many earlier or related trainings it should satisfy.

For Equivalence, admins can make the relationship bidirectional if they want both trainings to satisfy each other. For Alternates, admins normally keep the direction one*way to reflect that only some substitutions are allowed.

These relationships are stored at the training level, not at the learner level. Once configured and enabled, they apply to all current and future completions of the source training, subject to account*level settings such as whether retroactive completion is enabled.

Alternate completion

When a learner completes a source training, ALM examines all configured alternate or equivalent relationships and, for each relevant target training, creates an alternate completion record. This record is distinct from a normal completion:

Learners will see alternate completion even if they’re not enrolled. The Learner Transcript (LT) report includes only records of trainings that the learner has enrolled in.

Learner app experience for alternate and equivalent completions

Alternate and equivalent completions are surfaced distinctly in the learner app so learners can clearly understand how a training requirement was satisfied, while maintaining consistency with transcripts and reports.

LO card behavior

Alternate completion status

When a learner completes a training via an alternate or equivalent relationship, the Learning Object (LO) card displays a distinct status such as Completed via Alternate.
This visual distinction helps learners differentiate between direct completions and completions granted through configured relationships.

Completion method indicator

The LO card includes a completion method indicator (for example, a label or icon) to show that the completion was achieved through an Alternate.
If an alternate completion is later revoked due to changes such as retroactive incompletion or deletion of the source training, the LO card updates to reflect Alternate (Revoked).

Transparency and audit details

Learners can open the LO card to view additional details, including:

This ensures transparency and supports audit and compliance reviews.

Filtering and views

Completion method filter

The learner app provides a filter that allows learners to distinguish between:

This enables learners to quickly understand how their learning requirements were fulfilled.

Transcript and progress views

The completion method filter is available in learner*facing views such as:

These views clearly indicate which trainings were completed directly and which were satisfied through alternates or equivalence.

Reporting alignment

The filtering logic in the learner app aligns with the Completion Method column used in reports.
This ensures consistency between what learners see in the UI and what administrators see in exports and compliance reports.

End to end flow

For learners

For administrators and authors

Retroactive completion and incompletion behavior

ALM supports retroactive completion and retroactive incompletion to ensure that alternate and equivalent relationships remain accurate over time, even when relationships are created, modified, or removed after learners have already completed training.

Retroactive completion

Definition

When retroactive completion is enabled, learners who completed a source course in the past automatically receive an alternate completion for the target course if an equivalent or alternate relationship is created later.
This ensures that historical learning is honored without requiring learners to retake training.

How it works

Retroactive incompletion

Definition

When retroactive incompletion is enabled, alternate completions are revoked if the underlying equivalent or alternate relationship is removed or if the source training is deleted.
This ensures the system reflects the current and valid training relationships.

How it works

Impact on prerequisites

Alternate completions—including those granted retroactively—are treated as valid completions when evaluating prerequisites.
If a learner has Completed via Alternate, they are allowed to proceed with courses that require the target training.

If an alternate completion is later revoked through retroactive incompletion, the learner may lose eligibility for courses that depended on that prerequisite.

Impact on learning paths and certifications

Alternate completions contribute toward progress and completion of learning paths and certifications.
Learners can advance or complete these programs when required trainings are satisfied via alternate or equivalent relationships.

If an alternate completion is revoked, affected learning paths or certifications may lose progress or completion status until the requirement is met through a valid completion.

End to end workflow

Enabling retroactive completion or incompletion

System actions

Learner experience

Learners see updated completion statuses on LO cards and in transcripts, such as:

Prerequisite checks, learning path progress, and certification status update dynamically based on the current completion state.

Reporting and audit

All retroactive changes are reflected in the Learning Transcript (LT) report.
Reports clearly distinguish between direct completions, alternate completions, and revoked alternate completions to support compliance, support investigations, and audits.

Retroactive completion and incompletion behavior

ALM supports retroactive completion and retroactive incompletion to ensure that alternate and equivalent relationships remain accurate over time, even when relationships are created, modified, or removed after learners have already completed training.

Retroactive completion

Definition

When retroactive completion is enabled, learners who completed a source course in the past automatically receive an alternate completion for the target course if an equivalent or alternate relationship is created later.
This ensures that historical learning is honored without requiring learners to retake training.

How it works

Retroactive incompletion

Definition

When retroactive incompletion is enabled, alternate completions are revoked if the underlying equivalent or alternate relationship is removed or if the source training is deleted.
This ensures the system reflects the current and valid training relationships.

How it works

Impact on prerequisites

Alternate completions—including those granted retroactively—are treated as valid completions when evaluating prerequisites.
If a learner has Completed via Alternate, they are allowed to proceed with courses that require the target training.

If an alternate completion is later revoked through retroactive incompletion, the learner may lose eligibility for courses that depended on that prerequisite.

Impact on learning paths and certifications

Alternate completions contribute toward progress and completion of learning paths and certifications.
Learners can advance or complete these programs when required trainings are satisfied via alternate or equivalent relationships.

If an alternate completion is revoked, affected learning paths or certifications may lose progress or completion status until the requirement is met through a valid completion.

End to end workflow

Enabling retroactive completion or incompletion

System actions

Learner experience

Learners see updated completion statuses on LO cards and in transcripts, such as:

Prerequisite checks, learning path progress, and certification status update dynamically based on the current completion state.

Reporting and audit

All retroactive changes are reflected in the Learning Transcript (LT) report.
Reports clearly distinguish between direct completions, alternate completions, and revoked alternate completions to support compliance, support investigations, and audits.

Webhooks for equivalents and alternates

ALM provides dedicated webhook events for equivalent and alternate completions to support automation, integrations, and synchronization with external systems.

These events allow external consumers to reliably distinguish between direct completions and completions granted through alternate or equivalent relationships.

Overview

When a learner completes a course via an alternate or equivalent relationship, ALM triggers a webhook event that is separate from the standard course completion webhook.
This ensures that integrations can respond differently to alternate completions where required.

Webhook events are also triggered when retroactive completion or retroactive incompletion occurs, covering historical updates as well as relationship changes.

Webhook event behavior

Webhook payload details

The alternate completion webhook payload includes the following key attributes:

For retroactive incompletion scenarios, webhook events indicate that an existing alternate completion has been revoked.

Integration considerations

External systems can use these webhook events to:

Webhook consumers should explicitly differentiate between direct and alternate completions.
Alternate completions do not grant skills, badges, or gamification rewards and should be handled accordingly in downstream systems.

Impact of retiring and deleting source training in equivalents and alternates

The lifecycle state of a source training (retired or deleted) directly affects how alternate and equivalent completions are maintained for learners. ALM handles these scenarios differently to preserve historical accuracy while ensuring current relationships remain valid.

Retiring source training

Definition

Retiring a course makes it unavailable for new enrollments while keeping it in the system for historical reference, reporting, and audit purposes.

Impact

Deleting source training

Definition

Deleting a course removes it entirely from the system, including its completion records and configured relationships.

Impact

Workflow

No chaining of relationships

ALM does not support chaining of alternate or equivalent relationships. Alternate completions are granted only for directly configured relationships and do not cascade across multiple levels of courses.

Concept: no chaining of relationships

Definition

Chaining refers to allowing alternate or equivalent relationships to propagate across multiple courses.
For example, if Course A is an alternate for Course B, and Course B is an alternate for Course C, chaining would imply that completing Course A grants completion for Course C.

Policy

Chaining is not supported.
Alternate and equivalent relationships are evaluated only at a single level. Completing a source course grants alternate completion only to its immediate target course or courses, not to any downstream targets.

Workflow

Relationship setup

An administrator defines alternate or equivalent relationships between courses, such as:

Completion event

A learner completes Course A directly.

System action

Direct completion requirement

To receive alternate completion for Course C, the learner must:

Implications

No indirect benefits

Learners cannot receive completion credit for courses further down a relationship chain unless each course (or its direct alternate) is completed.
This ensures that learning requirements are met explicitly and predictably.

Simplified audit and reporting

Reports and learner transcripts display alternate completions only for direct relationships.
This avoids complex, multi-hop audit trails and ensures clarity when reviewing how a completion was granted.

Catalog sharing with peer accounts: relationships not shared

Catalog sharing allows learning objects (LOs) to be shared across peer accounts, but alternate and equivalent relationships are managed independently within each account and are not shared.

Concept: catalog sharing and relationships

Catalog sharing

Accounts can share catalogs with peer accounts to provide access to courses, learning paths, and other learning objects across accounts.

Relationships not shared

Alternate, equivalent, and alternate-completion relationships configured in the source account are not shared or replicated when a catalog is shared.
Each account maintains and evaluates its own relationships independently.

Workflow

Catalog sharing

An administrator in Account A shares a catalog containing learning objects with Account B.

Relationship configuration

Account A may have alternate or equivalent relationships defined among the learning objects in the shared catalog.

Peer account access

Account B receives access to the shared learning objects but does not inherit any alternate or equivalent relationships configured in Account A.

Independent management

If Account B requires similar alternate or equivalent behavior, an administrator in Account B must manually configure the relationships within that account.

Implications

No automatic relationship propagation

Alternate and equivalent relationships are not automatically available in peer accounts through catalog sharing.

Manual setup required

Each peer account is responsible for defining and managing its own relationships for shared learning objects.

Consistency considerations

Completion behavior, prerequisite satisfaction, and reporting may differ across accounts unless relationships are intentionally aligned through manual configuration.

Downstream behavior

Once an alternate completion exists for a target training, ALM uses it in downstream checks:

The system distinguishes between actual completion and alternate completion so that:

Alternate completions are designed not to interfere with actual learner activity on the target training. They act as an overlay that can be revised if the relationships change.