Completion Behavior - Article

What Completion Behavior helps you control

Eurekos normally records a module as complete automatically when the module's configured requirements have been fulfilled. That is the correct behavior for most training.

Completion Behavior provides additional control when the standard transition does not create the participant experience you need.

Typical uses include:

• Completing a short introductory Course without interrupting the learner with a celebration
• Asking a participant to acknowledge that they have finished reading a summary or procedural document
• Requiring a deliberate final action after a Course's videos, pages, and interactions are complete
• Keeping the end of a small nested Training Activity quiet inside a larger journey
• Waiting for a participant's confirmation after the normal Event or Assignment evidence has already been recorded

The feature is most useful when the learning evidence is already clear but the final interaction needs adjustment.

Completion Behavior is not a new completion criterion

It does not decide whether a test was passed, an Event was attended, an Assignment was approved, a video was watched, or a certificate was earned. Those conditions remain controlled by the Course, module, schedule, assessment, attendance, certificate, and other connected settings. Completion Behavior controls what happens after the applicable conditions have been met.

Understand the completion layers

Several features can influence an apparently simple question: “Has this participant finished?” Keep their responsibilities separate.

Completion Behavior sits between the learning evidence and the recorded completion. It should therefore be designed together with every process that depends on that completion.

Choose the correct control

Do not use Completion Behavior for a problem owned by another feature.

The controls can be connected. For example, an Event can require attendance and then ask the participant to confirm completion. The confirmation is an additional final step; it does not replace the attendance record.

Understand the available behaviors

There are three effective outcomes.

“Complete automatically” does not mean that opening a module automatically completes it. It means Eurekos applies the module's ordinary completion logic without an extra confirmation step.

Where Completion Behavior is configured

Completion Behavior is a module-level feature. It is configured independently on each module occurrence inside a Training Activity.

It is not an activity-level setting. In a learning path with several modules, one module can use participant confirmation while the others complete automatically.

Supported module types

If an option is unavailable, first confirm the module type. Existing Training intentionally has only the option to suppress the congratulations message.

Configure Completion Behavior

1. Open Course Administration.
2. Find and edit the Training Activity.
3. Locate the Course, Event, Assignment, or Existing Training module whose completion experience should change.
4. Open the module's Features or gear menu.
5. Enable Completion behavior.
6. Select the required supported option.
7. Save the Training Activity.
8. Preview the activity and test it with a participant account.
9. Verify the module status, overall activity status, certificate, automation, and any later restricted module.

Configure the feature on the exact module that owns the participant action. Enabling it on one Course module does not apply it to the other modules in the activity or to other Training Activities that reuse the same Course.

Leave Completion Behavior disabled for standard completion

When the feature is disabled, Eurekos uses its default Complete automatically behavior.

The system evaluates the requirements already associated with that module. Depending on the module and its configuration, those requirements can involve:

• Course pages and tracked content
• Video, audio, or interactive-object completion
• Test results
• SCORM or xAPI signals
• Schedules and end dates
• Event attendance
• Assignment assessment
• Certificate issuance criteria
• Completion of a child Training Activity
• Required modules in the wider learning path

No additional participant acknowledgement is added.

Use the default when:

• The tracked learning action already provides sufficient evidence
• Immediate completion is expected
• Completion unlocks the next step without a meaningful reason to pause
• The participant should not need to understand a separate administrative confirmation
• The journey is high-volume and an extra click would add friction without adding value

Default behavior is usually the clearest choice. Enable Completion Behavior only for a defined learning or experience reason.

Use Don't show congratulations message

What it means

Don't show congratulations message suppresses the normal completion message. It does not stop or delay completion.

What happens

When the normal module requirements are met:

• The module receives its normal completion status.
• Tracked videos, schedules, attendance, assessment, and other evidence retain their normal meaning.
• A connected certificate can still be issued when its criteria are met.
• Completion-dependent processes can continue.
• The congratulations message is not shown for that module.

The option changes presentation, not evidence or status.

When to use it

Use it when the completion message would feel disproportionate or interrupt the learning flow.

Examples:

• A one-page Course introduces the program and completes as soon as it is viewed.
• A short transition module tells participants what will happen next.
• A reference page sits between two substantial modules in a learning path.
• A nested child activity finishes inside a broader program where only the overall completion should feel celebratory.
• An administrative information module needs to complete quietly while still contributing to progress.

Single-module activities

If the Training Activity contains only one module and Don't show congratulations message is enabled on that module, the activity's completion popup is also hidden because the module and the complete training finish together.

This is an important difference from a larger learning path. In a multi-module activity, test the final transition from both the module and learning-path overview. The documented single-module rule should not be generalized to every possible combination of module and activity messages without testing the configured journey.

What it does not suppress

The setting does not disable the underlying completion event. It should not be treated as a general “turn off all notifications” control.

Processes that react to recorded completion—such as certificate issuance, a completion-triggered Automated Email Workflow, an Access Restriction, or parent-path progress—can still proceed.

If the activity uses Rating, remember that rating is normally offered in the completion experience. Confirm that participants can still find the Rate training action when the completion popup is intentionally removed. Similarly, do not rely only on the completion popup to explain feedback, renewal, or next-step obligations.

Use User confirmation is required

What it means

User confirmation is required adds a deliberate participant action after the module’s normal completion requirements have been fulfilled.

The Complete button becomes available only when those requirements are satisfied. The module is not recorded as Completed until the participant selects the button.

The participant journey

1. The participant fulfills the module’s normal learning requirements.
2. The Complete button becomes available.
3. The participant selects Complete.
4. The module is recorded as Completed.
5. The Training Activity is recalculated, and completion-dependent rules and processes can continue.

Before the participant selects Complete

• The required learning evidence can already be satisfied.
• The module is not yet recorded as Completed.
• The Training Activity can remain incomplete.
• A later module that requires this completion can remain locked.
• A workflow waiting for participant completion can remain pending.
• A certificate that depends on the module can remain unissued.

After the participant selects Complete

• The module changes to Completed.
• The Training Activity is recalculated.
• The participant sees the normal congratulations message.
• Completion-dependent Access Restrictions, certificates, automation, and parent-activity progress can be evaluated.

When to use it

Use participant confirmation when the deliberate acknowledgement has a clear purpose.

Examples:

• The last Course page summarizes a procedure and asks the participant to confirm they are finished.
• A policy-reading Course contains no measurable interaction, but the organization wants a clear completion action.
• A facilitated module requires the participant to acknowledge that all learner-side work is finished after the instructor-side evidence is recorded.
• A learning stage should not release the next step until the participant deliberately concludes the current one.

What the confirmation proves

The Complete button proves that the signed-in participant selected the completion action for that attempt. It does not by itself prove:

• Attendance at a live Event
• Identity beyond the platform's normal sign-in controls
• Knowledge or competence
• Successful practical assessment
• Reading comprehension
• Legally valid consent or electronic signature
• Completion of an external process that does not report evidence to Eurekos

Use attendance, tests, Assignments, certificates, legal-document functionality, or another governed process when the required evidence is stronger than acknowledgement.

Understand when the Complete button appears

The button is not a replacement for the module's ordinary completion rules. It becomes available only after those rules are fulfilled.

The exact moment depends on the complete module configuration. If the button is missing, investigate the underlying condition first; repeatedly enabling and disabling Completion Behavior will not make incomplete evidence complete.

Course-module behavior

A Course can contain simple pages, media, interactive content, tests, and external packages. Each can contribute different progress signals.

Quiet completion for simple content

A short text-only Course can complete automatically because there may be no separate interaction beyond viewing its content. This is a strong use case for Don't show congratulations message when the Course is only an introduction or transition.

Do not hide the message simply because the Course is short. If completing it grants a certificate, unlocks regulated work, or marks a substantial milestone, the visible acknowledgement may still be valuable.

Confirmation after tracked content

With User confirmation is required, the participant must first satisfy the Course's existing requirements. A final summary page with no new measurable action can then provide context for the Complete button.

Design the last page so participants understand:

• What they have completed
• Why confirmation is requested
• What selecting Complete will do
• What happens next
• Where to go if the button does not appear

SCORM and xAPI Courses

External packages must still send the completion or success information required by the Course and any certificate criteria. Completion Behavior cannot repair an incorrectly authored package or invent a missing Passed state.

If the package appears finished but the Complete button is absent:

1. Check the package's reported completion and success states.
2. Check its score and attempt configuration.
3. Confirm any certificate or schedule dependency.
4. Test the package independently where appropriate.
5. Review Progress before changing Completion Behavior.

Event-module behavior

Event completion can depend on schedule, attendance, certificate criteria, and other configured behavior.

Do not replace attendance with confirmation

If verified attendance is required, keep the Event's attendance process. A participant clicking Complete does not establish that an instructor or integration recorded attendance.

Use confirmation only as an additional learner-side step, for example when participants must acknowledge that they attended and reviewed follow-up information after the official attendance record exists.

Scheduled completion

The Complete button cannot be expected before all applicable Event conditions are met. If the Event has not ended, attendance remains unmarked, a required recording has not been completed, or certificate conditions remain outstanding, the module may not yet be ready for confirmation.

Events in a learning path

Consider the operational consequence of requiring participant confirmation after a facilitated Event. An administrator can record attendance for the entire cohort, but every participant must still perform their own confirmation before a dependent module or overall activity can complete.

Use this only when the participant action adds value and communication makes the remaining step clear.

Assignment-module behavior

The Assignment's assessment remains authoritative.

• A draft is not a submission.
• A published submission can remain Not assessed.
• Failed or Not assessed work does not satisfy a required Passed outcome.
• The responsible instructor or authorized administrator records the assessment.
• Participant confirmation does not convert failed work into passed work.

If User confirmation is required, the Complete button appears only after the Assignment's normal completion evidence is ready. For the standard assessed flow, that means the required Passed result must still exist.

Use the additional confirmation sparingly. In many assignment designs, the instructor's Passed assessment is already a clear and sufficient completion event. Add participant confirmation only when the learner must acknowledge the result, feedback, or next step.

Existing Training behavior

An Existing Training module connects another independent Training Activity to a parent journey.

The Existing Training occurrence supports Don't show congratulations message, but not User confirmation is required.

This prevents the parent wrapper from adding a second learner confirmation around the completion of an independent child activity. If a child Course, Event, or Assignment genuinely needs confirmation, configure Completion Behavior on that child module.

Keep these layers distinct:

• The child Training Activity owns its modules and completion configuration.
• Enable tracking progress determines whether the Existing Training module contributes its status to the parent path.
• Completion Behavior on the Existing Training occurrence can suppress the parent-side completion message.
• The child can issue its own certificates and notifications.

Test both the child and parent journey, particularly when a participant enters the child from the parent learning-path overview.

Single-module activity versus learning path

Single-module activity

The one module effectively determines the complete Training Activity experience.

• Requiring confirmation on the module delays completion of the activity.
• Suppressing the module congratulations message also suppresses the training completion popup.
• Module-level certificate, schedule, and completion rules can determine the status of the whole activity.

Test from the Activity Description, Learn mode, and the participant's training overview.

Multi-module learning path

Each module can use its own Completion Behavior.

For example, a learning path could use different Completion Behaviors across its modules:

1. Welcome and objectives — completes quietly
2. Safety Course — completes automatically
3. Practical Event — completes from recorded attendance
4. Supervisor Assignment — completes when assessed as Passed
5. Final acknowledgement — completes when the participant selects Complete

Avoid requiring confirmation on every module merely for consistency. Repeated Complete buttons create friction and make it harder for participants to understand which acknowledgement matters.

If only one final acknowledgement is required, use a purposeful final Course module and explain its role. Confirm that the preceding modules, Access Restrictions, and adaptive rules still create a reachable path.

How Completion Behavior affects downstream features

With Don't show congratulations message, the completion event still occurs normally. With User confirmation is required, dependent processes wait until the participant confirms, where their rules depend on that completion.

Overall Training Activity completion

A required module that still awaits confirmation can keep the complete learning path In progress. Selecting Complete causes the activity status to be recalculated together with its other modules, schedule, and certificate requirements.

Certificates

If certificate issuance depends on completion of the module, the certificate waits until participant confirmation has finalized that completion.

Do not create a circular design in which:

• The Complete button waits for a certificate, and
• The certificate waits for module completion.

Build and test the complete criterion sequence. A certificate can also remain unissued because of a test, attendance, feedback, schedule, or other criterion unrelated to the Complete button.

Don't show congratulations message does not prevent certificate issuance. The participant can still receive the connected certificate and applicable certificate communication.

Access Restrictions

A later Course or Event can use completion of the current module as an Access Restriction. If user confirmation is required, the later module remains locked until the participant selects Complete and the prerequisite status is recorded.

Explain the dependency in the final page or module description. Otherwise, participants can believe they have finished the visible content while the next module remains unexpectedly locked.

Automated Email Workflows

A workflow using Participant completed at the module level waits for the recorded completion event. With confirmation required, fulfilling the learning criteria is not enough; the participant must select Complete.

Similarly, the participant can remain part of a Participants not completed audience until confirmation occurs.

Attach the workflow at the level whose completion matters:

• Module level for follow-up to one Course or Event
• Activity level for completion of the complete learning path

Hiding the congratulations message does not stop a completion-triggered workflow.

Training Feedback

Feedback configured to become available only after completion can wait for the module- or activity-completion signal at its connected level. If participant confirmation is required, the participant may need to select Complete before the feedback action becomes available.

When feedback is required for certificate issuance, the expected sequence is:

1. The participant fulfills the underlying learning requirements.
2. The participant confirms completion by selecting Complete.
3. The feedback becomes available.
4. The participant submits the required feedback.
5. The remaining certificate criteria can be evaluated.

The exact sequence depends on the levels at which the Course or Event, feedback, certificate, and workflow are connected. Avoid creating a circular process in which each step waits for another step that is not yet available.

Mandatory deadlines

A participant can remain incomplete—and later appear Overdue—if they finish the learning but do not select the required Complete button before the deadline.

Use reminder communication that names the action. “Complete your training” may be too vague when the only remaining task is to return and select Complete.

Access Expiration

When Access Expiration is calculated from completion, the relevant completion time occurs only after the confirmation is recorded. A delayed confirmation can therefore delay the start of a completion-relative access period.

If access expires from another event, such as enrollment or a fixed date, ensure the participant has enough time to reach and select the button before access ends.

Adaptive Modules

Completion Behavior applies after a module is part of the participant's adaptive path. A hidden Supplemental module has no participant completion step until it becomes visible. A module that becomes optional should not be used as an unavoidable confirmation gate for the required journey.

Review adaptive state and Completion Behavior together so the participant does not receive an unnecessary acknowledgement for optional enrichment or lose access to a required final confirmation.

Existing Training and parent progress

When a child Training Activity is represented through Existing Training and tracking contributes to the parent, a child module waiting for user confirmation can keep the child—and therefore the tracked parent module—incomplete.

Troubleshoot from the inside out:

1. Open the child Training Activity.
2. Identify the child module still awaiting completion.
3. Confirm whether its Complete button is available and selected.
4. Verify child activity completion.
5. Allow the parent progress to recalculate.

Rating

Rating can be presented in the completion popup. If you hide the congratulations message, verify how the participant will discover the alternative Rate training action in your configured interface.

Requiring confirmation can delay the completion moment at which Rating is offered. In re-certification, a participant can rate each attempt.

Progress and reporting

Progress should be interpreted at the level where Completion Behavior is configured.

A participant can have satisfied the visible content requirements but still show the module or activity as incomplete because the Complete button has not been selected. Review:

• Current attempt
• Module status
• Underlying content or assessment evidence
• Schedule and attendance
• Certificate state
• Completion Behavior
• Activity-level status

Do not force completion before confirming whether the remaining participant acknowledgement is intentional and reachable.

Re-certification and new attempts

When User confirmation is required, the Complete button appears again in each new re-certification attempt after the underlying module requirements are fulfilled.

The earlier acknowledgement belongs to the earlier attempt. It is not treated as confirmation of a later renewal cycle.

This means a renewal design should explain:

• What the participant must repeat
• What progress is carried forward, if any
• When the Complete button will appear
• Whether feedback must be submitted again
• Which certificate is being renewed
• When the new certificate becomes available

Don't show congratulations message continues to affect only the completion presentation. It does not prevent the new attempt from completing or receiving a certificate.

If Completion Behavior is added or changed after a participant has already received a certificate, the documented behavior is that the existing training status is not rewritten. Test the next applicable attempt before relying on the new behavior for renewal.

Administrative completion is a separate process

Authorized users can use Mark as completed for exceptional cases from Progress or participant administration. This is not the same as the participant selecting Complete.

Administrative completion can affect status, certificates, restrictions, and reports. It should follow an approved exception policy and include the available audit comment. Do not use it routinely to compensate for unclear instructions or an unreachable Complete button.

Change Completion Behavior on a live activity

Changing the feature can affect an active participant journey. Review the reason and impacted population before saving.

Before enabling user confirmation

Check:

• Whether existing participants have already satisfied the underlying criteria
• Whether the new Complete button will be easy to find
• Whether any participant is close to a Mandatory deadline or Access Expiration
• Whether a certificate or later restriction depends on module completion
• Whether completion-triggered workflows will now wait
• Whether a re-certification attempt is active
• Whether participants need communication about the added action

Before removing user confirmation

Removing the confirmation requirement returns the module to its ordinary completion behavior. Participants whose underlying criteria are already satisfied may complete through recalculation.

Test a representative active participant before changing a large live cohort. Review resulting certificates, downstream access, workflow timelines, and completion dates.

Before hiding or restoring the message

The message option should not change completion status. It can still change how participants discover:

• Rating
• Feedback
• Certificate information
• A next activity
• Renewal guidance
• Support instructions

Ensure another visible route exists for any action previously explained only in the popup.

Previously certified participants

Adding or modifying Completion Behavior after a participant has received a certificate does not change that participant's existing training status. Do not expect the feature to retroactively revoke completion or request a historical acknowledgement.

Use the normal certificate, re-certification, or governed exception process for existing records.

Clone, repeat, and linked activities

Clone

Cloning a Training Activity copies its enabled features and configured values, apart from documented exceptions such as Community connection. Completion Behavior should therefore be reviewed on every cloned module.

A cloned Course can have the same content and behavior while serving a different business process. Confirm that a quiet introduction or participant acknowledgement still makes sense in the clone.

Repeat

A repeated delivery begins from copied activity configuration. Review Completion Behavior together with new dates, Event attendance, Assignment deadlines, certificate rules, and communication.

The learners are new or in a new delivery context; do not assume a setting is correct merely because it worked for the source activity.

Linked activities

Linked activity updates can synchronize selected activity-level fields. Modules and their module-level features remain delivery-specific. Changing Completion Behavior on a module in one linked activity should not be treated as a reliable way to update all linked occurrences.

Open and verify each affected activity when the same completion policy must apply across a linked group.

Design a clear confirmation experience

If participant confirmation is required, the learner should not have to guess why.

Place concise guidance near the end of the module:

When you have completed the material on this page, select Complete to record this module as finished and continue to the next step.

Where appropriate, also explain:

• What requirements must be satisfied before the button appears
• Whether an instructor must first record attendance or assess work
• What selecting the button confirms
• Whether a certificate or next module will then become available
• Where to return if the participant leaves before confirming
• Who to contact if the evidence is complete but the button is missing

Avoid language such as “By clicking this button you legally certify...” unless the organization has reviewed whether the platform action and audit evidence support that exact legal claim.

Verify the configuration

Preview is useful for layout, but a real participant signup is needed to validate status, attempts, certificate issuance, restrictions, and automation.

Minimum test matrix

Test representative module configurations

Do not validate only with a one-page Course. Include every configuration used in production:

• Native Course with simple pages
• Course with required video or audio
• Course with H5P assessment
• SCORM or xAPI Course
• Scheduled Course
• Event with attendance
• Event with certificate
• Individual Assignment
• Group Assignment where relevant
• Existing Training with progress tracking
• Adaptive module
• Activity- and module-level certificates
• Required Training Feedback

Use a new or controlled test participant so earlier completion and certificate records do not hide the behavior you are trying to verify.

Practical configuration patterns

Troubleshooting