Installing Snowflake Native Apps: Privileges, Listings, Grants and Instances

1.Check privileges before anyone clicks Get

Every installation runs CREATE APPLICATION, so the role that does the install needs the privileges for that command. On the consumer side, the role must be ACCOUNTADMIN or another role that holds both IMPORT SHARE and CREATE APPLICATION. A paid listing adds one more requirement: the role also needs PURCHASE DATA EXCHANGE LISTING, and the account has to meet some additional criteria. Plan this before the install starts, because a role that is missing a privilege stops the flow before any app object exists.

Providers also install apps, either to test them or to run them in their own account. They don't install from a listing. They create the app directly from the application package in the same account. For that, the role needs the account-level CREATE APPLICATION privilege plus the object-level INSTALL privilege on the package. The role that created the package can already do this by default. If other roles need to build and test apps from the package, grant them the DEVELOP privilege on it.

The provider account has its own prerequisites for a consumer install to work. A consumer can only install after the provider has published a listing that contains the application package as its data product, and that listing can be a Snowflake Marketplace listing or a private listing. Before an app is shared with consumers outside the provider's organization, it must pass an automated security scan. If the provider wants the events a consumer shares, the provider also needs an event account with an active event table in the region where the app is installed. Without one, the shared events from that region are dropped, although the consumer's own event table still captures them locally.

GRANT CREATE APPLICATION ON ACCOUNT TO ROLE provider_role;
GRANT INSTALL ON APPLICATION PACKAGE hello_snowflake_package
  TO ROLE provider_role;

Sources12345

2.Installing from a listing compared with installing from a package

Consumers install from a listing, and the Snowflake Marketplace is the main way to find one. Some providers share private listings directly with specific accounts instead. The install steps are the same either way. The difference is that a private listing may not have been through the same Marketplace-level review as a public one, so the consumer should evaluate it with equal care.

In Snowsight, Marketplace listings are under Marketplace » Snowflake Marketplace. Private listings appear under Catalog » Apps, in Recently shared with you. In both flows, the consumer reviews the app's security requests before installing. These cover account-level privileges, privileges on objects, role grants for the SNOWFLAKE database, and events and logs. A monetized app shows Buy where a free app shows Get. If a provider publishes more than one version, the consumer can choose a release channel. Default is the reviewed production version. Alpha builds may not have passed the security review. QA builds have not been reviewed or tested at all.

Cross-account installs are how providers test the real consumer experience. A provider creates a private listing, shares it with another account in their organization, signs in to that account, and runs the consumer install steps there. An install from the application package always happens in the same account as the package, so it can't show you what a consumer in a different account will see.

Sources12

3.How the app gets privileges and object access during installation

A simple app creates everything it needs inside its APPLICATION object when the setup script runs, and the consumer doesn't have to grant anything. More complex apps need to create objects, or reach objects, outside that boundary. The framework provides several ways to handle this.

At install time the app shows its Category 1 privilege requests, which are the operational resources it needs to create. If the consumer agrees and continues, those privileges are granted automatically. Apps that set manifest_version: 2 use automated granting of privileges. By installing such an app, the consumer also agrees that these privileges can be granted during later upgrades without asking again. Consumers who want to limit what an app can create can use feature policies.

The privileges that automated granting supports are EXECUTE TASK, EXECUTE MANAGED TASK, CREATE WAREHOUSE, CREATE COMPUTE POOL, BIND SERVICE ENDPOINT, CREATE DATABASE, CREATE EXTERNAL ACCESS INTEGRATION, CREATE SECURITY INTEGRATION, CREATE SHARE and CREATE LISTING. Some privileges are not granted automatically, and the consumer must grant them manually when installing or upgrading. Examples are MANAGE WAREHOUSES, IMPORTED PRIVILEGES ON SNOWFLAKE DB, READ SESSION and EXECUTE ALERT.

Other privileges, and access to existing consumer objects, go through one of two paths. The path depends on whether the provider built a UI with the Python Permission SDK.

References run from the app to objects in the consumer account. The provider declares them in the manifest file, and the consumer binds each one to a real object after installation. Because references use logical names, the provider never needs to know the consumer's database or schema names.

Provider data is the opposite direction. The installed app must be able to reach that data from the consumer account, and objects outside the application package can't be shared with it directly. The provider grants REFERENCE_USAGE on the external database to the package, creates a view inside the package that reads from it, and grants USAGE and SELECT on that schema and view to the share. Before an app can use an external table or Iceberg table from the provider account, the consumer must also allow it.

On connectivity, the Security tab of a private listing lists the Connections the app requests. Connecting to an external endpoint takes two things. The CREATE EXTERNAL ACCESS INTEGRATION and CREATE SECURITY INTEGRATION privileges let the app create the integration objects it needs. The consumer must also approve the app specification that allows the app to connect to external hosts. If the consumer does not approve it, the external connection stays disabled. The sources provided don't describe any further network setup between provider and consumer accounts.

GRANT REFERENCE_USAGE ON DATABASE other_db
  TO SHARE IN APPLICATION PACKAGE app_pkg;

Sources678910

4.Running several instances of one app

A provider can configure an app so that a consumer can install it more than once. Once the first install is done, from either a private listing or the Marketplace, the consumer opens the app under Catalog » Apps and selects Add instance. They name the instance, choose a warehouse, and select Get, and Snowflake emails the app admin. After installing an instance, the consumer can set up event tracing for the app, configure its privileges, and do other management tasks.

There are three limits. Add instance appears only if the provider has turned the feature on. An account can have at most 30 instances of the app. Apps installed from a trial listing or a monetized listing can't have multiple instances at all.

Sources1

5.Troubleshooting installation failures

Most installation problems come from a prerequisite that wasn't met. Apps with containers install the same way, but the account must have Snowpark Container Services enabled. If the app requested CREATE COMPUTE POOL it may create its own compute pool, and that pool can't be shared with other apps or with the consumer's own workloads. If the install screen shows a privilege or App Spec nobody mentioned during procurement, stop and ask the provider before continuing. Some failures can only be fixed by the provider. For example, if the setup script fails because of something retrying can't fix, such as a syntax error, the documentation says the fix comes when the app is upgraded to a new version or patch.

The setup script can run more than once during installation and upgrade. That is why Snowflake recommends CREATE OR REPLACE or CREATE IF NOT EXISTS for objects it creates, since after an error those objects might already exist. CREATE OR REPLACE on a procedure also removes the privileges previously granted on it. If the script then fails, consumers can lose access to that procedure until the provider ships a fix.

To see why an install failed, run DESCRIBE APPLICATION. An upgrade_state of INSTALL_FAILED means the application object could not be created, and the UPGRADE_FAILURE_REASON column gives the reason. The object stays in that state until it is dropped. An upgrade_failure_type of VERSION_SETUP means the setup script itself had an error, such as a syntax error.

One error a consumer may see during install is about tags or policies in a versioned schema. It says that a tag in a versioned schema can only be assigned to objects in the same schema, and the same applies to policies. The provider has to fix the setup script, so the consumer should ask the provider to update it. The consumer should also not assign a tag or policy from a versioned schema to objects in their account.

Sources61112

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Any app can be installed up to 30 times in the same account.Why is that wrong?

   The provider must turn on multiple instances, and apps from trial or monetized listings can never have more than one instance.

   Covered in Running several instances of one app

2. 2.A provider can share a table from any of its databases with the installed app by granting it to the package.Why is that wrong?

   Objects outside the package can't be shared directly. The provider grants REFERENCE_USAGE on the database and exposes the data through a view inside the package.

   Covered in How the app gets privileges and object access during installation

3. 3.A private listing has passed the same review as a public Marketplace listing, so it needs less scrutiny.Why is that wrong?

   Private listings may skip Marketplace-level review, so consumers should evaluate them just as carefully.

   Covered in Installing from a listing compared with installing from a package