Integration with Amazon Redshift

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:

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 data from this “stage” location – for example, Snowflake or Redshift can bulk-load data from S3, and Databricks can auto-load 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 outline the steps 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., the 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, it is recommended to use a Service Principal and 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.

Amazon Redshift Integration

Integrating Outdoo with Amazon Redshift allows your organization to analyze conversational and deal intelligence within your Redshift data warehouse, unifying it with the rest of your business data on AWS. Outdoo’s Redshift integration uses a secure, role-based approach to push data into your Redshift cluster. This typically involves Outdoo using AWS IAM roles and S3 for staging data, then loading into Redshift, as this method is both secure and scalable. Setup Steps:

1. Create a Redshift User or IAM Role for Outdoo: We recommend using Redshift’s IAM integration for security. In your Redshift cluster, create a new database user (e.g. outdoo_writer) that will own the Outdoo tables. You can disable the password for this user and use IAM authentication instead. For example, run:

CREATE USER outdoo_writer PASSWORD DISABLE; 

GRANT CREATE, TEMPORARY ON DATABASE <your_database> TO outdoo_writer;
 

The CREATE privilege allows Outdoo to create schemas/tables, and TEMPORARY allows usage of temp tables during loads. You can later restrict or grant more as needed (Outdoo will create its schema on first sync, so these rights are needed initially). If you prefer not to use IAM auth, you could set a password and give it to Outdoo securely, but using IAM roles is more secure (no static credentials).

1. Whitelist Outdoo’s IP (if needed): If your Redshift is in a VPC with restricted access, add an inbound rule to its security group to allow connections from Outdoo. Outdoo will provide a static IP address that you can whitelist. Allow this IP on the Redshift port (5439 by default) so Outdoo can connect.
2. Set Up an S3 Staging Bucket: Create an S3 bucket that will be used for staging data files during the load process (e.g. my-company-outdoo-stage). Outdoo will temporarily store data files here for Redshift to COPY from. The bucket should be in the same AWS region as your Redshift cluster for optimal performance. No public access is needed; this can be a locked-down bucket.
3. Create an IAM Role for Outdoo: In AWS IAM, create a role that Outdoo’s service can assume to get access to your S3 bucket and Redshift. Set up a trust policy on this role to trust Outdoo’s AWS account. (Outdoo will provide their AWS Account ID and an external ID or role ARN; for example, Outdoo provides an ARN like arn:aws:iam::123…:role/… for trust.) 

Attach a permissions policy to this role that allows the following actions:

• S3 Access: Permit s3:PutObject, GetObject, DeleteObject on the staging bucket (and ListBucket on the bucket itself) so Outdoo can upload and clean up data files.
• Redshift Credentials: Permit redshift:GetClusterCredentials for the Redshift cluster, user, and database that Outdoo will use. This allows Outdoo to generate temporary login credentials for the outdoo_writer user via AWS (so you don’t have to share a password).
• (Optionally, you could also allow direct redshift:Copy if using COPY with an IAM role, but GetClusterCredentials is typically enough alongside the Redshift cluster’s own permissions.)
  Create the role with these policies and note the Role ARN. Outdoo will use this ARN to assume the role at runtime.

1. Share Connection Details with Outdoo: In the Outdoo setup interface for Redshift integration, you will provide: the Redshift cluster endpoint (host and port), database name, the DB user (outdoo_writer), the target schema name for Outdoo data (you can specify one; Outdoo will create it on first sync, e.g. outdoo_data), the S3 bucket name, and the IAM Role ARN that Outdoo should assume. This information allows Outdoo to establish a pipeline into your Redshift.
2. Outdoo Data Loading Process: Once configured, Outdoo will connect to your Redshift using the IAM role. The typical process for each sync batch is: Outdoo extracts new or updated data, writes it to a file (or set of files) in the S3 staging bucket, then issues a Redshift COPY command (over JDBC) to load the data from S3 into the target table. Since we provided the IAM role and bucket, the COPY can use IAM_ROLE '<Role ARN>' to authorize S3 access without credentials. Outdoo may create a new schema (if not existing) on first run – as noted, the outdoo_writer user will create the schema if needed. Subsequent loads might use UPSERT logic if the table has a primary key (Redshift doesn’t natively support MERGE easily, so Outdoo might implement upserts by staging data in a temp table and merging, or by maintaining a “soft delete” flag for updated records). Outdoo’s documentation indicates that they handle history tracking and soft deletes in the data, so if a deal is removed or a call is redacted, they will mark it accordingly rather than fully deleting the row.
   • Call Data: As calls are analyzed, those records are queued for immediate sync. Expect that within minutes of a call finishing, a new row will appear in the calls table in Redshift. Outdoo might do this one call at a time or in small batches.
   • Deal Data: Deal updates (from your CRM) are aggregated and sent on a schedule (e.g. nightly). So the deals table in Redshift will refresh after the scheduled sync runs. Outdoo likely replaces or updates each deal record with the latest status once per interval. If they provide a history table (like deal_history), that would log changes over time as well.
3. Validation: Check your Redshift cluster for the new schema and tables after the first sync. For example, run SELECT COUNT(*) FROM outdoo_data.calls; to see number of call records. You can also verify a specific known deal or call appears correctly. It’s a good idea to monitor the Redshift WLM or Query Monitoring rules during initial loads in case any tweaks are needed (e.g. increasing work_mem or slot count if large volumes are loaded). Typically, Outdoo loads data in manageable batches to avoid impacting your cluster performance significantly.

Data Schema in Redshift: The schema of the tables will be similar to what was described for Snowflake/Databricks. One difference is data types – for example, JSON fields from Outdoo may be stored as VARCHAR (since Redshift does support SUPER type JSON now, Outdoo might leverage that if your cluster is new enough, or they could store JSON as text). Also, Redshift may not have as flexible semi-structured storage as Snowflake, so some nested data might be flattened or delivered in separate tables. Key tables likely include: calls, call_participants, call_transcripts (if transcripts are provided – possibly as JSON text), deals, deal_stages or deal_history (if tracking stage changes or AI scores over time), and possibly reference tables for users (sales reps) or accounts. The Outdoo Redshift database design should be documented in Outdoo’s reference – be sure to review column definitions (e.g. data types and any sort of encoding/compression applied). You can apply compression encoding after initial load for efficiency, though Outdoo might handle that by issuing COPY with COMPUPDATE so that Redshift assigns compression. Also note that Outdoo might include an updated_at timestamp column in each table to indicate the last update time, and an is_deleted boolean or similar for soft-deleted records. Use these to manage incremental models or to filter active records. Example Workflow: With Outdoo data in Redshift, you can join it to all your existing data in Amazon Redshift. For instance, your BI team using Amazon QuickSight or Tableau can query Redshift to create a unified dashboard: combining Outdoo’s call sentiment and talk-time metrics with your sales pipeline data to identify risky deals. You could write SQL queries that join the calls table to your Salesforce opportunity table (if that’s also loaded in Redshift) on a common deal ID, to correlate call frequency and sentiment with deal win rates. Additionally, because the data is now in Redshift, you can take advantage of Redshift’s scalability to run complex queries on large volumes of call transcript data (for example, using Redshift Spectrum, if transcripts are stored in Parquet on S3, or using the Redshift SUPER data type to query JSON). The integration ensures that as new calls happen and deals change, these Redshift-hosted tables stay up-to-date without manual effort.

Data Schema and Table Design Considerations

Regardless of the warehouse, the analyzed Outdoo data will typically be structured in a star schema-like format, centered around two fact tables: Calls and Deals. Below, we outline the typical schema design and how you might integrate it with your own schemas:

• Calls Table: Each row represents a single sales call or meeting. Key fields might include: call_id (unique identifier), call_timestamp (date/time of the call), duration_seconds, caller(s) and callee(s) identifiers (e.g. rep and customer, possibly as IDs or names), and outcome or disposition fields. Crucially, it will include analysis results such as sentiment_score, talk_ratio_percent (percentage of time the rep talked vs customer), interactions_count (back-and-forth exchanges), keywords or topics detected, and possibly a link to the transcript. The transcript might be stored as a separate JSON blob (in a call_transcripts table keyed by call_id) or as a text field in the calls table. For example, Outdoo’s data model includes a CALL_TRANSCRIPTS table with a JSON of who said what when. Outdoo’s schema likely follows suit. There may also be a call_participants lookup table if needed (listing each participant’s name, email, title, etc., linked to call_id).
  Integration tips: The calls table can be joined to your CRM’s contacts or users tables via email or employee ID to get more info on participants. Ensure you understand what identifier Outdoo uses (e.g. email addresses for participants, which should match your internal directory or CRM emails). If you want to analyze calls by account or opportunity, use the relationship to deals (see below).
• Deals Table: Each row represents a sales opportunity or deal (likely synced from your CRM). Fields include deal_id (could be CRM Opportunity ID), deal_name, owner (sales rep), account_name or ID, stage (current pipeline stage), amount, close_date, forecast_category, etc., essentially a mirror of key CRM fields at time of sync. Outdoo enhances this with its own analytics: for example, an AI-generated deal_health_score or likelihood-to-close (as some platforms provide), last_call_date (when the last conversation happened), next_step text or other intelligence notes. There might also be fields aggregating call data per deal (e.g. total_calls, avg_call_sentiment, last_call_participants). Some of these could be in the main deals table or in a supplemental table. Additionally, if Outdoo tracks changes over time, you might have a deal_history table or a deal_stage_history table capturing each stage change timestamp, or a forecast_submissions table (if tying into forecast data).

Integration tips: The deals table will typically have a one-to-many relationship with calls (one deal links to many calls). In Outdoo’s data, a deal_id or external CRM ID may be present in the calls table to join them. Use that to combine deal attributes with call details in your analyses. For example, you can query “calls where deal_stage = X” by joining calls to deals on deal_id. Be mindful of how Outdoo handles deals that are no longer active – they might remain in the table with a closed status, or be dropped after a while. Outdoo likely uses a soft-delete flag for deals that have been deleted or set to lost/won outside the active pipeline. You can filter on status or is_deleted as appropriate for your reporting.

• Additional Tables: Depending on your Outdoo product package, you may have other useful tables. Examples:
  • Users/Employees: A table listing the sales reps or users in your Outdoo system, with their user ID, name, email, role, team, etc. This can help join calls.rep_id to a rep name or region.
  • Accounts: If Outdoo syncs account info, a table of accounts (company names, industry, etc.) could be provided, allowing analysis at account level.
  • Call Metrics or Topics: Some conversation intelligence platforms provide tables like CALL_TOPICS (each row is a topic mentioned in a call, with call_id, topic_name, timestamp) or CALL_SENTIMENT_TIMELINE (sentiment over the timeline of the call). If available, these can enable more granular analysis (e.g. identifying at what point in calls certain competitors are mentioned).
  • Deal Forecast/Scoring: Tables such as DEAL_LIKELIHOOD_SCORES (one row per deal with the latest AI score and category) or FORECAST_SUBMISSIONS/FORECAST_TARGETS (if Outdoo integrates with sales forecasts). These are more advanced but can be very useful for sales ops analysis in the warehouse.

All tables are designed to be analytics-ready, meaning they are already organized in a way to make common analyses straightforward (e.g. one row per call or per deal with all relevant info, rather than needing complex parsing). When integrating into your warehouse, consider if you want to materialize these into your own schema. For example, some companies will ETL the Outdoo shared tables into their own schema for consistency (especially if combining with other sources into a single schema). However, since we aim for no-ETL here, you can also use them as provided. Use views or data virtualization if you need to rename fields or join with other data for ease of use. Finally, ensure that you handle incremental updates properly. Outdoo’s integration will take care of inserting new records and updating existing ones. But if you are further transforming the data (say, combining multiple sources), design your pipelines to be incremental as well. Leverage fields like updated_at or Outdoo’s own change tracking. For instance, if Outdoo marks a deal as is_deleted=true, you may want to exclude it from active pipeline metrics in your queries.