Saas Dash
Architecture

Runtime Resolution

How first-party apps resolve into tenant runtimes and why presentation never overrides entitlement

First-party rule

First-party apps resolve from:

  • tenant app assignment
  • plan app entitlements

They do not resolve from workspace-local install rows.

Runtime contract

For UI consumers, the important pair is:

  • workspace_state
  • reason_code

That pair explains:

  • whether the app is available
  • whether it is visible
  • why it is in that state

Presentation rule

Visibility hints such as show_in_switcher or visible_in_selector must not remove an entitled app from the runtime apps payload.

They only affect rendering.

Outcome

This gives:

  • cleaner admin-app navigation
  • cleaner saasdash-app app management
  • simpler plan reasoning
  • no seed-and-heal logic for first-party app presence

Boundary consequence

The runtime resolver should work with top-level apps first.

It should not be asked to resolve:

  • product subpages as apps
  • payment infrastructure as apps
  • selector visibility as entitlement

That separation keeps the runtime aligned with the app boundary model.

On this page