Stage 3 — App Collection Delivery
The app now runs (Stage 1) and is isolated to your target level (Stage 2). The final step is presentation: switch delivery from a full Virtual Desktop to an App Collection that projects only the application's own window — no desktop, no taskbar, no Explorer. This is the true SaaS experience: the user signs in and sees just your app in the browser.
Switch delivery mode
- Create an App Collection workspace and assign the same published application. See App Collection.
- Apply the policy you finalised in Stage 2 so isolation carries over unchanged.
- Assign the workspace to your test group and launch it.
- Compare against the Virtual Desktop. The single window should behave exactly as it did on the desktop. Anything that differs is a projection issue, addressed below.
An App Collection launches the executable directly without a desktop shell. Applications that assume a full Windows environment — a visible taskbar, Explorer, a specific working directory, or a launcher stub — may not appear, may show a blank window, or may exit immediately even though they ran perfectly as a Virtual Desktop. This is expected; the fixes below resolve most cases.
Common projection problems and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| App exits immediately or nothing appears | A launcher stub started the real process and then exited, so the collection sees the launcher close. | Publish the actual target executable, not the launcher/updater stub. Confirm the correct path in Publish an Application. |
| Window opens blank or with no content | The app expects a startup document, project, or mode it would normally get from the shell. | Supply the required startup argument in the application's arguments field (for example a file, profile, or /new-style flag). |
| App needs a specific working directory or relative files | Without a desktop, the working directory differs from a normal launch. | Use an absolute executable path and pass absolute paths in arguments; avoid relying on the current directory. |
| Second launch attaches to a hidden instance | Single-instance apps hand off to an existing process that has no visible window in the collection. | Pass the app's "new window"/"new instance" argument, or deliver it as a Virtual Desktop if it cannot be forced to a fresh instance. |
| A helper or child process is blocked | The app spawns a legitimate helper that Stage 2 isolation now blocks. | Add the helper to the childProcessPolicy allow list — see Child Process Control. |
| App relies on desktop chrome (tray icon, notifications) | App Collection provides no taskbar, tray, or notification surface. | Reconsider whether the feature is essential; if it is, deliver as a Virtual Desktop instead. |
Most projection issues are solved by publishing the correct executable and adding the right command-line arguments in the application definition. Treat the arguments field as your primary tool for making an app launch cleanly as a single window. Capture the working definition as JSON so it can be reused per customer — see Import / Export.
Some applications genuinely need a desktop — multi-window suites, shell-integrated tools, or apps that depend on the taskbar. If an app cannot be coaxed into a clean single-window launch, keep delivering it as the isolated Virtual Desktop from Stage 2. You still get full governance; you simply present a desktop rather than a single window.
You have SaaSified the app
The application now launches directly in the browser, isolated by a policy you control and presented as a single-purpose SaaS experience. Repeat the three stages for each new application, and reuse your policy and application JSON to make onboarding repeatable.