Installing an App into an Organization

The admin-side install walkthrough: grant access, install, Set Data Access, source mappings, first run, and how to confirm it actually worked.

This is the walkthrough for installing a published app into an organization, written for org admins and publishers testing their own apps. For the end-user App Store experience, see App Store Basics. Every step verified live in production, August 2026.

Before you start

Step 1: Grant the org access to the app

Org Settings > Apps. Find the app (check the "No Access" tab if you don't see it) and grant access.

Note: seeing the full catalog of every app is a Seek Admin capability; customer org admins see the App Store listings plus apps they've been granted.

Step 2: Install

Install the app from its listing. New installs get the app's default version (the most recently published one).

Step 3: Set Data Access (only if the app has RLS parameters)

If the app has row-level security parameters, a Set Data Access screen appears before anything else. Choose at least one value per parameter, then click Save & Manage Variant. Full details, including what the values mean and troubleshooting: RLS Parameters.

Note: you will be asked again after every app version upgrade — selections are currently not carried across versions.

Step 4: Map the sources

On the Source Mappings page, point each of the app's required sources at the fully qualified table in Snowflake (DATABASE.SCHEMA.TABLE, case matters — usually ALL CAPS). The defaults are the publisher's own tables; override them if this org's data lives elsewhere.

Two behaviors worth knowing:

  • Mappings survive version upgrades — you set them once per org.

  • If you change a mapping later, the very next run may fail with "does not exist or not authorized" and then succeed on the second run. That is a known sync timing race (CRE-764): the run picks up your new mapping immediately, the permission sync lags about a minute behind. Wait a minute and run again.

Step 5: Check the warehouse

The app's compute warehouse is configured on the app's catalog page / App Connections (NOT the org Connections page, which MTA orgs ignore). If a run fails with "no active warehouse," report it through Contact Us.

Step 6: Run the variant

App Settings > the variant card's more-options menu (⋮) > Run analysis.

Success is silent. The "Running" indicator simply disappears; nothing announces success. Confirm it worked by any of:

  • The app header's "Analysis as of" date updated to today

  • The output tables appear in the Data layer

  • CREATE TABLE statements in Snowflake query history

Only failures are announced (in #ic-app-run-failures). If the app page shows chart errors BEFORE the first successful run, that is expected — output tables don't exist until a run completes.

Upgrading to a new version later

Publishing a new version does not change what any org runs. Each org stays pinned to its installed version until someone clicks Upgrade in the org's Apps page (the row shows an "Update Available" badge).

Two known quirks after upgrading:

  • If the new version added a parameter, the first run may fail with KeyError: '<PARAM>' — the variant's parameter list refreshes only after that first attempt. Run again and it works; the new parameter then appears in the variant's edit screen.

  • If the app has RLS parameters, Set Data Access will re-prompt (see Step 3).

Uninstall / reinstall

Uninstalling does not delete the app's variants. Reinstalling reuses the same variant, with its history, parameter values, and source mappings intact.

Related articles

⏭️ Next: App Context