Request access workflow for organizational listings¶

The request access workflow lets consumers request access to organizational listings in the Internal Marketplace when they don’t already have access. Providers configure who can discover a listing, who can access it without a request, and how access requests are submitted and approved.

You can configure the workflow in Snowsight or programmatically using SQL and the organization listing manifest.

Overview¶

Organizational listings support separate controls for discovery and access:

Discovery defines who can find a listing in the Internal Marketplace and request access to it.
Access defines who can use the listing without submitting a request.

When a consumer discovers a listing but doesn’t have access, they can submit an access request. An approver reviews the request and grants or denies access to a specific role.

For organization_targets patterns, see Configure organizational listings.

Request approval types¶

Providers choose how access requests are handled:

Approval type	Manifest value	Summary
In Snowflake	`REQUEST_AND_APPROVE_IN_SNOWFLAKE`	Consumers submit requests in the Internal Marketplace. Providers approve or deny requests in Snowsight.
Out of band (legacy)	`REQUEST_AND_APPROVE_OUTSIDE_SNOWFLAKE` without `request_approval_config_name`	Consumers contact the `approver_contact` email address or URL. Providers grant access manually in Snowflake after external approval.
Out of band (notification integration)	`REQUEST_AND_APPROVE_OUTSIDE_SNOWFLAKE` with `request_approval_config_name`	When a consumer submits a request, Snowflake sends a webhook notification to your ticketing system with listing and requester context. Providers grant access manually in Snowflake after external approval.

In Snowsight, in-Snowflake approval corresponds to Manage requests in Snowflake. Out-of-band approval corresponds to Manage requests outside of Snowflake.

Prerequisites¶

Providers

A role with privileges to create or alter organizational listings. See Assign organizational listing privileges.
An approver email address when the listing is discoverable by users who don’t have access and you use REQUEST_AND_APPROVE_IN_SNOWFLAKE, or legacy out-of-band approval without request_approval_config_name. See Request access workflow.

Consumers

A complete Snowsight user profile that includes a valid email address. See Manage your user settings in Snowsight.

Limitations¶

The request access workflow grants access to roles, not individual users.
Request submission, review, and approval in Snowsight require a valid email address in the consumer’s or approver’s user profile.
To approve an in-Snowflake request, you must have access to the Snowflake account where the request originated and a role with OWNERSHIP or MODIFY privileges on the organizational listing.
Grant and deny actions on the Internal Requests page apply only when request_approval_type is REQUEST_AND_APPROVE_IN_SNOWFLAKE.
Snowflake does not sync approvals from external ticketing systems back into the request access workflow. After you approve a request in ServiceNow, Jira, Slack, or another external system, you must update listing access targets in Snowflake yourself.
Each listing supports one out-of-band notification integration configuration when you use request_approval_config_name.

Configure the request access workflow when creating a listing¶

Sign in to Snowsight.
In the navigation menu, select Data sharing » Internal sharing.
Select + Create Listing.
Select a data product such as a table, view, or other data product to add to the listing.
1. Review the generated share identifier, then select Generate listing.
Select + Access control.
Complete the Grant access and Allow discovery sections. Use No accounts or roles are pre-approved when consumers must request access. See Create an organizational listing for field descriptions.
Select Set up request approval flow, and then select one of the following options in the How should the request approval happen list:
- Manage requests in Snowflake: Consumers submit and providers approve requests in Snowsight.
- Manage requests outside of Snowflake: Consumers request access using the email address or URL you provide.
If you selected Manage requests in Snowflake:
1. In the Approver email for notifications field, enter the email address for access request notifications.
2. Optional. Select Add Role to add organizational listing approver roles.
3. Select Done.
If you selected Manage requests outside of Snowflake:
1. Select Use external method to choose an organization-level notification configuration, or enter an email address or URL in Approver contact for the legacy out-of-band flow.
2. If you use an external method, select the notification configuration your organization administrator published.
3. Select Done.
Select Save, add a listing title, optional metadata, and Publish.

Create an organizational listing with a request access workflow by setting organization_targets, request_approval_type, and the contact or configuration fields that match your approval type in the listing manifest.

The following example creates a listing that all internal accounts can discover, but only the finance account can access without a request. Other consumers must request access. Access requests are submitted and approved in Snowflake.

USE ROLE <organization_listing_role>;

CREATE ORGANIZATION LISTING MY_REQUEST_LISTING
SHARE <share_name> AS
$$
title: "Finance data product"
description: "Discoverable across the organization; access by request"
organization_profile: "INTERNAL"
organization_targets:
  discovery:
    - all_internal_accounts: true
  access:
    - account: "finance"
support_contact: "support@example.com"
approver_contact: "approver@example.com"
request_approval_type: "REQUEST_AND_APPROVE_IN_SNOWFLAKE"
locations:
  access_regions:
    - name: "PUBLIC.AWS_US_WEST_2"
$$;

For out-of-band approval with webhook notifications, set request_approval_type to REQUEST_AND_APPROVE_OUTSIDE_SNOWFLAKE and reference an organization-level configuration:

request_approval_type: "REQUEST_AND_APPROVE_OUTSIDE_SNOWFLAKE"
request_approval_config_name: "RAW_INTEGRATION"

For legacy out-of-band approval (email or URL only), omit request_approval_config_name and set approver_contact:

approver_contact: "https://internal.example.com/access-requests"
request_approval_type: "REQUEST_AND_APPROVE_OUTSIDE_SNOWFLAKE"

Configure the request access workflow in an existing listing¶

Sign in to Snowsight.
In the navigation menu, select Data sharing » Internal sharing.
On the Listings tab, select the listing you want to edit.
Select Edit in the Approver Contact area.
Select Manage requests in Snowflake or Manage requests outside of Snowflake, configure approver contact details, and select Done.

Update the request access workflow by altering the listing manifest with ALTER LISTING:

ALTER LISTING MY_REQUEST_LISTING AS
$$
approver_contact: "approver@example.com"
request_approval_type: "REQUEST_AND_APPROVE_IN_SNOWFLAKE"
$$;

To update discovery and access targets, include organization_targets in the manifest.

In-Snowflake request and approval workflow¶

When request_approval_type is REQUEST_AND_APPROVE_IN_SNOWFLAKE, providers and consumers complete the full request lifecycle in Snowsight.

Respond to access requests as a provider¶

As a provider, access requests are sent to the email address you specified when you configured the workflow.

Note

To approve a request, you need access to the Snowflake account the request originated from, and a role that owns or can modify the organizational listing. If you don’t meet these requirements, the Review Request control in the request email doesn’t work.

Open the organizational listing access request email and select Review Request.

The Internal Requests page in Snowsight opens.
Select the request, review the details, and optional comments.
Optional. To grant access to a different role, select Give access to a different role from requested and specify the role.
Select Grant request or Deny request.

You can also use Marketplace » Provider Studio » Requests to review open and resolved requests.

Request access as a consumer¶

Note

Your Snowsight user profile must include a valid email address.

Sign in to Snowsight.
In the navigation menu, select Catalog » Internal Marketplace.
Search for a listing and select Request access.
Select the role, enter a reason, and select Submit request.

Use View request on the listing page to check status. Select Withdraw request to cancel an open request. When a request is approved or denied, you receive an email notification with a Review Request link to open the listing.

For in-Snowflake requests, use OBJECT_ACCESS_REQUEST_HISTORY to audit submissions, approvals, and denials.

Out-of-band request and approval workflow¶

When request_approval_type is REQUEST_AND_APPROVE_OUTSIDE_SNOWFLAKE, your organization manages review and approval outside Snowflake. After you approve access in your external process, you add the consumer’s account and role to the listing access targets in Snowflake.

Snowflake supports two out-of-band patterns:

Legacy: Specify approver_contact as an email address or URL. Consumers contact that destination when they select Request access. Email notifications are basic and URLs do not include structured request context.
Notification integration: An organization administrator defines a webhook notification integration and publishes an Internal Marketplace configuration. Providers reference that configuration on the listing. When a consumer submits a request, Snowflake sends a webhook to your ticketing system (such as ServiceNow, Jira, or Slack) with listing and requester context.

Use out-of-band approval when:

Your organization requires approvals in ServiceNow, SailPoint, Jira, or another ticketing system.
Legal or compliance teams must record data access requests outside Snowflake.
Listing approvers manage access through tools other than the Internal Requests page.

Organization administrators: configure notification integrations¶

Organization administrators centralize webhook notification integrations in the organization account, similar to custom attributes.

In the organization account, create a webhook notification integration for your ticketing system. Store webhook secrets in a Snowflake secret object and grant USAGE on the integration to roles that manage listings, as needed.
Create an Internal Marketplace configuration that references the integration:

CREATE INTERNAL MARKETPLACE CONFIG RAW_INTEGRATION AS $$
title: "Request approval notification config"
description: "Out-of-band request access workflow notifications"
config_type: "request_approval_notification"
is_required: false
props:
  integration_type: "notification_integration"
  integration_name: "MY_SLACK_WEBHOOK_INT"
$$;

Use the same INTERNAL MARKETPLACE CONFIG commands as custom attributes to alter, drop, or describe configurations.

Providers in member accounts run SHOW AVAILABLE INTERNAL MARKETPLACE CONFIGS to view configurations the organization published.

Providers: associate a listing with a notification configuration¶

In Snowsight, when you configure Manage requests outside of Snowflake, select Use external method and choose the organization configuration.

In the listing manifest, set request_approval_type and request_approval_config_name:

CREATE ORGANIZATION LISTING raw_org_listing
SHARE raw_share AS
$$
title: "Example listing"
organization_profile: "INTERNAL"
organization_targets:
  discovery:
    - all_internal_accounts: true
  access: []
support_contact: "support@example.com"
request_approval_type: "REQUEST_AND_APPROVE_OUTSIDE_SNOWFLAKE"
request_approval_config_name: "RAW_INTEGRATION"
$$;

When the listing is discoverable and request_approval_type is REQUEST_AND_APPROVE_OUTSIDE_SNOWFLAKE, specify either request_approval_config_name or approver_contact (an email address or external URL). You don’t need both. If you omit request_approval_config_name, consumers use the legacy approver_contact flow.

Webhook notification payload¶

When a consumer submits an access request and the listing specifies request_approval_config_name, Snowflake sends a webhook notification using the organization’s notification integration. The payload includes context your ticketing automation can use to open or update a ticket:

{
  "listing_name": "ORG_LISTING_RAW_INTEGRATION",
  "requestor_account_name": "CONSUMER",
  "requestor_name": "John",
  "requestor_role": "SYSADMIN"
}

Snowflake uses a fixed payload format. Configure your notification integration body template to pass the message content to your external system. See Sending webhook notifications for integration examples.

Submit a request as a consumer¶

Sign in to Snowsight.
In the navigation menu, select Catalog » Internal Marketplace.
Search for the listing and select Request access.
Select the role you need, enter a reason if prompted, and submit the request.

If the listing uses a notification integration, Snowflake sends the webhook notification when you submit the request. If the listing uses the legacy out-of-band flow, follow the prompt to contact the provider using the configured email address or URL.

Snowflake doesn’t record approve or deny actions for out-of-band workflows on the Internal Requests page.

Grant access after external approval¶

After you approve a request in your external process, add the consumer’s account and role to the listing Grant access targets so they can use the data product.

Sign in to Snowsight.
In the navigation menu, select Data sharing » Internal sharing.
Select the listing, open Access control, and add the approved account and role under Grant access.
Save and publish changes if required.

Alter the listing manifest to add the role under organization_targets.access:

ALTER LISTING MY_REQUEST_LISTING AS
$$
organization_targets:
  access:
    - account: "consumer_account"
      roles:
        - "ANALYST"
$$;

Include existing manifest fields when you alter a published listing so you don’t overwrite other settings. Use DESCRIBE LISTING to view the current manifest.

Programmatic configuration reference¶

Configure the request access workflow in the organization listing manifest when you use CREATE ORGANIZATION LISTING or ALTER LISTING.

`organization_targets`¶

The organization_targets field defines who can discover and access the listing:

Set discovery to define who can find the listing and submit access requests.
Set access to define who can use the listing without submitting a request.

`approver_contact`¶

The email address or URL for the listing approver.

Required when the discovery field is specified and either of the following is true:

request_approval_type is REQUEST_AND_APPROVE_IN_SNOWFLAKE.
request_approval_type is REQUEST_AND_APPROVE_OUTSIDE_SNOWFLAKE and you don’t set request_approval_config_name.

When request_approval_type is REQUEST_AND_APPROVE_OUTSIDE_SNOWFLAKE and request_approval_config_name is set, approver_contact is optional. For out-of-band approval, specify approver_contact or request_approval_config_name.

approver_contact: "approver@example.com"

`request_approval_type`¶

Define whether access requests and approvals happen inside or outside of Snowflake:

REQUEST_AND_APPROVE_IN_SNOWFLAKE: Consumers submit, and providers approve or deny, requests in Snowsight.
REQUEST_AND_APPROVE_OUTSIDE_SNOWFLAKE: The provider manages request submission and approval outside Snowflake. When the listing is discoverable, specify one of the following:
- request_approval_config_name for webhook notifications through an organization-level notification integration.
- approver_contact as an email address or external URL (legacy out-of-band flow).

request_approval_type: "REQUEST_AND_APPROVE_IN_SNOWFLAKE"

`request_approval_config_name`¶

Name of an Internal Marketplace configuration with config_type set to request_approval_notification. Use with REQUEST_AND_APPROVE_OUTSIDE_SNOWFLAKE instead of approver_contact when your organization publishes a notification integration configuration.

request_approval_config_name: "RAW_INTEGRATION"

For field details, see The name of an %i-market% configuration that defines a [webhook notification….

Run DESCRIBE AVAILABLE LISTING or SHOW AVAILABLE LISTINGS to view the configured request_approval_type for a listing.

For the complete manifest reference, see Organization listing manifest reference.

Request access workflow for organizational listings¶

Overview¶

Request approval types¶

Prerequisites¶

Limitations¶

Configure the request access workflow when creating a listing¶

Configure the request access workflow in an existing listing¶

In-Snowflake request and approval workflow¶

Respond to access requests as a provider¶

Request access as a consumer¶

Out-of-band request and approval workflow¶

Organization administrators: configure notification integrations¶

Providers: associate a listing with a notification configuration¶

Webhook notification payload¶

Submit a request as a consumer¶

Grant access after external approval¶

Programmatic configuration reference¶

organization_targets¶

approver_contact¶

request_approval_type¶

request_approval_config_name¶

`organization_targets`¶

`approver_contact`¶

`request_approval_type`¶

`request_approval_config_name`¶