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.

Zuora Secure Data Share for Snowflake – Object Schema Definition

Snowflake Secure Share is designed to closely align with the schema exposed through Data Query and provides users with secure, read-only access to Zuora data directly within their Snowflake environment.

Similar to Data Query, schema updates in Secure Share follow Zuora’s standard release lifecycle. When new fields are introduced, they are not automatically added to the Secure Share schema immediately. Each schema change undergoes an internal review process to evaluate downstream compatibility and ensure existing integrations and customer workloads are not impacted before the field is included in a subsequent release.

If a field is available in Data Query but is not yet present in your Secure Share schema, contact Zuora Support for assistance.

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. For Billing objects, Zuora supports multiple latency options, including 5 minutes, 15 minutes, 60 minutes, 12 hours, and 24 hours, allowing users to choose the sync frequency that best fits their needs.

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.

• AccountAgingDetail

• AccountAgingSummary

• ApplicationGroup

• ARTransaction

• BillingPreviewRunResult

• BillingRun

• BillingTransaction

• BookingTransaction

• ChargeMetrics

• Contactsnapshot

• CreditBalanceAdjustment

• CreditMemoAgingDetail

• CreditMemoApplication

• CreditMemoApplicationItem

• CreditMemoPart

• CreditMemoPartItem

• DailyConsumptionSummary

• DebitMemoAgingDetail

• Feature

• FXCustomRate

• GuidedUsage

• InvoiceAgingDetail

• InvoiceAdjustment

• InvoiceHistory

• InvoiceItemAdjustment

• InvoicePayment

• JournalRun

• MinCommitPeriod

• MinCommitTransaction

• NonSubscriptionInvoiceItem

• NotificationHistoryEmail

• OrderActionRatePlan

• OrderCallLog

• OrderContact

• OrderDeltaMrr

• OrderDeltaTcb

• OrderDeltaTcv

• OrderElp

• OrderItem

• OrderLineItem

• PaymentApplication

• PaymentApplicationItem

• PaymentGatewayReconciliationEventLog

• 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

• UnappliedPaymentAgingDetail

• ChargeMetrics

• UpdaterBatch

• UpdaterDetail

• Usage

• User

• ValidityPeriodSummary

Custom field data type handling

Although Snowflake Secure Share generally aligns with the schema exposed through Data Query, certain custom fields may have differences in exposed data types due to internal storage and processing behavior.

For both standard objects and custom objects, certain custom field types such as picklist (dropdown) and multi-select fields are internally stored as JSON in the source system. During schema replication to Snowflake Secure Share, JSON data types are mapped to the Snowflake VARIANT type.

In contrast, Data Query internally converts JSON-backed field values into string representations before returning query results. As a result, the same custom field may appear with different data types between Data Query and Snowflake Secure Share.

This behavior is expected and applies specifically to certain custom fields. The following table provides the Snowflake Secure Share Data type mapping information:

Here is an example. A custom picklist or multi-select field may appear as:

• TEXT in Data Query

• VARIANT in Snowflake Secure Share

This difference is expected and reflects the underlying JSON-based storage and schema mapping behavior used by Secure Share.

Custom field availability timing

For custom fields, Snowflake Secure Share uses a scheduled schema synchronization and share rebuild process.

When a new custom field is added in Zuora:

1. The schema notification system first detects the new field and adds it to the underlying Snowflake base tables.

2. An additional scheduled process then rebuilds the related views and Secure Share metadata.

Because the view/share rebuild process runs on a scheduled cadence, newly added custom fields may take up to 24 hours to appear in Snowflake Secure Share after creation.

In some cases, propagation may take longer depending on system processing or schema update conditions. If a custom field does not appear in Snowflake Secure Share, please contact Zuora Support for investigation.

This behavior is expected and applies specifically to newly created or updated custom fields.

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.

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.

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 Revenue objects to Snowflake by default. For Revenue objects, Zuora supports multiple latency options, including 60 minutes, 12 hours, and 24 hours, allowing users to choose the sync frequency that best fits their needs.

Tables for monitoring

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

• TAR_USAGE_HISTORY

• DATA_QUALITY_LOG