Declarative Sharing in Native Apps: Limitations¶

Declarative sharing is a feature in Snowflake Native Apps that allows providers to quickly define and share objects across multiple databases using a simple YAML configuration file. While this feature significantly simplifies data sharing workflows, it has limitations that providers should understand before implementation.

Supported Object Types¶

Declarative sharing supports these object types:

Notebooks
Tables, including:
- Dynamic tables
- Apache Iceberg tables
Views, including:
- Semantic views
Stored procedures
User-defined functions (UDFs)
Cortex Agents
Streams

All other object types are not supported for sharing in Declarative Sharing in Native Apps.

Shared Objects¶

Object limit: A maximum of 1,000 objects can be defined in the shared content section of the manifest.yml file. To raise this limit, contact Snowflake Support.
Streams: Requires CHANGE_TRACKING = TRUE to be enabled on the provider’s source object.

Notebook Limitations¶

Read-only for consumers: Consumers can’t edit provider notebooks in place, nor can they clone them.
Network access: Notebooks cannot access external endpoints or consumer data when running in customer accounts.
Specialized libraries: Geospatial and other 3rd party libraries aren’t guaranteed to work out-of-the-box in notebooks.
External dependencies: Declarative Sharing apps have limited support for external libraries (Snowflake Anaconda channel and Python files in code stage.)
Non-interactive execution: Notebooks that are part of native applications cannot be executed non-interactively by worksheets or SQL commands.

Security and Access Control¶

Role definition: All application roles referenced in the shared content must be predefined in the roles field in the manifest.
Object-level roles: Object roles must be subsets of their parent schema roles.
Missing role validation: Validating the manifest returns an error if roles referenced in the sharing configuration don’t exist.
Minimum privileges: The provider role committing the shared_content.yaml file must have at least the same privileges on shared objects as those being granted to consumers.
No REFERENCE_USAGE required: Unlike traditional data sharing, providers don’t need to grant REFERENCE_USAGE privileges to the application package.

Migration & Compatibility¶

Declarative Sharing migration: Migration support for switching from data shares to Declarative Sharing in the Native App framework is unavailable.

Naming and Configuration Constraints¶

No wildcards: Object names must be explicitly specified; wildcard or regular expression matching is not supported.
Name collision prevention: No two shared objects can have the same DOMAIN and name.
Schema mapping: Schema mapping is not supported. Overlapping schema names from multiple databases are not allowed.
Schemas for data objects and logic objects: You must use separate schemas for data objects (shared by reference: tables and views) and logic objects (shared by copy: UDFs, stored procedures, Cortex Agents). For example, you can use a schema named DATA_SCHEMA for tables and views, and a schema named LOGIC_SCHEMA for UDFs.

Monitoring¶

Auditability: Declarative Native Apps don’t provide monitoring resources (such as audit trails) to let the provider receive information from the consumer about how the shared data is being used. If a consumer has compliance or regulatory requirements that require auditing, the consumer must work with the provider to implement their own monitoring solutions.

Cortex Agents¶

Execution Environment: When creating a Cortex Agent for sharing that uses Cortex Analyst and semantic views, you must explicitly define the execution_environment with an empty string for the warehouse (warehouse: ""). You can’t omit this field, nor can you specify a specific warehouse name.
Tools: All tools must be in the same database as the Agent. While procedures and UDFs are shared by copy and may be in the same schema as the Agent, semantic views and Cortex Search-based tools must be in a different schema.