Edmissa docs

Application stages

Troubleshoot stage movement, checklists, and pipeline behavior.

Use this guide when an application cannot move stages, appears in the wrong stage, or does not show the stage options a user expects.

Stage issues usually come from the selected pipeline, the current stage, checklist requirements, workflow rules, access scope, or an application being filtered out of the current view.

Confirm the application is in the right pipeline

Open Pipelines from the main navigation. This opens the Applications work area.

Check the selected view:

ViewWhat to check
List viewSearch for the application, then check its pipeline, stage, status, priority, assignee, and scope picker.
Board viewConfirm the selected pipeline. Board view groups applications by stage for one pipeline at a time.

If the application appears in list view but not board view, the board may be showing a different pipeline. Switch to the correct pipeline before changing the stage.

Board view showing applications grouped under Initial Consultation, Document Collection, and University Application stages.
Board view helps confirm whether an application is in the expected pipeline and stage column.

Confirm the stage change path

Users can move an application through stages from the stage selector in a list row, the application detail panel, or board interactions when their role allows it.

Before moving an application:

  1. Confirm the application number and student name.
  2. Confirm the current pipeline.
  3. Confirm the current stage.
  4. Choose the target stage.
  5. Read the Change Application Stage dialog before confirming.

The dialog shows the current stage, target stage, warnings, checklist messages, and reason fields when they apply.

Change Application Stage dialog showing a backward movement warning and reason field.
The stage change dialog helps users confirm the target stage and record why a stage is moving backward.

Stage selector is missing or disabled

If the user cannot change the stage, check these items:

CheckWhat to look for
Role accessThe user needs permission to update applications.
ScopeThe application must be inside the user's allowed scope.
LocationThe user must be allowed to work with the application's location.
Current viewThe stage selector may be available in list rows or detail view depending on layout and role.
Workflow stateApproval, checklist, or stage rules may block the move.
Feature availabilityPipelines and application workflows must be enabled for the workspace.

If the user can open the application but cannot change it, start with Access and permissions, then check the stage rules below.

Stage Change Blocked appears

The dialog can show Stage Change Blocked when required checklists must be completed before the application moves.

When this happens:

  1. Read the checklist names shown in the dialog.
  2. Review how many checklist items are complete.
  3. Complete the remaining required items.
  4. Return to the stage selector.
  5. Try the stage change again.

Hard checklist blocks cannot be skipped from the stage change dialog. If the team believes the block is wrong, an admin should review the checklist template and pipeline stage configuration.

Incomplete Checklists appears

The dialog can show Incomplete Checklists when the stage has soft checklist rules.

Soft rules allow an override, but the user must enter a reason. The reason must be at least 10 characters.

Use an override only when agency policy allows the application to move before the checklist is complete. Good override reasons are specific, for example:

Weak reasonBetter reason
Done laterStudent already submitted the missing bank statement by email. Counselor will upload it today.
Not neededUniversity waived the document after reviewing the student's prior submission.
Manager said okManager approved moving to Pre-Departure while final checklist item is confirmed.

If users override soft checklists often, review the checklist setup. The rule may be too strict for the real process.

Backward Stage Movement appears

The dialog shows Backward Stage Movement when the user moves an application to an earlier stage. Edmissa recommends a reason for this action.

Use backward movement for real corrections, such as:

SituationExample reason
Missing requirementReturned to Document Collection because the bank statement was rejected.
Wrong stage selectedMoved back to Initial Consultation after the application was opened too far ahead.
Student changed planReturned to University Application while the counselor confirms the new program choice.

Do not move applications backward just to clean up reports. The stage should match the actual work state.

Application is in an unexpected stage

Check these items:

CheckWhy it matters
PipelineThe stage belongs to the selected pipeline. A similarly named stage in another pipeline is different.
Board viewBoard view only shows stages for the selected pipeline.
Timeline or activityStage movement history can explain who moved the application and when.
Bulk changesA user may have moved several applications at once.
AutomationA configured rule may have moved the application after a trigger.
Stage orderMoving backward or skipping ahead can create confusion if the reason is unclear.

If the stage movement looks wrong, correct the stage and add a clear reason so the next user understands what changed.

Stage change fails after confirmation

If the user confirms the move but the application returns to the old stage, check:

CheckWhat to do
PermissionConfirm the user can update applications in the current scope.
Location accessConfirm the application is in a location the user can update.
Required checklistComplete hard-blocking checklist items.
Override reasonFor soft blocks, enter a reason with at least 10 characters.
Browser stateRefresh the list and reopen the application.
Configuration changeAn admin may have changed the pipeline or stage while the user was working.

If the problem repeats for one stage only, review that stage's configuration in Pipeline stages.

Admin checks

Admins should check configuration in this order:

  1. Open the pipeline and confirm the stage exists.
  2. Confirm the stage order and whether the target stage is active.
  3. Review stage checklists and blocking mode.
  4. Review any stage approvals or rules.
  5. Review pipeline form management if stage-specific forms are involved.
  6. Confirm application fields required by the workflow are present.
  7. Test with a sample application before changing live team guidance.
GuideUse it for
ApplicationsCreate, update, and move applications through stages.
PipelinesUnderstand how application workflows are organized.
Pipeline stagesConfigure stage behavior, requirements, and rules.
Pipeline form managementControl which forms apply at pipeline and stage level.
ChecklistsConfigure required and soft-blocking checklist work.
Access and permissionsCheck whether the user can update the application.