Skip to content
Merulan

Build and publish an experience

Build a Workspace experience, check its data and delivery path, then confirm the version or report that viewers receive.

Use this guide when you build an experience with Apps & Dashboards. As a builder, choose its delivery path, check access, and confirm what the viewer receives.

Before you start

The experience needs a Workspace, rights to author, and access to its data. Choose a Dashboard for a saved view. Choose an installed App for packaged software. Apps and dashboards explains three paths: layout save, App publish, and provider publication. Each has its own effect. For an App, complete the Product install path and obtain its Product-specific publication procedure before starting. The steps below check App delivery. They do not supply that publication procedure.

Build the view

In the Console at /dashboards/new, create a Dashboard, bind its widgets to saved queries, and save it. Open the saved view to check its results. A widget must reference a query with the matching source. An accepted layout edit takes effect directly.

For an App experience, use that Product's procedure to prepare the version. Check the installed App and release evidence before handing it to the publisher. Authored files do not prove a release. A deployed draft is also not the published version.

Check delivery

For an experience served by a provider, open its connection controls. Check readiness before publishing. Review the proposed publication, then track its saved progress. Check the provider's verified result. The served revision must match the intended view before you call it ready.

For a hosted App, hand the checked version to the Product's publication procedure. Publish requires the observed current version and release readiness. After that procedure reports publication, reopen the installed App to check the version served to the viewer.

Checkpoints

The experience's saved definition must name the intended data and actions. Inspect it as the intended viewer to check for denied reads. For scheduled reports, check cadence, time zone, and recipient. Check export and channel readiness before enabling delivery. Preview sends no report. Read the saved schedule's applied state. When it runs, inspect the occurrence and its delivery receipt.

Success

The experience opens with the expected definition and permitted data. For an installed App, bootstrap readback confirms the version used to open it. For a Dashboard, readback confirms the saved definition. A provider view also needs a verified result. A scheduled send needs its delivery outcome. Share the experience after these checks match the intended path.

When it fails

The experience's failed stage determines the repair. Keep the saved definition, version, and refusal before changing the request.

ACCESS_DENIED

The caller lacks access to the App, Dashboard, or requested data. Obtain the required access, then repeat the refused read as that caller.

GOVERNANCE_DENIED

Policy refuses the requested action. Resolve the named policy condition before trying again. A share link does not replace that check.

Recovery

The experience may have saved successfully while provider publication failed. Preserve that distinction when using Recover app delivery. If an App's published version changed concurrently, read it again before choosing whether to publish. If a schedule's delivery is uncertain, inspect its receipt before another send. Refreshing the experience cannot settle an external writeback or prove that a recipient got the report.

Next steps