# Test the workflow behind the preview.

Reviewed: 2026-09-12

Canonical: https://clankercloud.ai/learn/test-a-private-app

Start with a small dataset whose correct results you know. In the private App preview, test the main actions, filters, empty states, and behavior after reload on large and small screens. Review requirement checks and fix functional mismatches before deciding to share or publish.

## What you are working toward

A private App with an inspected behavior checklist and recorded remaining limitations.

## Start with

- An App preview with a clear primary workflow

- A small fictional or sanitized dataset with known answers

- Requirements for edits, persistence, access, and screen sizes

## Write acceptance criteria before clicking around

Open Apps and identify the one workflow the first version needs to support. “Show an owner’s open tasks” is testable. “Make a useful dashboard” is not enough to tell whether the build is correct. Write down the starting data, action, and expected result for each important requirement.

Include behavior that a screenshot cannot establish: applying and clearing filters, changing a value if edits are supported, reopening the App, and following its access path. Keep those requirements separate from optional enhancements. A small correct workflow provides better evidence than many controls whose effects have not been checked.

## Choose data that reveals mistakes

Use fictional or sanitized records for the first trial. Include a completed item, an open item, a missing value, and a combination that should return no matches. State what blanks mean and whether totals should reflect all records or the filtered subset. An ambiguous requirement can produce two plausible but incompatible implementations.

Do the expected arithmetic yourself for this small sample. If every record belongs to the same owner or status, a broken filter may look correct. Pick examples that produce visibly different results so you can distinguish an actual data change from an animation or a label changing on screen.

## Test a fictional three-record task tracker

Suppose the App contains T-1 assigned to Maya and Open, T-2 assigned to Ravi and In progress, and T-3 assigned to Maya and Done. The fictional requirement says the table and status counts follow the active owner filter. The following checks have exact answers before any real records are added.

Ask for the observed result beside each expected result. If the build instead intends global counts, decide whether that meets the workflow and change the label or requirement explicitly. Do not accept an unexplained mismatch simply because both numbers can be justified under different interpretations.

| Action | Expected fictional result | Failure it can reveal |
| --- | --- | --- |
| Open the default view | Three rows; one in each status. | Missing data or incorrect counts. |
| Filter owner to Maya | T-1 and T-3; Open 1 and Done 1. | Counts and rows use different scopes. |
| Add status In progress while Maya is selected | No rows and a clear empty state. | Filters fail to combine. |
| Clear both filters | The original three rows return. | Reset changes labels but not the data. |

## Check the interaction on different screens

Try the same workflow on a wide screen and a narrow screen. Inspect tables, menus, labels, and action buttons for overlap or clipped text. Use the keyboard to move through controls and confirm the current focus is visible. A control that works only with a precise mouse click may be difficult for actual users.

Test the empty result and missing-value cases deliberately. The App should explain what happened and provide a usable path back. If a long label obscures another value or a filter hides its reset control, report the specific starting state and action. Reproducible examples help the next revision address the real problem.

## Verify storage and reload behavior explicitly

If the App offers edits, change one fictional value, reload, and check what remains. Ask the build to explain the intended persistence behavior, then compare that explanation with what you observe. A private preview does not by itself establish that the App has a production database, cross-device storage, or live spreadsheet synchronization.

Do not treat a successful change in the interface as proof that it was saved. If an edit disappears, identify whether persistence was required but missing, or whether the build is intentionally a static demonstration. Resolve that difference before introducing real workflow data. Test the relevant behavior again after its implementation changes.

## Choose a reviewed build before sharing

Use requirement checks and the App’s saved build history to review changes. Fix one material failure, retest it, and check the adjacent workflow that the change could affect. For example, correcting filtered totals should also preserve the unfiltered totals and clear-filter behavior. Keep a short record of known limitations.

Open the actual preview of the version you intend to use. Creating or previewing an App does not publish it. When the functional checks pass, review its data and choose the appropriate private sharing or public publication path. Passing a small sample test is evidence about that tested scope, not proof that every future dataset or user action will work.

## Try this prompt

Copy into Apps. Opening Workspace does not send it automatically.

```text
Review this private App against a small test dataset before sharing. State the expected result for each main action, filter, empty state, and any edit followed by reload. Check a wide and narrow layout, keyboard navigation, and visible labels. Report observed results separately from assumptions. Fix the first failing requirement, then check that requirement and the related workflow again. Keep the App private.
```

## Before using the result

- Expected results are recorded before the test.

- Main filters, reset, and empty states match known data.

- Keyboard access and narrow-screen layouts are usable.

- Observed reload behavior matches the stated persistence requirement.

- The reviewed build and remaining limitations are identified.

## Common questions

### Can I build an App from a spreadsheet or idea?

Yes. Open Apps and describe the user, inputs, and actions you need. Start with sample data, inspect the private preview, try the main actions on large and small screens, and ask for changes before sharing or publishing.

[Read more in the FAQ](https://clankercloud.ai/faq#apps)

### Are Apps and files public as soon as I create them?

Creating or previewing an App does not publish it. Private sharing requires recipients to sign in. Publish only when you want a public link, and review the data included in the result. Manage private sharing in Shared.

[Read more in the FAQ](https://clankercloud.ai/faq#sharing)

### Where do I find and review the finished files?

Open your Project’s Files tab or General → Files. In a Session, Preview opens a side panel where you can select a file. Use page, sheet, or slide controls where available, check the contents, and download the result.

[Read more in the FAQ](https://clankercloud.ai/faq#review-files)

## Sources

- [Workspace guide: private App previews and build review](https://workspace.clankercloud.ai/#page=faq&tab=articles&article=apps-from-work)

## Related

- [A spreadsheet in. A useful App out.](https://clankercloud.ai/learn/build-an-app-from-a-spreadsheet)

- [An operations dashboard for your actual work.](https://clankercloud.ai/templates/operations-dashboard)

- [Share a reviewed App with the intended people.](https://clankercloud.ai/learn/share-apps-privately)

[Open Workspace](https://workspace.clankercloud.ai)

[Current pricing and usage](https://clankercloud.ai/pricing)