Participation Approval and Enrollment Requests - Article

What Participation Approval helps you achieve

Participation Approval inserts a controlled decision between a person's interest in training and their enrollment.

Use it when you need to:

• Review whether an applicant matches the intended audience.
• Let a manager approve the time, cost, or business relevance of training.
• Collect motivation, experience, consent, or practical information before deciding.
• Select participants for a limited-capacity program.
• Ask an approved applicant to reconfirm that they will attend.
• Coordinate admission to a paid activity without collecting payment before approval.
• Let managers request suitable training for employees or organization members.
• Preserve an administrative record of applications that were approved, declined, or left unresolved.

Do not enable approval merely to hide training from an audience. Organization visibility, Storefront audience controls, invitation-only enrollment, and self-enrollment eligibility solve different problems.

Approval is a process—not necessarily the final signup

A free activity with an available seat can register the participant as part of approval. A paid activity normally still requires checkout. An activity with post-approval confirmation waits for the participant's decision. A full activity can send the approved applicant to the waiting list. Always verify both the request status and the activity signup status.

Choose the correct enrollment control

Participation Approval is configured inside Self enrollment because the participant or a manager initiates the request from the participant-facing enrollment experience.

Understand the complete process

A basic approval flow is:

If a participation-confirmation questionnaire is required after approval, the Approved path contains another step:

If the participant does nothing before the configured confirmation deadline, the request becomes Approved (confirmation expired) and requires administrator or approver intervention.

Configure Participation Approval

1. Open Course Administration → Activities.
2. Open the intended Training Activity and edit it.
3. Add or enable the activity-level Self enrollment feature.
4. Enable Participation approval.
5. Select Who approves.
6. Decide whether unresolved requests should generate approver reminders.
7. Decide whether an application questionnaire is required before the request is sent.
8. Decide whether an approved applicant must complete a participation-confirmation questionnaire.
9. If confirmation is required, configure its deadline.
10. Save and test the flow with the intended approver type and participant audience.

Participation Approval depends on Self enrollment. If Self enrollment is disabled, participants do not receive the normal Request enrollment path through the Storefront.

Choose who approves

The Who approves field can provide:

• Immediate manager
• Organization manager
• Course administrator
• Specific person

If Specific person is selected, the email-address field supports multiple selections. The selected people receive and manage the requests and can make evaluations as a team.

Choose an approver that exists for the complete intended audience.

When Course administrator is the approver, Course Administrators set as Responsible for the activity receive the applicable request and reminder emails.

Avoid an approver with no valid relationship

A rule can be logically configured but operationally unusable if an applicant has no Immediate Manager, the selected manager cannot see the organization, or every named approver is unavailable. Test representative organization and reporting relationships before launch.

Configure approver reminders

Enable Enrollment request reminders when an unresolved request should prompt the selected approver again.

Configure the reminder as a number of hours or days after the request was submitted. If the request is still unprocessed at that point, Eurekos uses the system email: Settings → Email Sending → Activities → Enrollment request reminder – admin

The original request uses: Settings → Email Sending → Activities → Enrollment request sent – admin

Review both templates, translations, dynamic data, sender configuration, and delivery logs. The interface can tell participants that most requests are reviewed within 24 hours; treat this as participant-facing guidance, not a system-enforced service-level agreement.

Define an internal owner and actual review target that match the wording participants see.

Collect an application questionnaire before approval

Enable Require users to complete a questionnaire before enrollment when the approver needs information as part of the admission decision.

The selected questionnaire opens after the participant chooses Request enrollment. The participant must submit it before the request is created.

Suitable questions include:

• Why the participant wants to attend
• Relevant experience or prerequisite knowledge
• Role, organization, region, or customer context
• Consent or acknowledgement
• Preferred delivery option
• Supporting documentation
• Accessibility or logistical information that is appropriate at the application stage

Do not collect information merely because it may be interesting. Restrict questions to the approved decision purpose, define retention and access, and avoid exposing sensitive answers through unnecessary list columns or exports.

Review application answers

When a pre-enrollment questionnaire is connected, the Enrollment requests page provides Edit columns.

Approvers can add questionnaire questions as list columns. Supported filterable answer types include:

• Single choice
• Multiple choice
• Dropdown
• Linear scale
• Rating scale
• Consent
• NPS

Upload-file questions can also be selected as columns, and authorized users can download the submitted file from the answer.

The selected column arrangement is stored for the user's session. The default number of columns is controlled by the activity platform configuration.

Approvers can also preview the request and its questionnaire information before approving or declining it.

Repeated requests retain earlier answers

If a request with a completed questionnaire is declined and the participant requests the activity again, Eurekos informs them that their previous answers were kept.

Do not assume that a repeat request automatically represents new information. If the decision depends on changed circumstances, define how the applicant should update or supplement the retained response.

Require confirmation after approval

Enable Require users to complete a participation questionnaire after approval when approval should not immediately consume a place or complete the enrollment journey.

This is useful when:

• Seats are scarce and approved applicants must reconfirm attendance.
• Travel, availability, or final consent must be confirmed.
• The approval decision is made well before the activity.
• The participant must provide final information after selection.
• A formal acceptance step is part of the admission process.

Select the participation questionnaire and configure the response deadline as either:

• A number of Days after approval
• At specific date

What the approver does

With post-approval confirmation enabled, the normal Approve action becomes Approve and request confirmation.

When selected:

• The request becomes Approved (confirmation pending).
• The participant receives Enrollment approved with further details on confirmation – user.
• The email contains actions to confirm or decline participation.
• The participant can also take the available action from the Activity Description before the deadline.

No final signup should be assumed at this stage.

What the participant does

If the participant confirms before the deadline:

1. The participation questionnaire opens.
2. The participant submits the questionnaire.
3. The request becomes Approved.
4. The Activity Description presents the next applicable action: Go to training, Enroll, or Join waiting list.
5. Registration, checkout, or waiting-list processing continues according to price and seat availability.

If the participant declines:

• The request becomes Declined.
• The participant can request enrollment again later.

If the participant takes no action before the deadline:

• An hourly background process moves the request to Approved (confirmation expired).
• Confirm and Decline no longer proceed.
• The participant sees that the deadline to decide has passed.
• The status is a dead end for the participant.
• An approver or administrator must move the request back to Pending to restart the process.

Do not leave expired confirmations without an operational review owner.

Understand request statuses

Request status and signup status are separate. A request can be Approved while the participant still has no Registered signup because payment, confirmation, or waiting-list action remains.

Manage status transitions

The normal individual transitions are:

• Pending → Potential fit, Approved, or Declined
• Potential fit → Pending, Approved, or Declined
• Approved → Declined, which cancels an enrollment created from that approval
• Declined → Approved when the decision is reversed

Bulk actions also support returning selected requests to Pending or Potential fit.

Status changes remain possible after an earlier decision. Before reversing a decision, review:

• Whether a signup already exists
• Whether payment or a Transaction exists
• Whether a seat or organization allocation is occupied
• Whether the participant received an earlier decision email
• Whether a Community, Event, certificate, or nested activity was assigned
• Whether the new state requires participant communication

Changing Approved to Declined cancels the associated enrollment. It does not automatically reverse every connected commercial or external process.

Understand the participant experience

An eligible participant sees Request enrollment instead of Enroll on the Activity Description.

The interface explains that approval is required and that the participant will be notified. After confirmation, Eurekos acknowledges that the request was sent and provides a route back to the Storefront.

While Pending or Potential fit:

• The activity appears in My Overview → Waiting list.
• It has the label Enrollment requested.
• A tooltip explains that access follows approval.
• The activity is not clickable from that waiting-area presentation.

With post-approval confirmation:

• Approved (confirmation pending) appears with Participation confirmation pending.
• The participant is prompted to confirm so enrollment can be processed.
• Declined or expired confirmation removes the activity from that waiting-area presentation.

After ordinary approval:

• A free registered activity moves to the appropriate active area, such as Ongoing or Mandatory.
• A paid activity can disappear from the Waiting list area while checkout remains necessary.

Never use the My Overview section alone to determine whether the participant is registered. Check the request and signup records.

Understand free, paid, and full outcomes

Free activity with seats available

Without post-approval confirmation, approval creates a Registered signup.

With post-approval confirmation, the signup is created after the participant confirms and submits the questionnaire.

Paid activity with seats available

Approval authorizes the participant to continue but does not itself complete checkout. The participant receives the email with further details and uses Continue enrollment or returns to the Activity Description to enroll and pay.

With post-approval confirmation, the participant confirms first and then continues to checkout.

Activity with no available seats

When waiting lists are enabled and Seats are configured, approval checks capacity. If no seat is available, the approver is offered:

• Add to waitlist
• Enroll anyway
• Cancel the action

Adding to the waiting list gives the participant Waiting list signup status. Enroll anyway overrides capacity and creates a Registered signup.

For a paid activity, approval can lead the participant to the paid waiting-list checkout route rather than immediate registration.

If waiting lists are disabled and the activity is full, approval cannot silently create an ordinary place. Process requests individually when an authorized capacity override must be considered.

For more detail, see Registration Details and Capacity, Price Manager, Waiting list, Transactions.

Use Potential fit deliberately

Potential fit is useful when an applicant may be suitable but a final decision depends on:

• Comparative selection across applicants
• A later interview or assessment
• Employer confirmation
• Final cohort composition
• Budget or seat release
• Additional documentation

Potential fit does not enroll the participant or reserve a seat. Define how long requests may remain in this state and who must resolve them.

The applicant's My Overview presentation remains equivalent to a pending request, so do not rely on the status alone as participant communication.

Process requests from the Requests tab

Administrators with access to the Activity list open:

Course Administration → Activities → Requests

Managers, Immediate Managers, instructors, and other users without the complete Activity list can receive an Enrollment requests sidebar item when they are eligible approvers and relevant requests exist.

The Requests tab lists activities using information such as:

• Title
• ID
• Type
• Schedule
• Seats

Search can match:

• Activity title or ID
• Course title or code
• Event title
• Existing Training title
• Assignment title
• Program Number, when enabled

The Start from date filter follows the Activity-list approach: scheduled past and ongoing activities are evaluated against the selected date, while self-paced activities remain available regardless of that date.

Open an activity to reach its Enrollment requests page. The same page is available from the activity's Enrollment requests tab.

Work with the Enrollment requests page

The activity-specific page provides:

• Applicant name and email
• Requested date and time
• Request status
• Other requests indicator
• Search by full name or email
• Filters
• Configurable questionnaire columns when applicable
• Individual request actions
• Bulk actions
• Questionnaire reports when applicable

Available individual actions depend on status and configuration and can include:

• Preview request
• Potential fit
• Back to Pending
• Approve or Approve and request confirmation
• Decline

The Requested timestamp reflects the current request. If an earlier approved signup expired and the participant submitted a new request, the new request time replaces the earlier request time shown for the active request.

Use filters and questionnaire columns

Requests can be filtered by:

• Request status
• Enabled profile fields
• Supported answers from the pre-enrollment questionnaire

Use profile and questionnaire filters to support a defined selection policy—not to introduce hidden or discriminatory decision criteria.

When reviewing several applicants, add only the columns needed for the decision. Wide tables containing sensitive answers increase operational and privacy risk.

Review Other requests

The Other requests indicator can show whether the same person has:

• Pending enrollment requests
• Potential-fit requests
• Declined requests
• Pending confirmation requests
• Approved enrollment requests, including approval date

The detailed pop-up is available to the documented administrative roles. Other approver roles can see that another request exists without necessarily being able to open the complete cross-request detail. A dash appears when there are no other requests.

Use this information to avoid conflicting decisions or overbooking the same person across overlapping programs. Do not infer that another application should automatically disqualify the participant.

Process requests in bulk

Users with access to the Enrollment requests page can select several requests and:

• Approve or approve and request confirmation
• Decline
• Mark as Potential fit
• Return to Pending

Each bulk action asks for confirmation and then displays the result.

Capacity can create mixed outcomes. When waiting lists and Seats are enabled and the activity is full, approved requests beyond capacity can move to Waiting list. When waiting lists are unavailable, requests that cannot be given a seat can remain Pending while eligible requests are processed.

After every bulk operation:

1. Review request statuses.
2. Review resulting participant signup statuses.
3. Check seat and organization allocations.
4. Confirm notification outcomes.
5. Resolve skipped or exceptional records individually.

Do not assume a successful bulk message means every selected person received the same final enrollment outcome.

Let managers request training for others

Managers, Partners, and roles with the Immediate Manager add-on can request enrollment for people within their permitted staff or organization scope.

From the Activity Description, Request enrollment opens a list of eligible people who are not already enrolled. Depending on relationship and configuration, the list can include the requester.

The page provides:

• Name
• Email
• Organization
• Individual Request enrollment action
• Bulk Request enrollment action
• Search by name or email
• Filters such as Organization, Location code, Type, Job function, Country, Language, Extra, and Employment type

Approvers can sometimes enroll directly

When a Manager or Immediate Manager is themselves the configured approver for the relevant people, Eurekos can provide direct Enroll behavior instead of sending a request back to the same decision-maker.

For people outside that approver relationship but still inside the user's permitted management scope, Request enrollment can remain available.

Test the exact combination of:

• Manager role
• Immediate Manager add-on
• Organization relations
• Staff relations
• Selected Who approves option
• Requester included in or excluded from the managed population

Eligibility requirements still apply

If Restrict self enrollment until the criteria are met is enabled:

• The manager sees a warning to check requirements.
• A Requirements column explains why an individual is ineligible.
• Ineligible people are greyed out and have no individual Request enrollment action.
• They can still be included in a bulk selection, but Eurekos skips them and reports the number skipped.

Managers do not override participant-specific prerequisites merely by initiating the request.

Questionnaires submitted on behalf of staff

When the approval process requires the pre-enrollment questionnaire, the manager completes it for the selected person or people.

Each submission is recorded in Questionnaire analytics as a response by the person for whom enrollment was requested—not as the manager's own response.

For bulk requests, the approver email is sent separately for each requested person and appears to come from that person's name.

Ensure managers are authorized and able to answer the questionnaire accurately on another person's behalf.

Understand organization filtering

Request visibility follows role, activity responsibility, selected approver, and the platform's Organization filter.

In general:

• Top-level administrative roles can have complete access.
• Other administrators and approvers see activities and applicants within their permitted organization and responsibility scope.
• A Course Administrator can see requests for activities they are responsible for even when the applicants are outside the Course Administrator's own organization.

The same organization scope affects request lists and downloadable questionnaire reports.

Test with an approver from each relevant organization level. Never assume that seeing the activity means the approver can see every applicant or every other request.

Configure participant decision emails

Participation Approval uses dedicated system emails:

Review the templates under Settings → Email Sending → Activities.

The approved paid-training email should make the remaining checkout action clear. The confirmation email should make both Confirm participation and Decline understandable and display the applicable deadline.

When the activity automatically enrolls participants into scheduled Existing Training, the relevant enrollment confirmation can contain an Add to calendar file so participants receive immediate schedule information.

Add Automated Email Workflows

System approval emails and Automated Email Workflows are separate layers.

An Automated Email Workflow can use audiences such as:

• Participants with approved enrollment request
• Participants with declined enrollment request

Connect the workflow at the level whose schedule and participant population should drive the message.

When post-approval confirmation is enabled, the approved-request workflow is triggered after the participant confirms and submits the questionnaire—not merely when the approver first selects Approve and request confirmation.

The participant or approver can inspect the Notification timeline to see whether a rule was:

• Scheduled
• Sent
• Skipped because the request status was inappropriate
• Skipped because the rule's schedule dependency was unavailable

If a rule depends on activity Start or End and no Schedule is configured, Eurekos can skip the notification. For a request already in the matching Approved or Declined state, an authorized user can use Send notification from the timeline where available.

Changing a request from Approved to Declined—or the reverse—does not unsend the earlier message. The earlier state can remain represented as sent while a later rule is skipped or requires manual sending. Review the timeline before communicating a reversed decision.

Download questionnaire reports

The Get report action is available on the activity's Enrollment requests page when at least one questionnaire is connected to the approval process.

The available report choices are:

• Enrollment request questionnaire
• Participation confirmation questionnaire

The downloaded file follows the standard Questionnaire report format. Report access follows request-page and Organization-filter permissions.

Use reports for governed selection, operational preparation, and audit evidence. Store and share them according to the sensitivity of the answers.

Understand special signup cases

Change a live approval process safely

Before changing Who approves, questionnaire, reminder, confirmation, deadline, price, or seats:

1. Count requests in every status.
2. Identify requests already approved but not registered.
3. Identify pending confirmations and their deadlines.
4. Review participant-facing links already sent by email.
5. Review questionnaire responses and reporting access.
6. Check available seats and waiting-list entries.
7. Identify paid participants with incomplete checkout.
8. Decide who will complete unresolved decisions.
9. Test the new configuration with a fresh request.
10. Communicate any process change that affects current applicants.

Do not assume a new questionnaire or approver automatically rewrites requests already in progress.

Practical configuration patterns

Verify the configuration

Use representative accounts and the routes enabled for your delivery. Check the relevant outcomes before launch and after a material change; an administrator preview alone does not verify the participant experience.

Troubleshooting