Snowflake Data Clean Rooms Collaboration API¶

Introduction¶

This is the reference page for the Snowflake Data Clean Rooms Collaboration API. This API uses the COLLABORATION and REGISTRY schemas.

Note

You should disable secondary roles in your environment when using the Collaboration API:

USE SECONDARY ROLES NONE;

To learn how to set up your development environment, see Setting up your environment.

To learn how to manage access to the Collaboration API procedures, see Use DCR privileges to manage account, object, and procedure privileges.

Metadata cheat sheet¶

Here is how to find some commonly sought information about a collaboration:


To learn this…	Call this
What collaborations can I join?	VIEW_COLLABORATIONS - Look for collaborations where the `collaboration_name` column is NULL.
Which collaborations have I joined?	VIEW_COLLABORATIONS - Look for collaborations where the `collaboration_name` column is not NULL, which can mean either that you have created or joined the collaboration.
Which collaborations do I own?	VIEW_COLLABORATIONS - Look in the `owner_account` column.
What is the status of all collaborators in a collaboration?	GET_STATUS
What is my join or creation status in a collaboration?	GET_STATUS or VIEW_COLLABORATIONS
Who owns a given collaboration?	GET_STATUS - Look for OWNER in the `roles` column.
What is my collaboration role in a given collaboration?	GET_STATUS - Look in the `roles` column.
What collaboration roles are assigned in a given collaboration?	GET_STATUS - Look in the `roles` column.
What is the spec in a given collaboration?	VIEW_COLLABORATIONS - Look in the `collaboration_spec` column.
Is the spec up to date?	There is no way to tell if a given spec has changes in progress, but you can call VIEW_COLLABORATIONS to see when the latest updates were applied.
What pending update requests do I have?	`VIEW_UPDATE_REQUESTS`. Look for rows where STATUS = PENDING_MY_APPROVAL.
Show me the spec for a given collaboration	REVIEW returns the collaboration spec. If you have already called REVIEW or joined the collaboration, call the following SQL command with your collaboration name as indicated: CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION. VIEW_COLLABORATIONS() ->> SELECT "COLLABORATION_SPEC" FROM $1 WHERE "SOURCE_NAME" = <collaboration name>;

Template procedures¶

REGISTER_TEMPLATE¶

Schema:: REGISTRY

Registers a template to enable it to be used in a collaboration. Every template registered must have a unique name-version combination for all templates in all registries in your account.

Syntax¶

REGISTER_TEMPLATE( ['<registry_name>' ,] <template_spec> )

Arguments¶

registry_name (Optional): Name of a custom registry in which to register this template. If not specified, registers the template in the default account registry.
template_spec: Template definition in YAML format, as a string.

Returns¶

A template ID to use in the collaboration specification.

Examples¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.REGISTRY.REGISTER_TEMPLATE(
  $$
  api_version: 2.0.0
  spec_type: template
  name: my_test_template
  version: 2026_01_12_V1
  type: sql_analysis
  description: A test template
  template:
    SELECT * FROM IDENTIFIER({{ source_table[0] }}) LIMIT 10;
$$);

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.REGISTRY.REGISTER_TEMPLATE(
  'my_custom_registry',
  $$
  api_version: 2.0.0
  spec_type: template
  name: my_test_template
  version: 2026_01_12_V1
  type: sql_analysis
  description: A test template
  template:
    SELECT * FROM IDENTIFIER({{ source_table[0] }}) LIMIT 10;
$$);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling the following procedures.

To register objects in the default registry:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('REGISTER TEMPLATE', 'role name')

To register items in a custom registry:

You have read and write privileges on any custom registry that you created yourself.
To access a custom registry created by another user, you need GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('REGISTER', 'REGISTRY', 'MY_REGISTRY', 'role name').

VIEW_REGISTERED_TEMPLATES¶

Schema:: REGISTRY

Lists all templates that you have registered. To register a template, call REGISTRY.REGISTER_TEMPLATE.

Syntax¶

VIEW_REGISTERED_TEMPLATES( [ '<registry_name>' ] )

Arguments¶

registry_name (Optional): Name of a custom registry to list templates from. If not specified, lists templates from the default account registry.

Returns¶

A table that lists the details of all templates that you have registered in this account. The table includes the following columns:

TEMPLATE_ID: ID of the template.
NAME: Template name.
VERSION: Template version.
TEMPLATE_SPEC: Full YAML specification of the template.
REGISTRY: Registry the template is registered in.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.REGISTRY.VIEW_REGISTERED_TEMPLATES();

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures.

To see items in the default registry:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('VIEW REGISTERED TEMPLATES', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

To see items in a custom registry:

You have read and write privileges on any custom registry that you created yourself.
To access a custom registry created by another user, you need GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('READ', 'REGISTRY', 'MY_REGISTRY', 'role name').

ADD_TEMPLATE_REQUEST¶

Schema:: COLLABORATION

Sends a request to link a template to an existing collaboration. If the sender is affected by the request, the sender automatically approves the request; all other affected collaborators must approve the request for the change to be applied. All collaborators need to call this procedure to link a template to an existing collaboration, even the collaboration owner.

To add additional template sharers, you can call this procedure again with their aliases. Each call adds the users listed in share_with to the existing list of sharers.

To see the status of the request, call VIEW_UPDATE_REQUESTS.

See the link template flow.

Syntax¶

ADD_TEMPLATE_REQUEST( <collaboration_name>, <template_id>, <share_with> )

Arguments¶

collaboration_name: Name of the collaboration to link the template to.
template_id: ID of the template to link to the collaboration. Register the template to get this value.
share_with: Array of aliases of analysis runners to share this template with. Collaborators listed here will be added in addition to any other collaborators associated with this template. All collaborators listed here must be analysis runners or the procedure will fail without sharing this template with anyone.

Returns¶

A string success message.

Example¶

-- Ask to link the template only for Collaborator3 in this collaboration.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.ADD_TEMPLATE_REQUEST(
  $collaboration_name,
  $template_alias,
  ['Collaborator3']
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('UPDATE', 'COLLABORATION', 'collaboration name', 'role name')
Either of the following privileges:
- GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name'), plus all additional account-level privileges that must be manually granted to the role.
- GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name'), plus all additional account-level privileges that must be manually granted to the role.
If the template is in a custom registry, you must also have GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE( 'READ', 'registry name', 'role name')

REMOVE_TEMPLATE¶

Schema:: COLLABORATION

Asynchronous request to remove a template from a given collaboration for specified collaborators. Only the collaborator that registered the template can remove a template. No approval is needed from anyone else to remove a template that you have registered. When a template is removed for a collaborator, that collaborator can’t see or use the template.

Syntax¶

REMOVE_TEMPLATE( <collaboration_name>, <template_id>, <remove_for> )

Arguments¶

collaboration_name: Name of the collaboration to remove the template from.
template_id: ID of the template to remove from the collaboration.
remove_for: Array of one or more aliases of analysis runners in this collaboration that should no longer be able to see or use this template.

Returns¶

A string success message. To see if a template has been removed for a collaborator, view the collaboration specification.

Example¶

-- Prevent collaborator_1234 from using the specified template
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.REMOVE_TEMPLATE(
  $collaboration_name,
  $template_id,
  ['collaborator_1234']
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('UPDATE', 'COLLABORATION', 'collaboration name', 'role name')
Either of the following privileges:
- GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name'), plus all additional account-level privileges that must be manually granted to the role.
- GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name'), plus all additional account-level privileges that must be manually granted to the role.
If the template is in a custom registry, or references a code spec in a custom registry, you must also have GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE( 'READ', 'registry name', 'role name')

VIEW_TEMPLATES¶

Schema:: COLLABORATION

Shows all templates that you can run, or that you have submitted, to the specified collaboration.

Syntax¶

VIEW_TEMPLATES( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration. You must review or join this collaboration before you can list its templates.

Returns¶

A table that lists information about templates that you can run in this collaboration, including templates that you have registered. The table includes the following columns:

template_id: The template ID. Pass this into the template field or template_id parameter of your RUN command.
template_spec: The template specification for this template, which includes the full JinjaSQL for this template.
parameters: A description of all the arguments accepted by this template, in JSON format. The information about each parameter includes the name, default value, template-provider-written description, and whether it is required. Pass values for these parameters into your RUN command.
shared_by: The collaborator that registered this template.
shared_with: The collaborators that this template is shared with.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.VIEW_TEMPLATES(
  $collaboration_name
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('VIEW TEMPLATES', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('READ', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

ENABLE_TEMPLATE_AUTO_APPROVAL¶

Schema:: COLLABORATION

Causes all template update requests sent by other collaborators to be approved automatically. Requests will still appear in the request log. This affects only requests sent after auto-approval was enabled.

Syntax¶

ENABLE_TEMPLATE_AUTO_APPROVAL( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration.

Returns¶

A string success message.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.ENABLE_TEMPLATE_AUTO_APPROVAL(
  $collaboration_name
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('MANAGE TEMPLATE AUTO APPROVAL', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('UPDATE', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

DISABLE_TEMPLATE_AUTO_APPROVAL¶

Schema:: COLLABORATION

Disables automatic approval for template requests raised by other collaborators. All future requests must be approved manually by calling APPROVE_UPDATE_REQUEST.

Syntax¶

DISABLE_TEMPLATE_AUTO_APPROVAL( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration.

Returns¶

A string success message.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.DISABLE_TEMPLATE_AUTO_APPROVAL(
  $collaboration_name
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('MANAGE TEMPLATE AUTO APPROVAL', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('UPDATE', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

Data offering procedures¶

REGISTER_DATA_OFFERING¶

Schema:: REGISTRY

Registers a data offering so that it can be linked to a collaboration definition. You cannot unregister a registered data offering. You can’t overwrite an existing data offering, but you can register a new one with the same name and a new version. Creating a new version of a data offering doesn’t remove any earlier versions.

Every data offering must have a unique name-version combination for all data offerings in all registries in your account.

If you want to share this table with others in the collaboration, include the table in the collaboration specification before the collaboration is created.

You must have the REFERENCE_USAGE privilege with GRANT OPTION on any data that you share in a collaboration. If you do not, you will get a “missing reference usage grant” error when you try to join the collaboration or register the object. Learn how to handle this issue.

Syntax¶

REGISTER_DATA_OFFERING( ['<registry_name>' ,] <data_offering_spec> )

Arguments¶

registry_name (Optional): Name of a custom registry in which to register this data offering. If not specified, registers the data offering in the default account registry.
data_offering_spec: A data offering definition in YAML format that describes this data offering.

Returns¶

The data offering ID to use in a collaboration’s data_offerings.id field.

Examples¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.REGISTRY.REGISTER_DATA_OFFERING(
    $$
    api_version: 2.0.0
    spec_type: data_offering
    version: v1
    name: customers
    datasets:
     - alias: customers_1
       data_object_fqn: SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS
       allowed_analyses: template_only
       schema_and_template_policies:
         hashed_email:
           category: join_custom
         status:
           category: passthrough
    $$
  );

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.REGISTRY.REGISTER_DATA_OFFERING(
    'my_custom_registry',
    $$
    api_version: 2.0.0
    spec_type: data_offering
    version: v1
    name: customers
    datasets:
     - alias: customers_1
       data_object_fqn: SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS
       allowed_analyses: template_only
       schema_and_template_policies:
         hashed_email:
           category: join_custom
         status:
           category: passthrough
    $$
  );

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling the following procedures.

To register a data offering in the default registry:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('REGISTER DATA OFFERING', 'role name')

To register items in a custom registry:

You have read and write privileges on any custom registry that you created yourself.
To access a custom registry created by another user, you need GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('REGISTER', 'REGISTRY', 'MY_REGISTRY', 'role name').

LINK_DATA_OFFERING¶

Schema:: COLLABORATION

A data provider runs this procedure to update an existing collaboration by making the specified data offering available to the specified analysis runners. This is an asynchronous procedure; analysis runners should call VIEW_DATA_OFFERINGS to see when the data offering is available to be used.

This procedure is additive, meaning that the collaborators you specify are added to the existing list of data offering sharers.

If you want to use this table but not make it visible to other collaborators, call LINK_LOCAL_DATA_OFFERING instead of LINK_DATA_OFFERING.

Important

LINK_DATA_OFFERING can currently only be called by the role that created or joined the collaboration.

You cannot have an active secondary role when you run this procedure. Run the following SQL code to disable any secondary roles:

USE SECONDARY ROLES NONE;

This procedure is atomic: all of the following conditions must be met for this procedure to succeed. If the link attempt fails for any one collaborator, it fails for all of them.

All of the specified collaborators must be analysis runners.
This data offering must not already be shared with any of the specified analysis runners.
This procedure can be run only by a user with the data provider collaboration role who has joined the collaboration.

You must have the REFERENCE_USAGE privilege with GRANT OPTION on any data that you wish to share. If you don’t, you’ll get a “missing reference usage grant” error when you try to join the collaboration. Learn how to handle this issue.

Syntax¶

LINK_DATA_OFFERING( <collaboration_name>, <data_offering_id>, <share_with> )

Arguments¶

collaboration_name: Name of the collaboration.
data_offering_id: ID of the dataset to share, generated when it was registered. The data offering must be visible to you when you call VIEW_DATA_OFFERINGS or VIEW_REGISTERED_DATA_OFFERINGS to be able to link it.
share_with: Array of string aliases of analysis runners to share this dataset with. Collaborators listed here will be added in addition to any other collaborators associated with this data offering. All collaborators listed here must be analysis runners that you are a data provider for, or the procedure will fail without sharing data with anyone.

Returns¶

A string success message.

Example¶

This example allows collaborator alice to use the specified data offering in the specified collaboration.

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.LINK_DATA_OFFERING(
  $collaboration_name,
  $my_data_id,
  ['alice']
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name'), plus all additional account-level privileges that must be manually granted to the role.
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name'), plus all additional account-level privileges that must be manually granted to the role.

If the data offering is in a custom registry, you must also have GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE( 'READ', 'registry name', 'role name').

UNLINK_DATA_OFFERING¶

Schema:: COLLABORATION

A data provider runs this procedure to remove access to a data offering from specified analysis runners in an existing collaboration. This is an asynchronous procedure; analysis runners should call VIEW_COLLABORATIONS to confirm the data offering has been removed.

Syntax¶

UNLINK_DATA_OFFERING( <collaboration_name>, <data_offering_id>, <remove_for> )

Arguments¶

collaboration_name: Name of the collaboration.
data_offering_id: ID of the dataset to unlink, generated when it was registered.
remove_for: Array of string aliases of one or more analysis runners to remove access for. All collaborators listed here must be analysis runners that currently have access to this data offering.

Returns¶

A string success message.

Example¶

-- Remove data offering access for specific analysis runners in this collaboration.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.UNLINK_DATA_OFFERING(
  $collaboration_name,
  $data_offering_id,
  ['AnalysisRunner_1', 'AnalysisRunner_2']
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

LINK_LOCAL_DATA_OFFERING¶

Schema:: COLLABORATION

Use this procedure to link your own data into a collaboration if you are using Snowflake Standard Edition. You must first register your data offerings by calling REGISTER_DATA_OFFERING. These offerings will not be visible to any other collaborator, and template policies will not be enforced. Tables submitted here propagate the my_table array in the template.

For more information, see Run an analysis with your own data when you use Standard Edition.

Syntax¶

LINK_LOCAL_DATA_OFFERING( <collaboration_name>, <data_offering_id> )

Arguments¶

collaboration_name: Name of the collaboration.
data_offering_id: ID of the dataset, generated when you registered it. Also visible in VIEW_REGISTERED_DATA_OFFERINGS and VIEW_DATA_OFFERINGS (to you only).

Returns¶

A string success message.

Example¶

This example links a registered data offering for use only by the current account, without exposing it to the rest of the collaborators.

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.LINK_LOCAL_DATA_OFFERING(
  $collaboration_name,
  $my_private_data_offering_id
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('LINK LOCAL DATA OFFERINGS', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('UPDATE', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

UNLINK_LOCAL_DATA_OFFERING¶

Schema:: COLLABORATION

Use this procedure to unlink your own local data from a collaboration. After unlinking, the data offering will no longer be available to use in analyses within this collaboration. For more information about local data offerings, see Run an analysis with your own data when you use Standard Edition.

Syntax¶

UNLINK_LOCAL_DATA_OFFERING( <collaboration_name>, <data_offering_id> )

Arguments¶

collaboration_name: Name of the collaboration.
data_offering_id: ID of the dataset to unlink, generated when you registered it. Also visible in VIEW_REGISTERED_DATA_OFFERINGS and VIEW_DATA_OFFERINGS (to you only).

Returns¶

A string success message.

Example¶

-- Unlink a local data offering from a collaboration.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.UNLINK_LOCAL_DATA_OFFERING(
  $collaboration_name,
  $my_private_data_offering_id
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('UNLINK LOCAL DATA OFFERINGS', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('UPDATE', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

VIEW_REGISTERED_DATA_OFFERINGS¶

Schema:: REGISTRY

Lists all data offerings that you have registered. To view data offerings in a collaboration linked by others, call COLLABORATION.VIEW_DATA_OFFERINGS.

Syntax¶

VIEW_REGISTERED_DATA_OFFERINGS( [ '<registry_name>' ] )

Arguments¶

registry_name (Optional): Name of a custom registry to list data offerings from. If not specified, lists data offerings from the default account registry.

Returns¶

A table that lists the details of all data offerings that you have registered in this account. The table includes the following columns:

DATA_OFFERING_ID: ID of the data offering.
NAME: Data offering name.
VERSION: Data offering version.
DATA_OFFERING_SPEC: Full YAML specification of the data offering.
REGISTRY: Registry the data offering is registered in.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.REGISTRY.VIEW_REGISTERED_DATA_OFFERINGS();

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures.

To see items in the default registry:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('VIEW REGISTERED DATA OFFERINGS', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

To see items in a custom registry:

You have read and write privileges on any custom registry that you created yourself.
To access a custom registry created by another user, you need GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('READ', 'REGISTRY', 'MY_REGISTRY', 'role name').

VIEW_DATA_OFFERINGS¶

Schema:: COLLABORATION

Lists all data offerings present in a specified collaboration that you can access as an analysis runner, or that you have linked yourself. To see only data offerings that you registered, call REGISTRY.VIEW_REGISTERED_DATA_OFFERINGS.

You can see data offerings from collaborator X only after X has joined the collaboration.

Syntax¶

VIEW_DATA_OFFERINGS( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration to explore.

Returns¶

Information about all data offerings in the specified collaboration. The table includes the following columns:

template_view_name: The fully qualified view name used to reference offerings when calling RUN to query using a template. Pass this name into the source_tables field in the RUN spec.
template_join_columns: Names of columns in this table that can be used in joins in template-based queries.
analysis_allowed_columns: Names of columns in this table that can be projected in template-based queries.
activation_allowed_columns: Names of columns in this table that can be activated.
freeform_sql_view_name: The fully qualified view name used in free-form SQL queries, when the dataset supports free-form SQL queries. This cell is empty if the dataset doesn’t offer free-form SQL queries.
freeform_sql_column_policies: A JSON representation of all free-form column policies in this collaboration, keyed by policy type.
shared_by: The collaborator that linked this data offering.
shared_with: Who can use the data in an analysis. If this value is LOCAL, this is a local dataset that isn’t shared with any collaborators except for the party that hosts the data.
data_offering_id: The unique ID of this data offering, generated when it was registered.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.VIEW_DATA_OFFERINGS(
  $collaboration_name
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('VIEW DATA OFFERINGS', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('READ', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

Custom function procedures¶

REGISTER_CODE_SPEC¶

Schema:: REGISTRY

Registers a code bundle. This stores the code in the clean rooms environment in the REGISTRY.CODE_SPECS table. After a code spec is registered, it can be used by a template.

Every code spec registered must have a unique name-version combination across all registries in your account.

Syntax¶

REGISTER_CODE_SPEC( ['<registry_name>' ,] <code_spec> )

Arguments¶

registry_name (Optional): Name of a custom registry in which to register this code spec. If not specified, registers the code bundle in the default account registry.
code_spec: Code bundle spec definition in YAML format, as a string.

Returns¶

The generated code bundle spec ID.

Examples¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.REGISTRY.REGISTER_CODE_SPEC(
  $$
  api_version: 2.0.0
  spec_type: code_spec
  name: custom_udf
  version: v1
  description: Custom UDF for data normalization

  functions:
    - name: normalize_value
      type: UDF
      language: PYTHON
      runtime_version: "3.10"
      handler: normalize
      arguments:
        - name: value
          type: FLOAT
        - name: min_val
          type: FLOAT
        - name: max_val
          type: FLOAT
      returns: FLOAT
      code_body: |
        def normalize(value, min_val, max_val):
            if max_val == min_val:
                return 0.0
            return (value - min_val) / (max_val - min_val)
  $$
);

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.REGISTRY.REGISTER_CODE_SPEC(
  'my_custom_registry',
  $$
  api_version: 2.0.0
  spec_type: code_spec
  name: custom_udf
  version: v1
  description: Custom UDF for data normalization

  functions:
    - name: normalize_value
      type: UDF
      language: PYTHON
      runtime_version: "3.10"
      handler: normalize
      arguments:
        - name: value
          type: FLOAT
        - name: min_val
          type: FLOAT
        - name: max_val
          type: FLOAT
      returns: FLOAT
      code_body: |
        def normalize(value, min_val, max_val):
            if max_val == min_val:
                return 0.0
            return (value - min_val) / (max_val - min_val)
  $$
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling the following procedures.

To register objects in the default registry:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('REGISTER CODE SPEC', 'role name')

To register items in a custom registry:

You have read and write privileges on any custom registry that you created yourself.
To access a custom registry created by another user, you need GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('REGISTER', 'REGISTRY', 'MY_REGISTRY', 'role name').

VIEW_REGISTERED_CODE_SPECS¶

Schema:: REGISTRY

Lists all code bundle specs registered by this role in the local account registry.

Syntax¶

VIEW_REGISTERED_CODE_SPECS( [ '<registry_name>' ] )

Arguments¶

registry_name (Optional): Name of a custom registry to list code bundles from. If not specified, lists code bundles from the default account registry.

Returns¶

A table that lists the details of all code bundles that you have registered in this account. The table includes the following columns:

code_spec_id: ID of the code bundle spec.
name: Code bundle spec name.
version: Code bundle spec version.
code_spec: Full YAML specification of the code bundle spec.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.REGISTRY.VIEW_REGISTERED_CODE_SPECS();

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures.

To see items in the default registry:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('VIEW REGISTERED CODE SPECS', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

To see items in a custom registry:

You have read and write privileges on any custom registry that you created yourself.
To access a custom registry created by another user, you need GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('READ', 'REGISTRY', 'MY_REGISTRY', 'role name').

VIEW_CODE_SPECS¶

Schema:: COLLABORATION

Returns all code bundle specs that are referenced by any template that you created or can run in the specified collaboration.

Syntax¶

VIEW_CODE_SPECS( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration.

Returns¶

A table that lists the code bundles available in the specified collaboration. The table includes the following columns:

code_spec_id: ID of this code bundle spec.
code_spec: Full YAML specification of the code bundle spec.
shared_by: Collaborator alias that shared the code bundle spec.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.VIEW_CODE_SPECS(
  $collaboration_id
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('VIEW CODE SPECS', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('READ', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

Update request procedures¶

These procedures are used to manage collaboration update requests that require approval, such as the link template flow.

VIEW_UPDATE_REQUESTS¶

Schema:: COLLABORATION

See all update requests that you have created or that you can approve or deny, in the specified collaboration. This includes all collaboration changes such as adding data offerings, templates, and code packages. This procedure shows the status of the update. It can take a few seconds for an update request to appear in the request list, so you might not see a request that you just sent a moment ago.

See the link template flow.

Syntax¶

VIEW_UPDATE_REQUESTS( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration.

Returns¶

A table of update requests sent in this collaboration. Information includes

id: ID of the request. Use this to approve or deny a request.
type: Type of request. The following values are supported:
- Add Template
- Link Data Offering
- Unlink Data Offering
- Remove Template
status: Current status of the request. The following statuses can be reported:
- REQUESTED: The request has been submitted.
- PENDING_MY_APPROVAL: The request is awaiting your approval or rejection.
- PENDING_PARTNER_APPROVAL: You have approved the request, but the request still needs to be approved by one or more other collaborators.
- REJECTED: Someone in the collaboration rejected this request.
- APPROVED: All required approvers have approved the request.
- COMPLETED: The update action has been completed and changes applied to the collaboration. For templates that include a code bundle, you should still check the upgrade state to see when the code bundle is ready to be called.
- FAILED: The update action has failed. See the DETAILS column for failure details.
approval_log: Log of all approvals and rejections of the request. If the request is rejected, the reason given by the rejecting party is also provided here.
details: Details specific to the request type, such as the template name, description, and whom it is shared with for an ‘Add Template’ request.
spec: The details of the resource being updated, such as template specification for an ‘Add Template’ request.
updated_on: The timestamp when the last action was taken on this request (for example, an approval or rejection).

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.VIEW_UPDATE_REQUESTS(
  $collaboration_name
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('VIEW UPDATE REQUESTS', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('UPDATE', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('READ', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

APPROVE_UPDATE_REQUEST¶

Schema:: COLLABORATION

Approves a collaboration update request. See your list of pending requests by calling VIEW_UPDATE_REQUESTS. Once you approve a request, you cannot reject it later.

All affected collaborators must approve a request before the change is actually applied to the collaboration.

See the link template flow.

Syntax¶

APPROVE_UPDATE_REQUEST( <collaboration_name>, <request_id> )

Arguments¶

collaboration_name: Name of the collaboration.
request_id: ID of the request.

Returns¶

A string success message.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.APPROVE_UPDATE_REQUEST(
  $collaboration_name,
  $request_id
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('MANAGE UPDATE REQUEST', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('UPDATE', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

REJECT_UPDATE_REQUEST¶

Schema:: COLLABORATION

Rejects a collaboration update request. A single rejection prevents the change from being applied to the collaboration. You cannot approve a request after rejecting it.

Syntax¶

REJECT_UPDATE_REQUEST( <collaboration_name>, <request_id>, <reason> )

Arguments¶

collaboration_name: Name of the collaboration.
request_id: ID of the request.
reason: A human-readable description of why the request was rejected. The argument is required, but you can submit an empty string.

Returns¶

A string success message.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.REJECT_UPDATE_REQUEST(
  $collaboration_name,
  'request_1324f934457',
  'Needs more cowbell'
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('MANAGE UPDATE REQUEST', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('UPDATE', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

Collaboration management procedures¶

INITIALIZE¶

Schema:: COLLABORATION

The owner calls this to create a collaboration and, optionally, join the collaboration. If auto_join_warehouse is FALSE, you must call JOIN separately to make the collaboration available to other collaborators. You must use the same role to call INITIALIZE and then JOIN.

Submitting a collaboration definition with the same name value as an existing collaboration throws an error.

It takes some time to create and join a collaboration, so you must call GET_STATUS to learn when the collaboration has been joined.

Syntax¶

INITIALIZE( <collaboration_spec> [, '<auto_join_warehouse>'] )

Arguments¶

collaboration_spec: Collaboration definition in YAML format, as a string.
auto_join_warehouse (Optional): String that specifies a warehouse name as a valid Snowflake identifier. If specified, the collaboration will be created and joined using this warehouse. If not specified, the current warehouse will be used to create the collaboration, and you must call JOIN to join the collaboration. An XS warehouse is recommended.

Returns¶

A table with the following columns:

collaboration_name: The name of the collaboration. Use this in any procedures that require you to specify a collaboration.
message: Information about the initialize request.
auto_join_task: If auto_join_warehouse was specified, indicates whether the auto-join task was created.

Examples¶

The following example creates a collaboration where Alice is the owner and can run an analysis using data provided by Bob.

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.INITIALIZE(
  $$
  api_version: 2.0.0
  spec_type: collaboration
  name: basic_collaboration
  owner: alice
  collaborator_identifier_aliases:
    alice: corp_id.account_id
    bob: corp2_id.account2_id
  analysis_runners:
    alice:
      data_providers:
        bob:
          data_offerings:
          - id: bob_data_v1
      templates:
      - id: alice_test_template_2026_01_12_V1
  $$,
  'APP_WH'
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling the following procedure:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')

If providing the auto-join-warehouse parameter and using a role other than SAMOOHA_APP_ROLE, the role must also be granted the EXECUTE TASK account-level privilege.

See GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE for additional required role permissions.

TEARDOWN¶

Schema:: COLLABORATION

Called by the owner to delete a collaboration for all parties.

You must call this procedure twice. Call it once, then call GET_STATUS until it returns LOCAL_DROP_PENDING, then call this procedure again.

Note

This procedure can be called only on a collaboration that you have created and joined. If you have created but not yet joined the collaboration, you must join it before you can tear it down.

Syntax¶

TEARDOWN( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration to delete.

Returns¶

A string success message.

Example¶

-- Start the process.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.TEARDOWN($collaboration_name);

-- Call until it returns LOCAL_DROP_PENDING.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.GET_STATUS($collaboration_name);

-- Final call.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.TEARDOWN($collaboration_name);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

See GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE for additional required role permissions.

GET_STATUS¶

Schema:: COLLABORATION

Shows information about all collaborators in a given collaboration.

When running an asynchronous operation such as creating or joining a collaboration, you must check the status to know when the last operation was complete before you can perform additional actions on that collaboration, such as running analyses. This procedure can be called by any collaborator invited to a collaboration.

Collaboration owners can see the following status pathway:

CREATING » CREATED » INSTALLING » IN_REVIEW (or INSTALLATION_FAILED) » JOINING » JOINED (or JOIN_FAILED)

Non-owners will see the following status pathway:

INSTALLING » IN_REVIEW (or INSTALLATION_FAILED) » JOINING » JOINED (or JOIN_FAILED)

Syntax¶

GET_STATUS( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration to see the status of. You can see a list of your collaborations by calling COLLABORATION.VIEW_COLLABORATIONS. You must be invited to, or have joined, a collaboration before you can call GET_STATUS on it.

Returns¶

A table that shows the details about the latest join attempt for all collaborators in the specified collaboration. The table includes the following columns:

updated_on: Timestamp when the status was reported by the system.
collaborator_account: Data sharing account ID of this collaborator.
collaborator_name: The collaborator’s alias, as declared in the collaboration specification.
roles: The actual and potential roles for this collaborator. Values include owner, data_provider, analysis_runner.
status: Status at the updated time. The following values are supported, and show the status of the named collaborator in the specified collaboration.
- CREATING: Collaboration creation has started.
- CREATE_FAILED: Collaboration creation failed.
- CREATE_TIMED_OUT: Collaboration creation timed out.
- CREATED: Collaboration has been created and is ready to operate on.
- INSTALLING: Installing the application package and preparing the collaboration details for review.
- IN_REVIEW: The collaboration is in review.
- INSTALLATION_FAILED: Installation failed; application package not installed, and can’t be reviewed.
- INVITED: Participant has been invited.
- JOINING: Join process has started.
- JOIN_FAILED: Join process failed.
- JOINED: Successfully joined the collaboration. You can start to use the collaboration.
- LEAVING: Leave process has started.
- LEAVE_FAILED: Leave process failed.
- LEFT: Successfully left the collaboration.
- LOCAL_DROP_PENDING: You have made a successful request to drop or leave the collaboration. Complete the process by calling TEARDOWN or LEAVE again.
- DROPPING: Drop process has started.
- DROPPED: Successfully dropped.
- DROP_FAILED: Drop process failed.
details: Additional details about the current status, if available.
region: The cloud region of this collaborator.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.GET_STATUS(
  $collaboration_name
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('GET STATUS', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('READ', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

ENABLE_EXTERNAL_TABLE_ANALYSIS_FOR_COLLABORATION¶

Schema:: ADMIN

Enables external and Apache Iceberg™ tables to be used to run an analysis in your account. An analysis runner must call this before running any analysis that includes external or Iceberg tables. This procedure is called once per collaboration, not once per analysis.

Syntax¶

ENABLE_EXTERNAL_TABLE_ANALYSIS_FOR_COLLABORATION( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration.

Returns¶

A table with a MESSAGE column containing a success message.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.ADMIN.ENABLE_EXTERNAL_TABLE_ANALYSIS_FOR_COLLABORATION(
  $collaboration_name
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted the MANAGE FIREWALL CONFIGURATION privilege to call this procedure.

VIEW_COLLABORATIONS¶

Schema:: COLLABORATION

View information about collaborations that you have created, can review, or have joined.

Syntax¶

VIEW_COLLABORATIONS()

Arguments¶

None

Returns¶

A table that lists details of all collaborations that you can access. The table includes the following columns:

source_name: The name of the collaboration, as specified by the name value in the collaboration specification.
collaboration_name: The name of the installed collaboration. This is NULL until the collaboration is installed by calling JOIN (owners) or REVIEW (non-owners).
owner_account: Data sharing ID of the account that created the collaboration.
updated_on: When the collaboration was last updated.
collaboration_spec: The specification for this collaboration in YAML format. This shows the latest version of the collaboration, including any resources linked or removed after the collaboration was created. However, there might be update requests that are in progress that will be linked soon, such as new or removed templates or data offerings.

Examples¶

View all collaborations:

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.VIEW_COLLABORATIONS();

View the specification for a given collaboration by name:

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.VIEW_COLLABORATIONS() ->>
SELECT "COLLABORATION_SPEC" FROM $1 WHERE "SOURCE_NAME" = $collaboration_name;

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('READ', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('RUN', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('VIEW COLLABORATIONS', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

REVIEW¶

Schema:: COLLABORATION

Provides details about a collaboration to which you have been invited. Call COLLABORATION.VIEW_COLLABORATIONS to see which collaborations you have been invited to and not yet joined. All collaborators except the owner must call this procedure before calling JOIN. You cannot call this procedure on a collaboration that you have joined. You must use the same role to call REVIEW and JOIN. If your account is on a different cloud hosting region than the owner, you might need to call this procedure several times until it returns a successful response.

This procedure installs the underlying application in your account.

Important notes:

Owners cannot call REVIEW on their own collaborations.
Everyone except the owner must call REVIEW before calling JOIN.
After you have joined a collaboration, you cannot call REVIEW again.

Syntax¶

REVIEW( <source_name>, <owner_account> )

Arguments¶

source_name: Name of the collaboration you have been invited to join. You can see a list of your collaborations by calling COLLABORATION.VIEW_COLLABORATIONS.
owner_account: Data Sharing Account Identifier of the owner. This can be found in the response to COLLABORATION.VIEW_COLLABORATIONS.

Returns¶

Table of information about the collaboration, including the collaboration ID, owner, and the collaboration specification.

If your account is on a different cloud hosting region than the collaboration owner’s, REVIEW might return a message saying that additional setup steps are still being performed. If you get this message, continue calling REVIEW until it returns the information table about the collaboration.

Example¶

-- View the collaboration for your own usage.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.REVIEW(
  $collaboration_name,
  'org1.account1234'
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('REVIEW COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

See GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE for additional required role permissions.

JOIN¶

Schema:: COLLABORATION

Asynchronous method to join a specified collaboration. Note that you can access only the resources listed in the collaboration at the time that you join. This procedure takes some time to run.

You need the REGISTER DATA OFFERING account privilege to join any collaboration in which you can activate data (that is, you are an analysis runner and the collaboration specification includes an activation_destinations field). See the access management API reference guide.

You cannot have an active secondary role when you run this procedure. Run the following SQL code to disable any secondary roles:

USE SECONDARY ROLES NONE;

Everyone except the collaboration creator must call COLLABORATION.REVIEW before calling this procedure.

This procedure is asynchronous; call GET_STATUS to determine when you have successfully joined the collaboration.

Anyone who submits a resource to the collaboration or wants to run a template in the collaboration must join the collaboration first. The collaboration creator joins automatically when calling INITIALIZE (unless auto_join_warehouse is set to FALSE).

Syntax¶

JOIN( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration to join. You can see a list of your collaborations by calling COLLABORATION.VIEW_COLLABORATIONS. If you have been invited to join multiple collaborations with the same name, this defaults to the last one that you called COLLABORATION.REVIEW on.

Returns¶

A string success message. If you get an error about a missing reference usage grant, see the Troubleshooting guide.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.JOIN(
  $collaboration_name
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

See GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE for additional required role permissions.

LEAVE¶

Schema:: COLLABORATION

Leaves a collaboration that you have joined. You cannot rejoin a collaboration after you have left it.

You must call this procedure twice. Call it once, then call GET_STATUS until it returns LOCAL_DROP_PENDING, then call this procedure again.

Syntax¶

LEAVE( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration to leave.

Returns¶

A string success message.

Example¶

-- Start the process.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.LEAVE($collaboration_name);

-- Call until it returns LOCAL_DROP_PENDING.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.GET_STATUS($collaboration_name);

-- Final call.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.LEAVE($collaboration_name);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

See GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE for additional required role permissions.

GET_CONFIGURATION¶

Schema:: COLLABORATION

Returns the current configuration settings for a collaboration. You must have joined the collaboration before calling this procedure.

Syntax¶

GET_CONFIGURATION( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration.

Returns¶

A table with the following columns:


Column	Description
CONFIGURATION	The name of the configuration setting.
VALUE	The current value of the configuration.
STATUS	Whether the value is `ACTIVE` or `PENDING` (a change has been requested but not yet applied).

Supported configurations¶


Configuration name	Description
TEMPLATE_AUTO_APPROVAL	Whether template update requests from other collaborators are automatically approved. Values: `true` or `false`. Default: `false`.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.GET_CONFIGURATION(
  $collaboration_name
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('MANAGE TEMPLATE AUTO APPROVAL', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('READ', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

SET_CONFIGURATION¶

Schema:: COLLABORATION

Sets a configuration value for a collaboration. The change is asynchronous: call GET_CONFIGURATION to check when the new value has been applied. You must have joined the collaboration before calling this procedure.

Setting TEMPLATE_AUTO_APPROVAL to true is equivalent to calling ENABLE_TEMPLATE_AUTO_APPROVAL, and setting it to false is equivalent to calling DISABLE_TEMPLATE_AUTO_APPROVAL.

Syntax¶

SET_CONFIGURATION( <collaboration_name>, <config_name>, <value> )

Arguments¶

collaboration_name: Name of the collaboration.
config_name: Name of the configuration to set. See GET_CONFIGURATION for supported configuration names.
value: The new value for the configuration. Must be a valid value for the specified configuration name.

Returns¶

A string message confirming the request has been accepted.

Example¶

-- Enable automatic approval of template requests
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.SET_CONFIGURATION(
  $collaboration_name,
  'TEMPLATE_AUTO_APPROVAL',
  'true'
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('MANAGE TEMPLATE AUTO APPROVAL', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('UPDATE', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

Running analyses and activations¶

RUN¶

Schema:: COLLABORATION

Runs an analysis in the data clean room. You can pass in run details either as individual parameters, or by passing in an analysis YAML specification string.

Read the consumer.run_analysis reference for background about running a template in a data clean room.

There are two versions of this procedure: one that takes the run arguments as a single YAML-formatted string, and one that takes the arguments as individual parameters.

Syntax¶

YAML argument syntax:

RUN( <collaboration_name>, <analysis_spec> )

Explicit parameters syntax:

RUN( <collaboration_name>, <template_id>, <template_view_names>, <local_template_view_names>, <arguments> )

Arguments¶

collaboration_name: Name of the collaboration in which to run this analysis.
analysis_spec: Analysis definition in YAML format as a string, describing the template, tables, and template values to use in this analysis. Used with the YAML argument syntax.
template_id: ID of the template to run.
template_view_names: Array of string names of source tables to use in the analysis. Use table names returned by VIEW_DATA_OFFERINGS in the template_view_name column. The format for each entry is user_alias.data_offering_id.dataset_alias
local_template_view_names: Array of string IDs of your own tables to use in the analysis. You must link these tables first by calling LINK_LOCAL_DATA_OFFERING.
arguments: JSON object that contains named arguments used by the template, where each key is a template argument name, and the value is the value of that argument.

Returns¶

Analysis results in table format.

Examples¶

Pass by parameter example:

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.RUN(
  $collaboration_name,
  $template_name,
  ['Provider.data_offering_1_2026_01_12_v0.test_dataset'], -- Tables to pass to source_tables variable.
  [],
  {} -- Template takes no parameters.
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('RUN', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

VIEW_ACTIVATIONS¶

Schema:: COLLABORATION

Shows the activation status of any analysis run that either you triggered to send to a collaborator, or activations that a collaborator triggered to send to you. Activation requests to send data to yourself are not listed.

For more information about activation, see Implementing activation.

Syntax¶

VIEW_ACTIVATIONS( <collaboration_name> )

Arguments¶

collaboration_name: Name of the collaboration.

Returns¶

A table containing details for each activation. The table includes the following columns:

updated_on: Time when the status was last updated.
segment_name: An arbitrary string assigned by the analysis runner to identify this activation. For more information, see Activating query results.
batch_id: Batch ID of this activation request. For more information, see Viewing provider and consumer activation results.
template_id: Template used to produce this activation data.
shared_by: The collaborator that ran the analysis.
shared_with: The collaborator that should receive the analysis data.
status: Status of the activation. The following values are supported:
- PENDING: Activation was requested, but is waiting to be processed.
- REPLICATING: Activation data is being replicated to the destination region.
- SHARED: Activation data is ready to be processed. Call PROCESS_ACTIVATION to send the results to your account.
- FAILED: Activation processing failed. See information in the details column.
- PROCESSED: Activation results have been sent to the account specified in the activation request.
details: Failure details, if the activation failed.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.VIEW_ACTIVATIONS(
  $collaboration_name
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('VIEW ACTIVATIONS', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('RUN', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

PROCESS_ACTIVATION¶

Schema:: COLLABORATION

If the analysis runner is sending data to another collaborator’s account, that collaborator should call PROCESS_ACTIVATION to import the activation data into their account. The collaborator should call VIEW_ACTIVATIONS and wait until the output shows that the activation status for a given segment is SHARED before calling PROCESS_ACTIVATION.

For more information, see Implementing activation.

Syntax¶

PROCESS_ACTIVATION( <collaboration_name> [, <segment_name> | <array_of_batch_ids> ] )

Arguments¶

collaboration_name: Name of the collaboration.
segment_name (Optional): String name of a specific activation segment to process.
batch_ids (Optional): String array of batch IDs of activations to process. This value is returned by VIEW_ACTIVATIONS. If not included, the request will process all pending activations in the designated collaboration for the caller.

Returns¶

The table name where the user can retrieve the results, and the segment name specified for the results. See Implementing activation to learn how to read results.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.PROCESS_ACTIVATION(
  $collaboration_name
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('PROCESS ACTIVATION', 'COLLABORATION', 'collaboration name', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')

Registry management procedures¶

This section contains procedures used to register objects. For more information:

CREATE_REGISTRY¶

Schema:: REGISTRY

Creates a custom registry to organize resources such as templates and data offerings. A custom registry can store resources of a single type, designated when you create the registry.

Use custom registries to group related resources separately from the default local registry. Add resources to this registry using the optional registry name parameter.

Syntax¶

CREATE_REGISTRY( '<registry_name>', <registry_type> )

Arguments¶

registry_name: Name of the registry to create. Must be a unique name across all registries in the account.
registry_type: The type of resources this registry will contain. Supported values: TEMPLATE, DATA OFFERING.

Returns¶

A string success message.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.REGISTRY.CREATE_REGISTRY(
  'my_custom_registry',
  'TEMPLATE'
);

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling the following procedure:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE REGISTRY', 'role name')

VIEW_REGISTRIES¶

Schema:: REGISTRY

Lists all registries that you have access to, including the default local registry and any custom registries.

Syntax¶

VIEW_REGISTRIES()

Arguments¶

None.

Returns¶

A table with a row for each registry that you can access.

Example¶

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.REGISTRY.VIEW_REGISTRIES();

Access requirements¶

If you’re not using the SAMOOHA_APP_ROLE role, you must use a role that was granted privileges by calling one of the following procedures:

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('VIEW REGISTRIES', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('JOIN COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE COLLABORATION', 'role name')
GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE('CREATE REGISTRY', 'role name')

For a custom registry to be visible to VIEW_REGISTRIES, you must also have READ or REGISTER privileges, granted by one of the following procedure calls:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('READ', 'REGISTRY', 'registry name', 'role name')
GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE('REGISTER', 'REGISTRY', 'registry name', 'role name')

Access management procedures¶

The SAMOOHA_APP_ROLE role grants access to all Data Clean Room Collaboration API procedures. However, if an administrator wants to grant more granular privileges to specific roles, you can create a role and grant it specific privileges with the procedures described in this section. Learn more about managing access to Collaboration API: The Access Management Documentation.

The following procedures are used to manage fine-grained access to the Snowflake Data Clean Room Collaboration API:

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE¶

Schema:: ADMIN

Grants a specified role the privilege to call specific procedures on a specific object.

You can call this procedure multiple times to grant multiple permissions to the same role. Run this procedure using the role that owns the object.

Syntax¶

GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE(
  '<privilege>',
  '<object_type>',
  '<object_name>',
  '<account_role_name>'
);

Arguments¶

'privilege'

What permission this role should be granted. See the table below to learn which privileges are available for which objects.

'object_type'

The type of object that this role is being granted permissions on. Supported values:

COLLABORATION
REGISTRY

'object_name'

The ID of the object, as specified in the object’s specification.

'account_role_name'

The role being granted.

The following privilege and object type combinations are supported:

Compound privileges

The following compound privileges grant access to multiple procedures at once:


Privilege	Object type	Procedures enabled
`READ`	`COLLABORATION`	VIEW_COLLABORATIONS, GET_STATUS, GET_CONFIGURATION, VIEW_CODE_SPECS, VIEW_DATA_OFFERINGS, VIEW_UPDATE_REQUESTS, VIEW_TEMPLATES
`RUN`	`COLLABORATION`	RUN, VIEW_ACTIVATIONS, VIEW_COLLABORATIONS
`UPDATE`	`COLLABORATION`	LINK_LOCAL_DATA_OFFERING, UNLINK_LOCAL_DATA_OFFERING, ADD_TEMPLATE_REQUEST, REMOVE_TEMPLATE, APPROVE_UPDATE_REQUEST, REJECT_UPDATE_REQUEST, ENABLE_TEMPLATE_AUTO_APPROVAL, DISABLE_TEMPLATE_AUTO_APPROVAL, SET_CONFIGURATION, VIEW_UPDATE_REQUESTS
`READ`	`REGISTRY`	View resources registered in a custom registry.
`REGISTER`	`REGISTRY`	View or register resources such as templates and data offerings in a custom registry.

Fine-grained privileges

The following fine-grained privileges grant access to individual procedures on a specific collaboration:


Privilege	Procedures enabled
`GET STATUS`	GET_STATUS
`VIEW DATA OFFERINGS`	VIEW_DATA_OFFERINGS
`VIEW TEMPLATES`	VIEW_TEMPLATES
`VIEW CODE SPECS`	VIEW_CODE_SPECS
`VIEW UPDATE REQUESTS`	VIEW_UPDATE_REQUESTS
`VIEW ACTIVATIONS`	VIEW_ACTIVATIONS
`ADD TEMPLATE REQUEST`	ADD_TEMPLATE_REQUEST
`REMOVE TEMPLATE`	REMOVE_TEMPLATE
`MANAGE UPDATE REQUEST`	APPROVE_UPDATE_REQUEST, REJECT_UPDATE_REQUEST
`MANAGE TEMPLATE AUTO APPROVAL`	ENABLE_TEMPLATE_AUTO_APPROVAL, DISABLE_TEMPLATE_AUTO_APPROVAL, GET_CONFIGURATION, SET_CONFIGURATION
`LINK LOCAL DATA OFFERINGS`	LINK_LOCAL_DATA_OFFERING
`UNLINK LOCAL DATA OFFERINGS`	UNLINK_LOCAL_DATA_OFFERING
`PROCESS ACTIVATION`	PROCESS_ACTIVATION

Returns¶

A table with a MESSAGE column containing a success message.

Example¶

This example creates a role for analysts to use to run analyses in a collaboration named my_collaboration and assigns it to a user.

USE ROLE role_that_created_this_collaboration;

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.ADMIN.GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE(
  'RUN',
  'COLLABORATION',
  $collaboration_name,
  'collaborator_analyst_role'
);
GRANT ROLE collaborator_analyst_role to USER alexander_hamilton;

Access requirements¶

You must use the same role that created the object to call GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE on that object.

For collaborations, any role with CREATE COLLABORATION or JOIN COLLABORATION can call GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE on any collaboration.
For registries, only the role that created the registry can call GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE on that registry.

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE¶

Schema:: ADMIN

Grants account-level privileges to a role. This procedure enables anyone using that role to call the procedures listed for that privilege.

Syntax¶

GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE( '<privilege>', '<account_role_name>' );

Arguments¶

'privilege'

The privilege to grant this role. The following string values are supported:

JOIN COLLABORATION: Grants permission to run COLLABORATION.JOIN as well as the following procedures on the joined collaboration:
- ADMIN.GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE
- ADMIN.GRANT_PRIVILEGE_ON_OBJECT_TO_ROLE
- ADMIN.REVOKE_PRIVILEGE_ON_OBJECT_FROM_ROLE
- COLLABORATION.ADD_TEMPLATE_REQUEST
- COLLABORATION.APPROVE_UPDATE_REQUEST
- COLLABORATION.ENABLE_TEMPLATE_AUTO_APPROVAL
- COLLABORATION.DISABLE_TEMPLATE_AUTO_APPROVAL
- COLLABORATION.REMOVE_TEMPLATE
- COLLABORATION.GET_STATUS
- COLLABORATION.LEAVE
- COLLABORATION.LINK_DATA_OFFERING
- COLLABORATION.LINK_LOCAL_DATA_OFFERING
- COLLABORATION.PROCESS_ACTIVATION
- COLLABORATION.REJECT_UPDATE_REQUEST
- COLLABORATION.REVIEW
- COLLABORATION.RUN
- COLLABORATION.TEARDOWN
- COLLABORATION.UNLINK_DATA_OFFERING
- COLLABORATION.UNLINK_LOCAL_DATA_OFFERING
- COLLABORATION.VIEW_ACTIVATIONS
- COLLABORATION.VIEW_CODE_SPECS
- COLLABORATION.VIEW_COLLABORATIONS
- COLLABORATION.VIEW_DATA_OFFERINGS
- COLLABORATION.VIEW_TEMPLATES
- COLLABORATION.VIEW_UPDATE_REQUESTS
- REGISTRY.VIEW_REGISTRIES
- REGISTRY.VIEW_REGISTERED_CODE_SPECS
- REGISTRY.VIEW_REGISTERED_DATA_OFFERINGS
- REGISTRY.VIEW_REGISTERED_TEMPLATES
This privilege requires the following account-level privileges to be granted to the role manually:
- APPLY ROW ACCESS POLICY ON ACCOUNT
- CREATE APPLICATION ON ACCOUNT
- CREATE DATABASE ON ACCOUNT
- CREATE LISTING ON ACCOUNT
- CREATE SHARE ON ACCOUNT
- IMPORT SHARE ON ACCOUNT
- MANAGE SHARE TARGET ON ACCOUNT
CREATE COLLABORATION: Grants permission to run COLLABORATION.INITIALIZE, plus all procedures allowed by JOIN COLLABORATION for the joined collaboration. Requires the following account-level privileges to be granted manually to the role:
- APPLY ROW ACCESS POLICY
- CREATE APPLICATION
- CREATE DATABASE
- CREATE LISTING
- CREATE SHARE
- IMPORT SHARE
- MANAGE SHARE TARGET
- EXECUTE TASK (if using auto-join in the INITIALIZE procedure)
VIEW COLLABORATIONS: Grants permission to run COLLABORATION.VIEW_COLLABORATIONS. Requires the following privileges to be granted manually to the role:
- IMPORT SHARE ON ACCOUNT
REGISTER DATA OFFERING: Grants permission to run REGISTRY.REGISTER_DATA_OFFERING. This permission is required for any analysis runner to join a collaboration that implements activation.
VIEW REGISTERED DATA OFFERINGS: Grants permission to run REGISTRY.VIEW_REGISTERED_DATA_OFFERINGS.
REGISTER TEMPLATE: Grants permission to run REGISTRY.REGISTER_TEMPLATE.
VIEW REGISTERED TEMPLATES: Grants permission to run REGISTRY.VIEW_REGISTERED_TEMPLATES.
REGISTER CODE SPEC: Grants permission to run REGISTRY.REGISTER_CODE_SPEC.
VIEW REGISTERED CODE SPECS: Grants permission to run REGISTRY.VIEW_REGISTERED_CODE_SPECS.
CREATE REGISTRY: Grants permission to run REGISTRY.CREATE_REGISTRY, REGISTRY.VIEW_REGISTRIES, and also the ability to read from custom registries that you have created.
REVIEW COLLABORATION: Grants permission to run COLLABORATION.REVIEW.
VIEW REGISTRIES: Grants permission to run REGISTRY.VIEW_REGISTRIES.
VIEW DCR STATUS: Grants permission to view the overall status of Data Clean Rooms in the account.

'account_role_name'

The name of an account-level role.

Returns¶

A table with a MESSAGE column containing a success message.

Example¶

USE ROLE ACCOUNTADMIN;
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.ADMIN.GRANT_PRIVILEGE_ON_ACCOUNT_TO_ROLE(
  'REGISTER DATA OFFERING',
  'COLLABORATOR_ANALYST_ROLE'
);

Access requirements¶

You need the ACCOUNTADMIN role, or a role with the MANAGE GRANTS global privilege, to run this procedure.