Recording eLearning Task Completion During Connectivity Interruptions in Palestine

On Monday morning, a training coordinator opens the completion report for a new eLearning safety task. One technician appears twice. Another is marked overdue, although her supervisor watched her complete the task on Thursday at a customer’s site. Her phone had no signal there, and the result reached the eLearning platform three days later, after the deadline had been calculated.

Nothing in this story is unusual for teams that work in the field, in basements and plant rooms, or at sites outside reliable coverage. The practice itself can be designed to cope with interruptions, as covered in our guide to designing flexible eLearning practice around work schedules. The record of eLearning completion is a separate problem. If it is lost, late, or duplicated, HR cannot trust it, and employees lose confidence in the eLearning.

This article sets out four rules for recording eLearning task completion during connectivity interruptions: what counts as evidence offline, which time to record, how to give each completion a single identity, and how to sync and confirm. A short weekly reconciliation then keeps the records clean.

How eLearning Completion Records Go Wrong When the Connection Drops

Three failures account for most problems:

• Lost: the eLearning completion exists only on the device, and it disappears when the app is reinstalled, the phone is replaced or local storage is cleared before the next sync.

• Late: the completion arrives days after the work, and the eLearning platform records the arrival date, so a punctual employee appears overdue.

• Duplicated: the app resends after a failed attempt, the employee repeats the task because nothing confirmed it, or a paper slip is entered on top of a digital record.

Each failure needs its own rule. None of them is solved by asking employees to try again when they have a better signal.

Rule 1: Define What Counts as Offline Completion Evidence

Before launch, decide which forms of evidence the eLearning record will accept when there is no connection. Any acceptable evidence must show five things: who completed the task, which task and version, when it was completed, the result, and how the evidence was captured.

In practice, three forms cover most situations:

• An offline completion stored by the eLearning app on the device and sent automatically when a connection returns. This is the preferred form.

• A paper completion slip signed by the supervisor, with a pre-printed slip number, for cases where the app cannot be used at all.
• A supervisor’s observation record, for practical tasks that are assessed on site rather than on a screen.

Be equally clear about what does not count: a screenshot of a final screen, a chat message saying ‘done’, or a supervisor’s memory a week later. These cannot be checked, and they tend to create disputes that a clear rule would have prevented. Write the rule on one page and brief supervisors and employees before the first offline task, so that nobody learns it from a rejected record.

Rule 2: Record When the Task Happened, Not When the Record Arrived

A completion has two times: when the employee finished the task, and when the eLearning platform received the record. The xAPI data specification published by ADL keeps them apart. Its timestamp is the time at which the experience occurred, while the stored property is the time the learning record store saved the statement, and the specification acknowledges that there can be delays between the two.

Use the same distinction even if your eLearning platform does not support xAPI. Deadlines, compliance reports, and supervisor dashboards should use the completion time. The arrival time belongs in the audit trail, so late syncs remain visible. Set a tolerance, such as seven days between completion and arrival, after which a record is reviewed before it is accepted.

Device clocks need attention too. The same specification does not allow a future time in the timestamp, and a phone set to the wrong date can produce exactly that. Include a clock check in device setup, and flag any record whose completion time is later than its arrival time.

Rule 3: Give Every eLearning Completion One Identity

Duplicates are prevented at the moment of completion, not cleaned up afterwards. Each eLearning completion should receive a unique identifier on the device when the task is finished, and keep it through every resend. The identifier has to be created on the device rather than by the server, because the server is exactly what cannot be reached at that moment. Ask your provider to confirm how its app does this.

This is how xAPI is designed to work. According to the xAPI communication specification, when a learning record store receives a statement with an id it already holds, it must not modify its state, and it should return a conflict response if the two statements do not match. A batch containing two statements with the same ID should be rejected. The cmi5 specification, an xAPI profile for content launched from an LMS, adds a completion rule: a unit must not send more than one ‘completed’ statement within the same course registration.

For eLearning platforms and paper processes outside these standards, build a simple completion key: employee, task, task version, and attempt number. Whoever enters a paper slip or uploads an offline record checks the key first. If it already exists, the new item is attached as supporting evidence, not added as a second completion.

Rule 4: Sync Deliberately and Confirm Every Record

Employees should never have to guess whether their work was recorded. The eLearning app should show two clearly different states: ‘saved on this device’ and ‘recorded’. Keep the local copy until the platform confirms receipt, sync automatically when a connection returns, and offer a manual send option for employees who know they will be in coverage only briefly.

Late records can also run into session rules. Under cmi5, once a unit sends its ‘terminated’ statement, the LMS waits for a period it defines and then rejects further statements for that session. A result that arrives after that window may be refused, so check how your eLearning platform treats late records before you rely on them. Test at least these scenarios before launch:

• Complete an eLearning task in airplane mode, then reconnect and confirm one record with the original completion time.

• Interrupt the sync halfway, then resend.

• Complete the task on one device and open it on another before syncing.

• Reinstall the app while an unsynced completion is still on the device.

• Enter a paper slip for a task that was also completed offline in the app.

Our guide to testing LMS completion reports explains how to check that the results then appear correctly in the eLearning reports managers actually use.

A Weekly Reconciliation That Keeps Records Clean

Even with good rules, a short weekly check is worth the time. One named coordinator compares three lists: eLearning records still pending on devices, paper slips received, and completions flagged as possible duplicates by the completion key. Supervisors confirm anything unclear, and every correction is logged with a reason. When two records with the same key disagree, for example on the result, keep both, mark the conflict, and ask the supervisor which one reflects the work. Never let a later record silently overwrite an earlier one.

If supervisors take part, check that they can see and confirm only their own team’s records, as discussed in our article on testing supervisor permissions and training records for Palestinian teams. Keep evidence only as long as your records policy requires, and handle it under your organization’s data protection policies.

A Hypothetical Example: Safety Checks for Field Technicians

The following example is hypothetical and is included only to illustrate the method.

An appliance after-sales service company sends technicians to homes and small businesses across Nablus, Jenin and Tulkarm. A new eLearning task asks each technician to complete a short gas-safety check scenario and then confirm the same check at their next real installation. Many installations are in basements or stairwells where phones have little or no signal.

The company adopts the four rules for its eLearning records. The eLearning app stores each completion with a unique identifier and the completion time, shows ‘saved on this device’ until the platform confirms receipt, and syncs when the technician returns to coverage. Where a phone fails, the supervisor signs a numbered paper slip. The completion key is technician, task, version, and attempt.

In the first weekly reconciliation, the coordinator finds four paper slips for tasks that the app had also synced. Because the keys match, the slips are attached as supporting evidence instead of creating duplicate eLearning completions. Two records arrived five days late; both are accepted because their completion times fell before the deadline, and the coordinator notes which areas had the longest delays so supervisors can plan syncs at the depot.

Summary

When connectivity is interrupted, the record of eLearning completion fails in three ways: it gets lost, it arrives late or it is duplicated. Four rules address them: define acceptable offline evidence, record the completion time separately from the arrival time, give every completion one identity, and sync deliberately with clear confirmation.

Standards such as xAPI and cmi5 already build these ideas into how records are sent and stored, but the rules apply on any eLearning platform and even on paper. With a weekly reconciliation, HR and supervisors can trust that each eLearning completion in the report happened once, on the date shown.

Click here. If you need to set completion rules for eLearning that your teams complete offline, the SkillUp MENA team can discuss your requirements with you.