Skip to main content

Use Zuora Secure Data Share for Snowflake to access Zuora data

Zuora

Use Zuora Secure Data Share for Snowflake to access Zuora data

  1. Last updated
  2. Save as PDF

Set up Secure Data Share

To check your eligibility to use Secure Data Share, see Availability.

To set up Secure Data Share, contact your Zuora account representative and provide the following information:

  • The tenant ID of the Zuora tenant from which to share data. For information about locating the tenant ID, see Managing your tenant profile.
  • The entity to share data from. Only applicable if the Multi-entity feature is enabled in your Zuora tenant.
  • The account identifier of your organization's Snowflake account. You can obtain the account identifier from the URL of your organization's Snowflake account: <account_identifier>.snowflakecomputing.com

Zuora creates a database from your Zuora data and shares the database with your organization's Snowflake account. The name of the database is zuora_<id>, where <id> is the tenant ID of the Zuora tenant that the data is shared from.

You need to request an individual data share for each tenant. However, in the case of a multi-entity tenant, the same share can include all entities, with each entity represented as a separate database.

Data security

When you set up Secure Data Share, Zuora only shares data from the tenant that you specify. In addition, the shared database is only accessible via the Snowflake account that you specify.

The shared database is read-only.

The visibility of the shared database depends on how your Snowflake administrator has set up access control. For more information, see Access Control in Snowflake in the Snowflake documentation.

Tables and columns available in Snowflake

The following tables are available in the shared database. To determine the columns available in each table, you can use the SHOW COLUMNS command from Snowflake's SQL syntax. For more information, see SHOW COLUMNS in the Snowflake documentation. Columns containing PCI data contain null values and are excluded from the share.

To save your Total Active Rows (TAR) credit, Zuora syncs a basic group of Billing objects, all custom objects, and all supported Revenue objects to Snowflake by default. If you want to sync other supported Billing objects to Snowflake, submit a request at Zuora Global Support.

The following table shows details of each supported table type:

Table type Sync by default List of available objects
Billing - basic standard objects Yes See Available Billing objects. 
Billing - other standard objects No See Available Billing objects. 
Billing - custom objects Yes  All custom objects in your tenant are supported. See, Custom Objects. 
Revenue objects Yes  See Available Revenue objects.
Tables for monitoring (N/A) See Tables for monitoring.

Available Billing objects

Zuora supports syncing both standard and custom objects to Snowflake. Any objects from the list can be added or removed based on an on-demand request. All these objects contribute to the TAR (Total Active Rows) usage.

Zuora syncs the following basic standard objects to Snowflake by default:

  • Account
  • AccountingCode
  • AccountingPeriod
  • Amendment
  • Contact
  • CreditMemo
  • CreditMemoItem
  • CreditTaxationItem
  • DebitMemo
  • DebitMemoItem
  • DebitTaxationItem
  • Invoice
  • InvoiceItem
  • JournalEntry
  • JournalEntryItem
  • OrderAction
  • OrderMrr
  • OrderQuantity
  • Orders
  • OrderTcb
  • OrderTcv
  • Payment
  • PaymentMethod
  • PaymentSchedule
  • PaymentScheduleItem
  • Product
  • ProductRatePlan
  • ProductRatePlanCharge
  • RatePlan
  • RatePlanCharge
  • Refund
  • RevenueEvent
  • RevenueEventInvoiceItem
  • RevenueSchedule
  • RevenueScheduleItem
  • Subscription
  • TaxationItem

Zuora does not sync the following standard objects to Snowflake by default. If you want Zuora to sync these objects, submit a request at Zuora Global Support.

  • ARTransaction
  • BillingPreviewRunResult
  • BillingRun
  • Contactsnapshot
  • CreditBalanceAdjustment
  • CreditMemoApplication
  • CreditMemoApplicationItem
  • CreditMemoPart
  • CreditMemoPartItem
  • DailyConsumptionSummary
  • Feature
  • FXCustomRate
  • GuidedUsage
  • InvoiceAdjustment
  • InvoiceHistory
  • InvoiceItemAdjustment
  • InvoicePayment
  • JournalRun
  • MinCommitPeriod
  • MinCommitTransaction
  • NonSubscriptionInvoiceItem
  • OrderActionRatePlan
  • OrderCallLog
  • OrderContact
  • OrderDeltaMrr
  • OrderDeltaTcb
  • OrderDeltaTcv
  • OrderElp
  • OrderItem
  • OrderLineItem
  • PaymentApplication
  • PaymentApplicationItem
  • PaymentMethodSnapshot
  • PaymentPart
  • PaymentPartItem
  • PaymentRun
  • PaymentTransactionLog
  • PrepaidBalance
  • PrepaidBalanceFund
  • PrepaidBalanceTransaction
  • ProcessedUsage
  • ProductFeature
  • ProductRatePlanChargeTier
  • Ramp
  • RampInterval
  • RampIntervalDeltaMetrics
  • RampIntervalDeltaMrr
  • RampIntervalDeltaQuantity
  • RampIntervalMetrics
  • RampIntervalMrr
  • RefundtTansactionLog
  • RatePlanChargeTier
  • RatingResult
  • RealTimeRatingProcessedUsage
  • RefundApplication
  • RefundApplicationItem
  • RefundInvoicePayment
  • RefundPart
  • RefundPartItem
  • RefundTransactionLog
  • RevenueChargeSummary
  • RevenueChargeSummaryItem
  • RevenueEventCreditMemoItem
  • RevenueEventDebitMemoItem
  • RevenueEventInvoiceItemAdjustment
  • RevenueEventItem
  • RevenueEventItemCreditMemoItem
  • RevenueEventItemDebitMemoItem
  • RevenueEventItemInvoiceItem
  • RevenueEventItemInvoiceItemAdjustment
  • RevenueEventType
  • RevenueScheduleCreditMemoItem
  • RevenueScheduleDebitMemoItem
  • RevenueScheduleInvoiceItem
  • RevenueScheduleInvoiceItemAdjustment
  • RevenueScheduleItemCreditMemoItem
  • RevenueScheduleItemDebitMemoItem
  • RevenueScheduleItemInvoiceItem
  • RevenueScheduleItemInvoiceItemAdjustment
  • SubscriptionProductFeature
  • SubscriptionStatusHistory
  • UpdaterBatch
  • UpdaterDetail
  • Usage
  • User
  • ValidityPeriodSummary

Supported FX Data Tables

When the currency conversion feature is enabled on your tenant, you can export transaction amounts converted into your home currency and other specified currencies. This functionality applies to a set of transaction tables. For the complete list of tables that support FX data conversion, see Data source objects that support FX data conversion. 

Example Format for Snowflake Schema

In Snowflake, the tables related to transaction amounts converted into your specified currencies will appear as follows:

  • Payment Object
    • Payment
    • PaymentFXData
  • Credit Memo Object
    • CreditMemo
    • CreditMemoFXData

These FX data tables contain the foreign currency conversion amounts for the corresponding transaction types (e.g., PaymentFXData for payments, InvoiceFXData for invoices). You will find both the original transaction data and the converted data in the specified currencies based on the Currency Conversion feature. The FX data tables will be generated for the following transaction types.

  • Credit Memo FX Data
  • Credit Memo Application Item FX Data
  • Credit Memo Item FX Data
  • Credit Memo Part FX Data
  • Credit Memo Part Item FX Data
  • Credit Taxation Item FX Data
  • Credit Balance Adjustment FX Data
  • Credit Memo FX Data
  • Credit Memo Application FX Data
  • Credit Memo Application Item FX Data
  • Credit Memo Item FX Data
  • Credit Memo Part FX Data
  • Credit Memo Part Item FX Data
  • Credit Taxation Item FX Data
  • Debit Memo FX Data
  • Debit Memo Item FX Data
  • Debit Memo FX Data
  • Debit Memo Item FX Data
  • Debit Taxation Item FX Data
  • Invoice FX Data
  • Invoice Item Adjustment FX Data
  • Invoice Item FX Data
  • Invoice Payment FX Data
  • Invoice Adjustment FX Data
  • Invoice Item FX Data
  • Invoice Item Adjustment FX Data
  • Invoice Payment FX Data
  • Payment Application FX Data
  • Payment Application Item FX Data
  • Payment FX Data
  • Payment Part FX Data
  • Payment Part Item FX Data
  • Payment Application FX Data
  • Payment Application Item FX Data
  • Payment Part FX Data
  • Payment Part Item FX Data
  • Refund Application FX Data
  • Refund Application Item FX Data
  • Refund FX Data
  • Refund Invoice Payment FX Data
  • Refund Part FX Data
  • Refund Part Item FX Data
  • Refund Application FX Data
  • Refund Application Item FX Data
  • Refund Invoice Payment FX Data
  • Refund Part FX Data
  • Refund Part Item FX Data
  • Revenue Schedule Item Credit Memo Item FX Data
  • Revenue Schedule Item Debit Memo Item FX Data
  • Taxation Item FX Data

Custom objects

Zuora syncs all custom objects in your tenant to Snowflake by default. The custom object names in Snowflake are consistent with the custom object names in Data Query, which are prefixed with default__. For example, default__vehicle. Custom objects also contribute to TAR usage.

Multi-Organization related tables

You can view your Zuora tenant data in Snowflake tables and associate it with Organization IDs. It facilitates accurate data segmentation and control according to your organizational boundaries. 

Multi-Org Support Configurations:

One-to-One Mapping

Each object is directly associated with a single organizational ID, which has been added as a new field within the respective business object tables.

Many to Many Mapping

Dedicated mapping tables are useful in scenarios where objects may belong to multiple organizations or multiple organizations need to be linked to a single object. These tables follow the pattern <ObjectName>OrgMap, e.g., ProductOrgMap, supporting flexible associations between objects and organizations.

An organization table is used to support both configurations. This table provides the Organization ID and Name, enabling you to associate these tables and filter records effectively.

Schema details 
  • Organization:
    • Id: Unique identifier for the organization.
    • Name: The name of the organization.
  • OrgMap (e.g., ProductOrgMap):
    • ObjectNameID: Links to the specific object. (e.g.,  ProductID) 
    • OrgId: Corresponds to the associated organization.
    • TenantId: Identifier for the tenant.
Existing Table Enhancements: For example, the Account table:
  • Existing columns are retained.
  • OrganizationId: Field used to link each account directly to an organizational entity.

Mapping Types

One-to-One Mapping: The following tables have the OrganizationId field directly within the object itself:

  • Account
  • Amendment
  • Contact
  • CreditMemo
  • CreditMemoItem
  • CreditTaxationItem
  • DebitMemo
  • DebitMemoItem
  • DebitTaxationItem
  • Invoice
  • InvoiceItem
  • JournalEntry
  • JournalEntryItem
  • OrderAction
  • Orders
  • Payment
  • PaymentMethod
  • RatePlan
  • RatePlanCharge
  • Refund
  • Subscription
  • TaxationItem
  • CreditMemoApplication
  • CreditMemoApplicationItem
  • CreditMemoPart
  • CreditMemoPartItem
  • OrderLineItem
  • PaymentApplication
  • PaymentApplicationItem
  • PaymentMethodSnapshot
  • PaymentPart
  • PaymentPartItem
  • PaymentTransactionLog
  • RatePlanChargeTier
  • RefundApplication
  • RefundApplicationItem
  • RefundPart
  • RefundPartItem
  • SubscriptionStatusHistory
  • Usage

Many to Many Mapping: The following tables have an associated dedicated mapping table:

  • AccountingPeriod
  • Product
  • ProductRatePlan
  • ProductRatePlanCharge
  • BillingRun
  • JournalRun
  • PaymentRun
  • ProductRatePlanChargeTier

Available Revenue objects

Zuora syncs the following Revenue objects to Snowflake by default:

  • REVENUECALENDAR
  • REVENUECONTRACT
  • REVENUECONTRACTACCOUNTINGENTRIES
  • REVENUECONTRACTACCOUNTINGSEGMENTS
  • REVENUECONTRACTACCOUNTINGTYPE
  • REVENUECONTRACTACTIONS
  • REVENUECONTRACTAPPROVALS
  • REVENUECONTRACTBILLSDIMENSIONS
  • REVENUECONTRACTBILLSFACTS
  • REVENUECONTRACTCOSTDIMENSIONS
  • REVENUECONTRACTCOSTFACTS
  • REVENUECONTRACTHOLDS
  • REVENUECONTRACTLINESDIMENSIONS
  • REVENUECONTRACTLINESFACTS
  • REVENUECONTRACTMJENTRIESDIMENSIONS
  • REVENUECONTRACTMJENTRIESFACTS
  • REVENUECONTRACTVCDIMENSIONS
  • REVENUECONTRACTVCFACTS
  • REVENUEPERIODS

Tables for monitoring

The following tables in Snowflake are generated by Zuora for data monitoring purposes:

FAQs

  • How frequently is the shared database updated with the latest data?

    The frequency at which data is synchronized into your Snowflake warehouse is configurable. Typically, it is advisable for you to choose to synchronize data every 15 or 60 minutes, although options are available for lower latency. Additional fees are applicable depending on the latency setting. Contact Zuora to discuss options. 

  • Is it possible for Zuora to access data in my organization's Snowflake account?

    No.

  • Are there limits to how much data Zuora will share to my Snowflake account?

    Yes, Zuora will share data up to your committed TAR level.

  • What does TAR stand for?

    TAR stands for Total Active Rows and is the total count of rows made available from Zuora to your Snowflake account in your secure data share. Zuora will exclude data from INFORMATION_SCHEMA and TAR_USAGE_HISTORY in the total active row count. Zuora will include soft deleted records as part of the total active row count. 
    Customers are able to view and monitor total active rows by querying the TAR_USAGE_HISTORY table provided by Zuora, which is a daily snapshot and accounting of TAR levels.
    Your purchase of this feature commits you to a specific total committed TAR level for each tenant identified on the applicable Order Form.

  • What happens if the data in my Zuora tenant grows so much that my committed TARs level is exceeded?

    If your committed TAR level is exceeded, Zuora will pause new data updates into your share from Zuora until your TAR level is increased. Contact your Zuora account representative to discuss options for increasing your allowance if you are approaching your TAR limit.

  • Are there any limits associated with querying the shared database in Snowflake?

    No. You can query the shared database as if it were stored in your organization's Snowflake account. However, your organization is responsible for the compute costs of querying the shared database.

  • Are there any costs associated with querying the shared database in Snowflake?

    Yes. All queries that you run inside your Snowflake account against the shared database will consume your organization's Snowflake compute credits. Your organization will directly pay Snowflake for those compute credits. However, Zuora covers all data storage costs associated with the shared database. Your organization will not incur any additional storage fees from Snowflake as a result of the share. In other words, your organization pays for all the Snowflake compute, but nothing extra for Snowflake storage.

    In addition, access to the shared database will involve additional Zuora license fees.

  • Does Snowflake support ZOQL?

    No. You can use Snowflake's SQL syntax to query data. For more information, see SQL Command Reference in the Snowflake documentation.

  • Are the business object tables in Snowflake the same as those in Zuora?

    Yes. However, you must refer to the supported objects in Snowflake because not all available objects in Data Query are supported in Snowflake.

  • Are slowly changing dimensions supported?

    Not at this time. Zuora provides an exact replica of what you can find in Data Query.

  • How long do I have to wait before I can use Zuora Secure Data Share for Snowflake?

    Up to 21 days from the time you provide Zuora with your target Snowflake account details.

  • On what data model is Secure Share for Snowflake based?

    Secure Share for Snowflake is modeled based on the Data Query framework, designed to mirror Data Query’s object definition and adhere to its design principles. This strategic approach ensures that Secure Share maintains full compatibility with Data Query. However, Secure Share only supports a specific subset of Data Query objects. For more information on the detailed list of supported tables, see Tables and columns available in Snowflake.

  • How does Secure Share handle schema changes from Data Query?

    To maintain consistency within the system, Secure Share automatically updates its schema to mirror any changes made in Data Query. This process ensures that Secure Share remains aligned with Data Query, providing users with a seamless and accurate data sharing experience.

  • What are the best practices for querying in Secure Share to ensure efficient data retrieval?

    Zuora recommends that you use queries that specify particular column names instead of utilizing SELECT *. This practice helps prevent disruptions that could arise from schema changes, such as the addition of new fields. By selecting specific columns in your queries, you can enhance the accuracy and efficiency of data retrieval, ensuring that your operations remain streamlined and effective.

Availability

Zuora Secure Data Share for Snowflake allows Zuora, as a Data Provider to Snowflake Data Cloud, to securely share data with data consumers across different regions and cloud platforms. Cross-region data share is supported for Snowflake consumer accounts hosted on provisioned AWS or Azure regions.

The following table lists the provisioned clouds and regions in alphabetical order:

Cloud Region
AWS AP Northeast 1 (Tokyo)
AP Southeast 2 (Sydney)
CA Central 1 (Central)
EU Central 1 (Frankfurt)
EU West 1 (Ireland)
US East 1 (N. Virginia)
US East 2 (Ohio)
US West 1 (N. California)
US West 2 (Oregon)
Azure Australia East (New South Wales)
East US 2 (Virginia)
West Europe (Netherlands)

West US 2 (Washington)
GCP US Central1 (Iowa)
US East4 (N. Virginia)
Europe West2 (London)
Europe West4 (Netherlands)

Limitations

  • EU-US data transfer is not advisable because of legal restrictions. For these types of scenarios, please contact your Zuora account representative to discuss.

Zuora Revenue specific limitations

  • All objects available in the Zuora secure data share do not support custom display labels; all columns will have the standard label.
  • Revenue secure share data does not include all the custom objects available through the data query utility.
  • Pre-summary and waterfall data objects, available through BI Views, will not be available from revenue secure share.