Share content using the manifest in a Snowflake Native App¶

This topic describes how to share provider-side content with consumers by declaring it in the manifest file of a Snowflake Native App. Declaring shared content in the manifest is the recommended way to share content. Use a setup script only for advanced scenarios that must run code in the consumer account.

Recommended: declare shared content in the manifest¶

You share content by adding a shared_content section to the manifest file, using the same syntax as Snowflake Declarative Sharing. The framework handles privilege management, object resolution, and versioning, so you don’t need to write GRANT statements or create proxy views.

When a version or patch declares a shared_content section, authorization for that patch runs entirely through the declarative sharing engine. Grant-based authorization no longer applies to that patch. Code from earlier versions that uses grant-based sharing continues to work and sees only the content granted that way.

How manifest sharing improves on proxy views¶

Grant-based sharing requires a local proxy view in the application package to expose shared content to consumers. Declaring content in the manifest removes that requirement and offers the following advantages:

• No proxy view is required to expose a shared object.
• You can share object types that the grant path can’t share through a proxy view, including semantic views and Cortex Search services.
• Content shared by reference stays on the provider side and is read at query time.

Proxy views in a versioned schema still have one advantage: the view locks the structure of the shared content to the application version, which keeps the application interface stable across versions. There’s no automatic migration path from proxy views to direct sharing. For more information, see Migrate from grant-based sharing to the manifest.

Supported object types¶

You can declare the following object types in the shared_content section of the manifest:

• Regular tables
• Dynamic tables
• Secure views
• Semantic views
• Cortex Search services

For the full manifest syntax and field semantics, see the Manifest file reference.

Choose between the manifest and a setup script¶

Both the manifest and the setup script can add content to an app. Choose based on what the object needs to do, not preference.

• Declare it in the manifest when the object operates on provider-side content that consumers read at query time, such as tables, views, secure views, semantic views, and Cortex Search services. This is the default and the common case.
• Use a setup script when the object has to be built inside the app environment in the consumer’s account, such as Snowpark Container Services, stored procedures that use external access integrations, or logic that needs consumer-side tooling.

The following table summarizes the choice:

A single patch uses one authorization model. If a patch declares a shared_content section, all of its shared content is authorized through the declarative engine. You can still include a setup script in the same patch for the advanced cases above.

Scenarios¶

• Ship non-grantable content alongside an app. A provider wants to share notebooks, workspace content, and compliance documents with their app. These object types can’t be shared through the grant path, so the provider declares them in the manifest instead of recreating them in a setup script.
• Share a governed service by reference. A provider shares a PII-protected Cortex Search service so consumers query it by reference while the data stays on the provider side. The provider declares the service in the manifest.
• Read consumer data and write results back. A provider’s functions read the consumer’s data, combine it with provider data, and persist results in the consumer’s account. Because this runs code in the consumer’s account, the provider builds that logic in a setup script and shares the provider-side reference data through the manifest.
• Call an external API from shared logic. A provider’s shared analytics logic fetches data from a third-party API. The provider builds that logic in a setup script with an external access integration and declares any provider-side reference content in the manifest.