Lesson video coming soon. The player below contains a sample video, not this lesson. You can use the written lesson and slide guide now.

Open video on YouTube ↗

Download slide guide (PDF)10 pages · 4.5 MB

Work through the lesson

Use these explanations alongside the slide guide. Expand any section to read its full explanation.

Before the demonstration

• Your assigned responsibility
• The correct training record
• Evidence of the result

Today’s outcome
Pending evidence is preserved and one accepted synchronized event can be verified.

Read the full explanation

Before we begin, check these prerequisites: C02–C03; app previously loaded online and supported storage; disposable profile. The intended outcome is: Pending evidence is preserved and one accepted synchronized event can be verified. Keep a note of the training identity and date so that you can recognize the result. We will pause before any action that your role or the exercise does not authorize.

Online preparation

• While online open the app in the intended browser, confirm enrollment and check storage readiness
• install via browser if supported

In this step
Prepare while the server is reachable. Load the application in the enrolled browser and inspect storage readiness. Browser installation options differ, so the important check is whether this device can keep the required page and evidence.

Read the full explanation

While online open the app in the intended browser, confirm enrollment and check storage readiness; install via browser if supported. Prepare while the server is reachable. Load the application in the enrolled browser and inspect storage readiness. Browser installation options differ, so the important check is whether this device can keep the required page and evidence. I will pause here so you can identify the control or result that tells us where we are in the workflow.

A disconnected event

• Disconnect only the training device from the server/network and record a standard event

In this step
Use only the designated training device for this exercise. Record the event normally and observe how the result changes when the server cannot receive it. Other devices and the shared server should remain connected.

Read the full explanation

Disconnect only the training device from the server/network and record a standard event. Use only the designated training device for this exercise. Record the event normally and observe how the result changes when the server cannot receive it. Other devices and the shared server should remain connected. I will pause here so you can identify the control or result that tells us where we are in the workflow.

The pending queue

• Read local-only completion and the Pending queue rather than claiming server success

In this step
A queued record still needs server acceptance. Keep the browser profile and site data because they hold the pending evidence. Closing a page and clearing its storage are different actions with very different consequences.

Read the full explanation

Read local-only completion and the Pending queue rather than claiming server success. A queued record still needs server acceptance. Keep the browser profile and site data because they hold the pending evidence. Closing a page and clearing its storage are different actions with very different consequences. I will pause here so you can identify the control or result that tells us where we are in the workflow.

Synchronization results

• Reconnect and choose Upload pending check-ins
• inspect each row/result and server history

In this step
After reconnecting, inspect each upload result. Then find the event in server history and compare its identity and time. A working internet connection does not necessarily mean you can reach the organization’s attendance server.

Read the full explanation

Reconnect and choose Upload pending check-ins; inspect each row/result and server history. After reconnecting, inspect each upload result. Then find the event in server history and compare its identity and time. A working internet connection does not necessarily mean you can reach the organization’s attendance server. I will pause here so you can identify the control or result that tells us where we are in the workflow.

Rejected evidence

• For rejected/conflict/too-old evidence retain the record, export pending evidence if needed, and contact support with the error

In this step
Keep rejected or conflicting evidence and the error message. Export pending evidence when support requests it. Repeatedly retrying or editing signed data can hide the information needed to explain why the server rejected the record.

Read the full explanation

For rejected/conflict/too-old evidence retain the record, export pending evidence if needed, and contact support with the error. Keep rejected or conflicting evidence and the error message. Export pending evidence when support requests it. Repeatedly retrying or editing signed data can hide the information needed to explain why the server rejected the record. I will pause here so you can identify the control or result that tells us where we are in the workflow.

Common problems

• Clearing storage while pending
• assuming internet means appliance reachability
• retrying rejected evidence indefinitely
• expecting reports or guest entry offline

A useful support report
The task and record
The expected result
The actual message
The authorized next step

Read the full explanation

Let us consider the mistakes that can disrupt this workflow. Clearing storage while pending; assuming internet means appliance reachability; retrying rejected evidence indefinitely; expecting reports or guest entry offline. Describe what you expected and what the application actually showed before choosing a remedy. Preserve the relevant record and error. The role responsible for a review or configuration change should make that decision. Do not borrow broader access simply to finish the exercise.

Guided practice

• Queue one disposable training event offline, reconnect, synchronize and prove it appears once in server history
• Discuss a prepared rejected/conflict screenshot instead of tampering with signed data

Evidence to show
The correct training case
The result or permitted decision
Your explanation of the next step

Read the full explanation

Now it is your turn. Queue one disposable training event offline, reconnect, synchronize and prove it appears once in server history. Discuss a prepared rejected/conflict screenshot instead of tampering with signed data. Work within the assigned training role. When you finish, show the result and explain which identity and date it belongs to. If the exercise includes a restricted action, explain the decision and its authorized owner rather than carrying it out without approval.

Practice debrief

• Correct context and permitted action
• A result you can trace
• A clear next step if blocked

Expected result
Pending evidence is preserved and one accepted synchronized event can be verified.

Read the full explanation

The expected outcome is: Pending evidence is preserved and one accepted synchronized event can be verified. Walk me through the record you used and the result you found. Explain these workflow checkpoints in order: While online open the app in the intended browser, confirm enrollment and check storage readiness; install via browser if supported. Disconnect only the training device from the server/network and record a standard event. Read local-only completion and the Pending queue rather than claiming server success. Reconnect and choose Upload pending check-ins; inspect each row/result and server history. For rejected/conflict/too-old evidence retain the record, export pending evidence if needed, and contact support with the error. For an exception, name the evidence you would preserve and the person with authority to take the next action.