Skip to content
Merulan

Recover app delivery

Recover app delivery by reading the failed version, provider result, report receipt, or writeback state before choosing a repair.

Use this guide when an experience in Apps & Dashboards fails to load, publish, write, or send. As an operator, use its retained result to choose the repair.

Before you start

App delivery recovery needs the Workspace, experience, and failed request. Keep the installed version or Dashboard id. Retain the provider's failed revision and any report or writeback reference. Read the saved Dashboard definition to distinguish view and data failures. Check your rights for the repair path before changing a release or external resource.

Read the failure

For App delivery, read the installed version and release state. For a provider view, open recovery and inspect the saved diagnosis. For a report, inspect the schedule version, occurrence, and receipt. For a writeback, read status for the same request. An uncertain effect differs from a known refusal. Repeating a request can duplicate work outside Merulan.

Choose the repair

Provider delivery recovery has three paths. Missing resources need the binding detached before publishing again. Denied access needs the account authorized again, then checked. Drift needs a fresh publication or detachment. Review the impact before detaching. A resource needs proof of Merulan ownership before release. Detach does not broadly delete customer-owned resources. Revision history stays available.

For hosted App failures, compare the published version with the intended one. A revert must still pass checks for dependencies and settings. For writeback failure, follow the request's owning repair path. Publishing an App again does not repair the data change.

Checkpoints

App delivery repair must name the current version and its refusal. Detach requires the exact publication and control revision shown in its impact. Read again if that revision is stale. For reports, pause further sends when the problem could repeat. Keep the occurrence and receipt. An indeterminate send keeps its reservation. Do not replace it with a blind second send.

Success

App delivery succeeds when the intended viewer opens the checked version and reads its permitted data. A provider repair needs a fresh verified result. A scheduled report needs a delivered outcome for its occurrence. A writeback needs its settled status. Read each result again after repair. A green widget cannot prove a delivered report or a settled external value.

When it fails

App delivery repair follows the returned cause. Keep the prior failed revision or request even after a later attempt succeeds.

verification_missing

The provider resource is absent. Review detachment impact, detach the binding, then publish the Dashboard again.

verification_denied

The provider refused access. Authorize the connected account again, then verify the same resource.

verification_mismatch

The external resource differs from the plan. Review a fresh publication, or detach the binding after inspecting its impact.

Recovery

App delivery can remain blocked after a valid repair request. Read its current state before retrying. A writeback at awaiting_readback closes from an observed result without another external write. A conflict or manual review state needs the writeback repair contract. Keep the provider result with that request. Restoring view access cannot resolve a value conflict. View access also cannot prove that the provider accepted a write.

Next steps