Declarative Native App manifest reference¶
Providers create a manifest file as part of a package.
The manifest file is a text-based YAML (https://yaml.org/spec/) file, with the filename: manifest.yml
. It’s used to declaratively share data with consumers, such as notebooks, tables, and views.
The manifest file 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 teams by role.
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 contains:
manifest_version: # Added automatically. Don't include.
application_content: # Optional, describes associated app logic
roles: # Optional, describes roles associated with shared_content
shared_content: # Required, describes associated data to be shared
Fields¶
Declarative Native App manifests include the following fields:
manifest_version
field¶
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.
The manifest_version
top level field (Integer, required) specifies the version
number of the manifest file.
For more information about versioning, see Package Versions in Declarative Sharing in the Native Application Framework.
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 name of the interactive Python notebook (.ipynb) file.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 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.
application_context
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.
application_content:
notebooks:
- salesbook:
roles: [sales, marketing]
main_file: NOTEBOOK1.ipynb
comment: Notebook1: Sales and marketing notebook
runtime_environment_version: stable
roles:
- sales:
- marketing:
roles
field¶
The roles
top level field (list, optional) defines a list of app roles. These roles allow 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
, or view
level. For objects at the table
or view
level, roles must also be specified at the schema
level.
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
example¶
roles:
- sales:
- marketing:
application_content:
notebooks:
- salesbook:
roles: [sales, marketing]
main_file: NOTEBOOK1.ipynb
comment: Sales and marketing notebook
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
For more information about roles, see app roles.
Manifest file example¶
The following code block is an example of a Declarative Native App manifest file:
manifest_version: 2
roles:
- VIEWER:
comment: "The VIEWER role provides access to only one view."
- ANALYST:
comment: "The ANALYST role provides access to both views and the table."
shared_content:
databases:
- SNAF_POPULATION_DB:
schemas:
- DATA_SCHEMA:
roles: [VIEWER, ANALYST]
tables:
- COUNTRY_POP_BY_YEAR:
roles: [ANALYST]
views:
- COUNTRY_POP_BY_YEAR_2000:
roles: [VIEWER, ANALYST]
application_content:
notebooks:
- intro_notebook:
roles: [VIEWER, ANALYST]
main_file: INTRO_NB.ipynb
- analyst_notebook:
roles: [ANALYST]
main_file: ANALYST_NB.ipynb