Declarative Native App manifest reference

A manifest file is a text-based YAML file with the filename: manifest.yml. The manifest file is used to define a Declarative Native App and its associated data and logic. It also defines app roles, which app owners can use to share a subset of the app’s data and features to teams in their organization by role.

Providers create a manifest file as part of a package. This topic describes the structure and fields of the manifest file.

For information about developing an application package, see Application Packages in Declarative Sharing in the Native Application Framework.

Declarative Native App manifest

The general format of a Declarative Native App manifest is:

manifest_version:    # required manifest version; added automatically by Snowflake - do not include
roles:               # optional app roles referenced by shared objects
shared_content:      # required shared data and logic (databases, schemas, and objects)
application_content: # optional app logic (for example, notebooks) shared by the app

Manifest fields

Declarative Native App manifests include the following fields. Each section describes a field’s purpose, structure, and an example.

manifest_version field

The manifest_version field (Integer, required) specifies the version number of the manifest file. This field is added automatically to the manifest file when you release a new version of an application package.

Don’t include this field when creating a manifest file to include in an application package. Editing this field manually is not supported.

For more information about versioning, see Package Versions in Declarative Sharing in the Native Application Framework.

roles field

The roles field (list, optional) defines a list of app roles. These roles let app owners to provide access to shared objects in an app — such as schemas, tables, views, and notebooks — to their organization.

Each named role can optionally contain a comment, which appears as a description when the app owner lists the roles in the application.

These roles are referenced in the manifest by shared objects at the named notebook, schema, table, view, semantic_view, and cortex_agent level. For objects in shared_content (schemas, tables, views, semantic views, functions, procedures, and Cortex Agents), the roles you assign must be defined in the top-level roles list and must be a subset of the roles assigned to the parent schema (either directly on the schema or inherited from the database). For notebooks in application_content, the roles must be defined in the top-level roles list but are not tied to a shared schema.

Note

  • All content in the manifest is accessible to the app owner, the ACCOUNTADMIN, and to roles that are granted IMPORTED PRIVILEGES to the app.
  • The object name defined in this manifest file is used for the runtime object resolution. If the provider changes the object name without updating the manifest file with a new version, consumers will lose access to the object.

roles field example

roles:
  - SALES
  - MARKETING

shared_content:
  databases:
    - SALES:
        schemas:
          - ORDERS:
              roles: [SALES, MARKETING]
              tables:
                - JANUARY_2025:      # App owners/assignees only
                - FEBRUARY_2025:
                    roles: [SALES]   # Accessible to SALES only
                - MARCH_2025:
                    roles: [MARKETING]  # Accessible to MARKETING only
    - CUSTOMER_INFO:
        schemas:
          - CUSTOMER_CONTACT:
              roles: [CUSTOMER_SUPPORT]
              views:
                - CUSTOMER_ADDRESS:
                    roles: [CUSTOMER_SUPPORT]  # Accessible to CUSTOMER_SUPPORT
                - CUSTOMER_DETAILS:
                    roles: []                  # App owners/assignees only

application_content:
  notebooks:
    - SALESBOOK:
        roles: [SALES, MARKETING]
        main_file: NOTEBOOK1.ipynb
        comment: Sales and marketing notebook

For more information about roles, see app roles.

shared_content field

The shared_content field (list, required) defines a list of databases declaratively shared by the app. Each database includes a list of named schemas. Each schema can include a list of named entities grouped by type.

This field includes a single databases field and an optional required_databases field:

  • shared_content.databases (List, required): A list of named database instances and the underlying objects to share.

shared_content.databases.{named database} field

Each named database supports the following name value pairs:

  • schemas (list, required): A list of schemas within the database.

shared_content.required_databases.{named database} field

The required_databases field (list, optional) defines a list of databases that are dependencies of the shared databases. These databases are referenced by views in the shared databases, but are not shared directly. For more information about managing cross-database dependencies, see Dependency databases: Managing cross-database references.

When your application shares data from multiple databases, you must explicitly list all additional databases that are referenced by objects in your shared content under the required_databases field. This ensures that the application can be deployed successfully in other regions where these databases may not exist by default.

Including a database in the required_databases field is similar to referencing a database using the REFERENCE_USAGE privilege in traditional Secure Data Sharing. For information about the REFERENCE_USAGE privilege and how dependent databases are shared in traditional data sharing, see Share data from multiple databases.

schemas.{named schema} field

Each named schema supports the following name value pairs:

Important

You must enforce schema separation between data objects (objects shared by reference: tables, views, and semantic_views) and logic objects (objects shared by copy: functions, procedures, and cortex_agents). You can’t mix data and logic objects in the same schema.

tables.{named table} field

Each named standard table, dynamic table, and Apache Iceberg table (List, required [OneOfRequired] ) supports the following name value pair:

Note

Shared dynamic tables and Apache Iceberg tables replicated to remote regions are read-only and do not refresh automatically. Data freshness depends on the replication frequency from the source, and underlying source objects do not need to be replicated. For details, see Replication considerations.

Note

To allow consumers to create streams on this shared object (for change data capture or incremental loading), you must enable CHANGE_TRACKING = TRUE on the source table in your provider account using standard SQL commands (for example, ALTER TABLE ... SET CHANGE_TRACKING = TRUE). This setting can’t be changed by the consumer on the shared object; it must be set on the source.

views.{named view} field

Each named view (List, required [OneOfRequired] ): supports the following name value pair:

Note

To allow consumers to create streams on this shared object (for change data capture or incremental loading), you must enable CHANGE_TRACKING = TRUE on the source table in your provider account using standard SQL commands (for example, ALTER TABLE ... SET CHANGE_TRACKING = TRUE). This setting can’t be changed by the consumer on the shared object; it must be set on the source.

semantic_views.{named semantic view} field

Each named semantic view (List, required [OneOfRequired] ): supports the following name value pair:

  • roles (list, optional): A list of app roles that can access the semantic view; for example, [SALES]. Note that, when sharing a semantic view, its referenced tables or views must be shared as well. When this field is empty ([]) or omitted, then only app owners and roles with granted IMPORTED PRIVILEGES receive access. The included roles must be defined in the top-level roles field and included in the {named schema}.roles field.

functions.{named function} field

Each named function (List, required [OneOfRequired] ): supports the following name value pair:

procedures.{named procedure} field

Each named stored procedure (List, required [OneOfRequired] ): supports the following name value pair:

cortex_agents.{named cortex agent} field

Each named Cortex Agent (List, required [OneOfRequired] ): supports the following name value pair:

shared_content field example

In this example, two databases are exposed: SALES and CUSTOMER_INFO. Within these databases the ORDERS.[JANUARY_2025|FEBRUARY_2025] tables are exposed as well as the CUSTOMER_CONTACT.CUSTOMER_ADDRESS view.

Two required databases are also exposed: SALES_PROJECTIONS and CUSTOMER_ANALYTICS. These databases can be referenced by views in the shared databases, but are not shared directly.

roles:
  - SALES
  - MARKETING
  - CUSTOMER_SUPPORT

shared_content:
  required_databases:
    - SALES_PROJECTIONS
    - CUSTOMER_ANALYTICS

  databases:
    - SALES:
        schemas:
          - ORDERS:
              roles: [SALES, MARKETING]
              tables:
                - JANUARY_2025:      # App owners/assignees only
                - FEBRUARY_2025:
                    roles: [SALES]   # Accessible to SALES only
                - MARCH_2025:
                    roles: [MARKETING]  # Accessible to MARKETING only

    - CUSTOMER_INFO:
        schemas:
          - CUSTOMER_CONTACT:
              roles: [CUSTOMER_SUPPORT]
              views:
                - CUSTOMER_ADDRESS:
                    roles: [CUSTOMER_SUPPORT]  # Accessible to CUSTOMER_SUPPORT
                - CUSTOMER_DETAILS:
                    roles: []                  # App owners/assignees only

application_content field

The application_content field (list, optional) defines bundled content declaratively shared by the app.

This field includes a single notebooks field:

  • application_content.notebooks (List, required): A list of named notebooks.

application_content.notebooks.{named notebook} field

Each named notebook supports the following name value pairs:

  • main_file (string, required) the path to the interactive Python notebook (.ipynb) file, relative to the root of the package version.
  • comment (string, optional): A comment describing the notebook.
  • runtime_environment_version (string, optional): Specifies a particular runtime environment version for the notebook execution context, if applicable within the platform.
  • roles (list, optional): A list of app roles that can grant access to the notebook, for example, [SALES, MARKETING]. When this field is empty ([]) or omitted, then only app owners and roles with granted IMPORTED PRIVILEGES receive access. The included roles must be defined in the top-level roles field.

Note

The main_file path is always relative to the root of the package version (the snow://package/<DECL_SHARE_APP_PKG>/versions/<version> prefix). For example, if the full path to the notebook file is snow://package/<DECL_SHARE_APP_PKG>/versions/LIVE/NOTEBOOK.ipynb, then specify main_file as just NOTEBOOK.ipynb.

application_content field example

In this example, a single notebook, SALESBOOK, is defined using the notebook file NOTEBOOK1.ipynb which uses the known runtime stable and provides access to those granted either the SALES or MARKETING roles.

roles:
  - SALES
  - MARKETING

application_content:
  notebooks:
    - SALESBOOK:
        roles: [SALES, MARKETING]
        main_file: NOTEBOOK1.ipynb
        comment: Notebook1: Sales and marketing notebook
        runtime_environment_version: stable

Manifest file example

The following code block is an example of a Declarative Native App manifest file.

Note that data and code objects must be in different schemas.

manifest_version: 2

roles:
  - VIEWER:
      comment: "Can view summary data and dashboards."
  - ANALYST:
      comment: "Can query detailed tables, views, and semantic views."
  - APP_USER:
      comment: "Can run in-app agents."

shared_content:
  required_databases:
    - REF_DATA_DB

  databases:
    - POPULATION_APP_DB:
        schemas:
          - DATA_SCHEMA:
              roles: [VIEWER, ANALYST, APP_USER]

              tables:
                - COUNTRY_POP_BY_YEAR:
                    roles: [ANALYST]
                - POPULATION_DYNAMIC_TABLE:
                    roles: [ANALYST]
                - MANAGED_POPULATION_ICEBERG_TABLE:
                    roles: [ANALYST]

              views:
                - COUNTRY_POP_BY_YEAR_2000:
                    roles: [VIEWER, ANALYST]

              semantic_views:
                - POPULATION_METRICS_SEMANTIC_VIEW:
                    roles: [ANALYST]

          - LOGIC_SCHEMA:
              roles: [ANALYST]

              functions:
                - POPULATION_ANALYSIS_FUNCTION(NUMBER):
                    roles: [ANALYST]

              procedures:
                - POPULATION_ANALYSIS_PROCEDURE():
                    roles: [ANALYST]

          - AGENT_SCHEMA:
              roles: [APP_USER]

              cortex_agents:
                - POPULATION_ASSISTANT_AGENT:
                    roles: [APP_USER]

application_content:
  notebooks:
    - intro_notebook:
        roles: [VIEWER, ANALYST]
        main_file: INTRO_NB.ipynb
        comment: "Read-only overview of shared population data."
        runtime_environment_version: stable

    - analyst_notebook:
        roles: [ANALYST]
        main_file: ANALYST_NB.ipynb
        comment: "Analysis notebook for detailed population metrics."
        runtime_environment_version: stable