Integration with Snowflake

Introduction

Outdoo’s platform analyzes your sales call data (e.g. recorded customer meetings) in real-time and deal data (pipeline and CRM opportunities) on scheduled intervals. Integrating this analyzed Outdoo data into your own data warehouse – whether Snowflake, Databricks, or Amazon Redshift – allows RevOps and data teams to unify conversation intelligence with other business data. 

This empowers deeper analysis of deal trends, rep performance, customer behavior, and pipeline risks within your existing BI tools and workflows. In short, connecting Outdoo to your warehouse enables you to correlate call insights and AI-derived deal metrics with CRM, product usage, and revenue data for more informed decision-making across your go-to-market operations.

Integration Overview and Supported Methods

Outdoo provides direct integration options to sync data to your warehouse without requiring third-party ETL tools. The following integration methods are supported:

Snowflake Data Share: If you use Snowflake, Outdoo can share a read-only Snowflake database containing your call/deal datasets via Snowflake’s Secure Data Sharing. This allows ready-to-query Outdoo data to appear in your Snowflake account with no data copy overhead. Updates in Outdoo are reflected in near real-time in the shared tables.

Direct Warehouse Connection (JDBC/ODBC): For Snowflake (as an alternative to data shares), Redshift, and Databricks, Outdoo can act as a data connector that writes data into your warehouse using official drivers. In this model, you create credentials for Outdoo (e.g. a database user or token) and Outdoo’s service pushes new call records and periodic deal updates into your tables on your behalf.

REST API Pull: Outdoo also offers RESTful APIs to retrieve call and deal data for custom integrations. Advanced customers can use this to script data pulls (e.g. via Snowflake External Functions or Databricks notebooks). This requires more custom development, but provides flexibility if the above methods don’t meet requirements.

Cloud Storage Stage (S3 or ADLS): As an alternative, Outdoo can export data files (e.g. in JSON format) to a cloud storage bucket that you own (such as Amazon S3). Your warehouse can then ingest from this “stage” location – for example, Snowflake or Redshift can bulk-load from S3, and Databricks can autoload files from cloud storage. This method is useful if direct database connections are not possible, but may introduce slight delays (e.g. daily batch file drops).

Each method emphasizes security and minimal maintenance. Next, we detail how to set up integration for each target warehouse, including authentication, connection configuration, table schema, and workflow examples.

Security and Authentication Setup

Before diving into platform-specific steps, ensure you’ve prepared secure access for Outdoo:

Create Dedicated Credentials: It’s recommended to provision a dedicated user/role in your data warehouse for Outdoo. For example, create a Snowflake user with a custom role, a Redshift database user (or IAM role), or a Databricks personal access token with limited scope. Grant only the minimum privileges needed (e.g. ability to create and write to Outdoo-specific schemas). This principle of least privilege protects your warehouse while allowing Outdoo to deliver data.

Network Access: If your warehouse is behind a firewall or VPC, you may need to whitelist Outdoo’s egress IP addresses or use a private connectivity method. (For instance, Redshift users should allow inbound access from Outdoo’s known static IP in their cluster’s security group settings.) Ensure any required VPC peering or security group rules are in place so Outdoo’s service can reach your warehouse.

API Keys & Tokens: When using REST API or Databricks connections, generate secure tokens. For Databricks, prefer using a Service Principal + token rather than a personal token for long-term integrations. Outdoo will securely store any tokens or secrets you provide.

Certificate and Encryption: All integrations use encrypted channels (HTTPS for APIs, TLS for JDBC). If using JDBC, you may need to provide SSL certificates or verify Outdoo’s connection meets your encryption standards.

Auditing and Revocation: Treat the Outdoo integration credentials as you would any service account: monitor their activity and rotate keys/tokens periodically. Outdoo will only access your warehouse for data sync operations, but you should revoke credentials if the integration is ever disabled.

With security considerations in mind, let’s proceed to the setup for each platform.

Snowflake Integration

Outdoo supports two integration methods for Snowflake: Snowflake Data Sharing (the easiest, no-maintenance option) and a direct Snowflake connector that pushes data via JDBC.

Method 1: Snowflake Data Share (Zero-Copy Integration) [Recommended]

Using Snowflake’s native data sharing is the most seamless way to get Outdoo data into your Snowflake account. In this model, Outdoo acts as a Snowflake data provider and shares a database containing your tables (e.g. OUTDOO_CALL_DATA and OUTDOO_DEAL_DATA). You, as the consumer, can then create a database from this share in your Snowflake instance. This approach has several benefits: the data is always up-to-date, no ETL or copying is needed, and data never leaves Snowflake’s managed storage.

Setup Steps:

Provide Snowflake Account Details to Outdoo: In the Outdoo admin interface (or via your Outdoo account manager), initiate a Snowflake data share integration. You will need to supply your Snowflake Account Locator (e.g. abc12345), and the Snowflake cloud region where your account is hosted (e.g. AWS us-east-1). Outdoo uses this to create a secure share target for your account.

Outdoo Shares the Data: Once configured, Outdoo will create a Snowflake secure share with the appropriate datasets for your organization. This share will include the analyzed call and deal tables (and any related tables). Outdoo manages all data loading into this share – as new calls are analyzed or deals updated, the share is updated in near real-time. Snowflake’s data sharing ensures the data is in a ready-to-query state in your account with no copy lag.

Accept the Share in Snowflake: In your Snowflake console, navigate to Data » Shares (or use Snowsight’s Private Sharing UI). You should see an incoming share from Outdoo. Create a new database in your account from this share (you can do this via UI or SQL). For example, in SQL:

-- List incoming shares (as ACCOUNTADMIN):
SHOW SHARES;
-- Create a database from the share:
CREATE DATABASE OUTDOO_DATA FROM SHARE OUTDOO_ORG.OUTDOO_SHARE_NAME;
 

Replace OUTDOO_ORG.OUTDOO_SHARE_NAME with the provider name and share name given by Outdoo (you can get these from the SHOW SHARES result). Once executed, a new database (e.g. OUTDOO_DATA) will appear in your account.

Grant Access to Users (if needed): The new database will come with pre-defined schemas and tables from Outdoo. You may want to grant SELECT access on these to your analytics roles. You can use Snowflake’s GRANT IMPORTED PRIVILEGES ON DATABASE ... TO ROLE ... for data shares. This allows your analysts to query the Outdoo data.

Verify Data Availability: You can now query the Outdoo tables as if they were local. For instance: SELECT * FROM OUTDOO_DATA.CALLS LIMIT 10; should return recent call records. Because this is a live share, you don’t need to schedule imports – any new call processed by Outdoo will automatically appear in this table shortly after analysis, and deal records will refresh on their schedule. Snowflake’s sharing ensures the data stays in sync.

Data Model in Snowflake: The shared Outdoo database will contain separate tables for call and deal data (and possibly supporting tables). For example, you may see a CALLS table with one row per sales call (including columns like Call ID, call datetime, participants, duration, sentiment score, key topics, etc.), and a DEALS table with one row per active deal (Deal ID, name, owner, stage, value, last update, Outdoo risk score, etc.). Outdoo might also include reference tables or JSON fields for detailed analytics (e.g. a CALL_TRANSCRIPTS table with full conversation transcript in JSON format per call). Check Outdoo’s documentation for the exact schema reference; it will detail all columns and any relationships (for instance, a call record may include a foreign key identifying the related Deal or Account). Since Snowflake is schema-on-read, all data types (VARIANT for JSON, etc.) are preserved as shared. You should design your analytics in Snowflake to leverage these tables directly or copy them into your own schemas as needed for transformations.

Example Workflow: Once the Snowflake share is active, your RevOps analysts and data scientists can immediately start joining Outdoo data with other warehouse data. For example, you could create a view that joins Outdoo’s DEALS table with your internal CRM accounts table to correlate call engagement (from Outdoo) with product usage or revenue numbers stored elsewhere. Because the Outdoo data is live, your dashboards and ML models can always use the latest conversation insights without building a custom ETL pipeline. This integration effectively turns Outdoo into a Snowflake data source that’s always in sync with your sales conversations and pipeline changes.

Method 2: Direct Snowflake Connector (JDBC Push)

If for some reason Snowflake Data Sharing is not viable (or if you prefer data to be materialized in tables you fully control), Outdoo can also integrate by writing data into your Snowflake account using a connector. In this method, Outdoo uses Snowflake’s official drivers to connect to your Snowflake and load data on your behalf. The outcome is similar (Outdoo tables end up in your Snowflake), but the setup and maintenance differ slightly:

Setup Steps:

Create a User and Warehouse for Outdoo: In Snowflake, create a dedicated user for the Outdoo integration (e.g. OUTDOO_LOADER). Assign it a role with permissions limited to a specific database or schema where data will reside. For example, you might create a database OUTDOO_DATA (if not using a share) and grant OUTDOO_LOADER rights to create and insert into tables there. Also ensure the role has usage on a warehouse (for loading). This user will be used by Outdoo’s connector.

Provide Connection Details: In the Outdoo integration settings, select the Snowflake direct connect option. Enter your Snowflake account hostname (e.g. xy12345.us-east-1.snowflakecomputing.com), the user name (OUTDOO_LOADER), password (or key pair), default database and schema for Outdoo data, and optionally a warehouse name. Outdoo will store these securely.

Initial Schema Setup: On first connection, Outdoo will log in and create the required tables in the target schema. Typically, it will create tables for calls and deals. If you already pre-created the schema or tables, ensure the Outdoo user has CREATE TABLE or INSERT privileges accordingly. Otherwise, grant the user the ability to create objects in the database. Outdoo’s service may also create temporary tables during load, so the TEMPORARY privilege is useful.

Data Loading Process: Outdoo will perform an initial full sync – fetching all available call records and deal records and loading them into your Snowflake. This might be done via batch inserts or using Snowflake’s PUT/COPY commands with cloud staging behind the scenes (the details are abstracted from the user). After the initial load, Outdoo will continuously or periodically push new data: call data is pushed shortly after each call is analyzed (near-real-time streaming of inserts), and deal data is pushed on its refresh schedule (e.g. once daily or every few hours). Because this is an automated connector, you don’t need to manually run any pipelines – Outdoo handles the upsert logic.

Verify and Use Data: You can monitor that new records appear in the Snowflake tables. Each call or deal record will typically have a timestamp indicating when it was last updated/inserted. It’s good practice to verify the row counts or a sample of data against Outdoo’s UI to ensure the sync is complete. Once verified, you can treat the data like any other Snowflake table in your analysis. You might want to put a Snowflake Task in place (optional) to copy or transform these raw tables into your enterprise schema if needed, but that’s entirely up to your data modeling preference – since Outdoo already provides an analysis-ready schema, many users will query it directly.

Note: The connector approach means data is stored in your Snowflake (incurring storage costs on your account), unlike the data share where storage stays on Outdoo’s side. The advantage, however, is that you can index or aggregate the data as you wish, and you’re not subject to Snowflake’s data sharing region constraints. Both methods ensure near real-time data availability. Choose the one that fits your IT policies (some companies prefer not to rely on an external share and instead want the data fully copied into their account).