Skip to main content

Build and Manage Apps

Start here when you are creating a new app or tightening up an existing one.

Create the app record first​

Every app starts with a stable record.

At creation time, you are usually setting:

  • app name
  • slug
  • description

Do not treat those fields as filler. The slug affects install flow, and the name and description are part of how other people understand what this app is for.

What belongs in General​

The General page is for the app itself, not one specific version.

Use it to manage:

  • name
  • slug
  • description
  • distribution state
  • private-install allowlist
  • installation visibility at a high level

Think clearly about distribution​

The portal supports more than one distribution shape.

In plain terms:

  • Private means installs are limited to approved workspaces
  • broader visibility modes require Nawfe review before they should be treated as generally available

That split is useful. Private is the right place to start when you are still proving the app in a controlled environment.

Use the allowlist on purpose​

Private apps install only in approved workspaces.

That means the allowlist is not housekeeping. It is part of release control.

Use it when you want to:

  • limit preview installs to a test workspace
  • approve one customer workspace at a time
  • keep early app work out of the wrong environments

Check installed workspaces​

The installed-workspaces view helps you answer:

  • where this app is already installed
  • whether an install is active or disabled
  • what manifest channel those installs are following

That view matters more once the app is live. It tells you whether your changes are reaching the places you think they are reaching.

Good app hygiene​

  • Keep the slug stable once installs exist.
  • Write a description that tells people what the app actually does.
  • Start private before pushing for broader distribution.
  • Treat the allowlist as release control, not admin clutter.

Next reads​