Restore a lost device

Revoke a lost device. Do not name it in replaces. replaces on enroll is for a deliberate swap, such as a new phone that succeeds an old one the person still holds. It is not for a device that is gone. Revoke the lost device from another device the person still holds. Then enroll the new device as an ordinary enrollment. It catches up on everything it missed.

Revoke the lost device

From another device of the same person, call people.revoke with the lost device’s RecipientId and the reason 'lost'.

The samples use the allowed helper from Access decisions.

TypeScript

await allowed(await client.people.revoke(lostRecipientId, 'lost'));

Swift

try await allowed(client.people.revoke(lostRecipientId, reason: .lost))

Kotlin

allowed(client.people.revoke(lostRecipientId, reason = RevocationReason.LOST))

Enroll the new device

Enroll the new device the same way you would enroll any device, with no replaces. It gets its own device certificate (card) and its own key. It starts catching up from nothing.

TypeScript

const enrollment = await sealdhealthcare.enroll({ hostname: 'records.example-health.com', tenantId });
const client = await enrollment.wait();

Swift

let enrollment = try await sealdhealthcare.enroll(EnrollRequest(hostname: "records.example-health.com", tenantId: tenantId))
let client = try await enrollment.wait()

Kotlin

val enrollment = sealdhealthcare.enroll(EnrollRequest(hostname = "records.example-health.com", tenantId = tenantId))
val client = enrollment.wait()

Watch what still waits

The new device does not get access to everything at once. Call offline.waiting() to render what is still queued. Watch the backfill event to learn when more completes.

TypeScript

render(await client.offline.waiting());
client.on('backfill', ({ waiting }) => render(waiting));

Swift

render(try await client.offline.waiting())
for await event in client.on(.backfill) { render(event.waiting) }

Kotlin

render(client.offline.waiting())
client.on<ClientEvent.Backfill>().collect { event -> render(event.waiting) }

Each BackfillWaiting carries:

• kind: domain or record
• locator
• dataset: the dataset it belongs to
• since: when the device started waiting
• canComplete: the people whose devices can complete it

Use canComplete to tell the person whom to ask. Do not leave them waiting in silence.

What the SDK does for you

• Gives the person’s new device access to every key domain and record it may see, on its own, session by session.
• As a member device, gives access to another member’s new device or queued group join, in its own next session.
• Raises backfill as soon as more access arrives. The person can open more without restarting.
• Shows whose devices can complete what still waits, through canComplete.

Decisions and errors you may see

revoke and enroll have their own decisions and errors. See people, devices and roles and enroll a device. offline.waiting() reports state. It is not a decision and has no Decided or SealdHealthcareError of its own.

Next

• Enroll a device for the full enrollment flow and its errors.
• People, devices and roles for revoking and offboarding.
• Worklist and events for backfill-waiting in the worklist.
• Work offline for how the offline lease and access for a new device interact.