Skip to main content

​
Supported Warehouses

​
Secure Data Sharing (Preferred)

You can request our account details (identifier and region) and use one of the below options to give us the targeted access to the data you want to share.

​
Direct Share

If we are in the same region, you can configure a data share using Snowflake’s instructions here.Note: Creating a replication will not work since we are two separate orgs.

​
Private Listing

If we are in different regions, you can configure a private listing using Snowflake’s instructions here.Note: This route may incur additional egress costs outside the ones you would normally get:
Snowflake creates one secure share area for an organization to manage auto-fulfillment to a region and associates billing costs with that area. Because of that, the costs associated with auto-fulfillment are attributed differently when compared to manual database replication costs.
Full explanation per Snowflake’s docs here.

​
Service User (Alternative)

You can instead create a service user and grant it READ access on the tables you wish to connect. We will need the following information to finish configuring the integration:
  • host
  • username
  • private key (or password)
    • Note: Snowflake will disallow passwords for all service users by October 2026 (full docs here).
  • role
  • database
  • schema
  • warehouse (optional)
We connect to Snowflake using the following IP addresses, which you may need to whitelist in your Snowflake account:
34.212.54.206
35.162.156.254
44.241.212.223
44.240.0.247
To connect with BigQuery:
1
Add the service account email address to your Google Cloud IAM policy and grant it the bigquery.jobUser (BigQuery Job User) role. This will allow us to run queries on your behalf.
2
Share the dataset containing tables, like those described below, with our service account email address and grant it the bigquery.dataViewer (BigQuery Data Viewer) role. This will provide us with read-only access to the datasets you want to share.
To connect with Amazon Redshift using Datashare:
You will need to have the appropriate permissions to create a datashare in your Redshift cluster. Contact your Redshift administrator if you cannot create a datashare.
Please refer to the Amazon Redshift Producer actions for more information on creating and sharing datashares.
1
Ask your primary contact at Reforge for the Reforge Namespace ARN and AWS account ID. You will need these to authorize Reforge’s AWS account to access your datashare.
2
Create a datashare in your Redshift cluster:
CREATE DATASHARE reforge_<your company name>_datashare;
3
Add objects to your datashare. You can add entire schemas or specific tables and views:
-- Add schema
ALTER DATASHARE <datashare name> ADD SCHEMA <schema name>; -- you may need to create the schema first

-- Pick specific items
ALTER DATASHARE <datashare name> ADD TABLE <table name>;
ALTER DATASHARE <datashare name> ADD VIEW <view name>;
4
Make the datashare visible cross-account:
ALTER DATASHARE <datashare name> SET PUBLICACCESSIBLE TRUE;
Note: This doesn’t expose your data publicly. It only allows consumption by authorized accounts.
5
Grant usage access to the datashare to the Reforge AWS account:
GRANT USAGE ON DATASHARE <datashare name> TO NAMESPACE <Reforge Namespace ID>; -- The Namespace ID is the last part of the Namespace ARN
6
Authorize Reforge’s AWS account to access your datashare:
aws redshift authorize-data-share \
  --data-share-arn <your datashare ARN> \
  --consumer-identifier <Reforge AWS account ID>
Replace the ARN with your datashare ARN and the consumer-accounts value with the Reforge AWS account ID provided to you by your Reforge contact.You can also do this via the Redshift console under Datashares → <datashare name> → Authorize.
7
Provide the following information to your primary contact at Reforge:
FieldExample
Datashare ARNarn:aws:redshift:us-east-1:111122223333:datashare:reforge_company_datashare
Redshift namespace ARNarn:aws:redshift:us-east-1:111122223333:namespace:prod-ns-1
List of schemas / tables / views includedpublic.conversations, public.latest_tickets_v

​
Data Models

We support several schemas and relationships between tables. With each of the schemas defined below, you can also provide a list of additional column names that you would like to be included on the respective fields as metadata. A few examples of common additional fields are for feedback or conversation messages, a “version” number that the feedback refers to, or for Contacts, a “plan” or “subscription tier”. When working with the team to connect to your data warehouse, simply share with us fields beyond those defined below that you would like to have included!

​
Standalone Feedback

Standalone feedback are singular items of feedback, such as a review or a single response to a question.
Field NameRequiredTypeDescription
idYesSTRINGUnique identifier for the feedback record
descriptionYesSTRINGThe main feedback content
created_atYesSTRINGWhen the feedback was created
updated_atYesDATEWhen the feedback was last updated
sourceNoSTRINGThe source of the feedback, e.g. “HUBSPOT”
titleNoSTRINGOptional title for the feedback
contact_idNoSTRINGOptional identifier linking to a contact

​
Conversation

A conversation is a collection of conversational feedback messages. For example, a chat log between a support agent and a user.
Field NameRequiredTypeDescription
idYesSTRINGUnique identifier for the conversation
titleNoSTRINGOptional title for the conversation
sourceNoSTRINGThe source of the feedback, e.g. “HUBSPOT”
created_atYesSTRINGWhen the conversation was created
updated_atNoDATEWhen the conversation was last updated

​
Conversation Message

These are the individual messages within a conversation, and should be linked to a conversation by the conversation_id field.
Field NameRequiredTypeDescription
idYesSTRINGUnique identifier for the message
created_atYesDATEWhen the message was sent
updated_atNoDATEWhen the message was last updated
conversation_idYesSTRINGID of the conversation this message belongs to
contentYesSTRINGThe message content
incomingYesBOOLEANWhether the message was sent by an external user
contact_idNoSTRINGOptional identifier linking to a contact

​
Contacts

Contacts are the users of your product.
Field NameRequiredTypeDescription
idYesSTRINGUnique identifier for the contact
nameYesSTRINGThe contact’s full name
emailYesSTRINGThe contact’s email address
account_idYesSTRINGThe account the contact belongs to
created_atYesDATEWhen the contact was created
updated_atYesDATEWhen the contact was last updated

​
Accounts

Accounts are the companies that your contacts belong to.
Field NameRequiredTypeDescription
idYesSTRINGUnique identifier for the account
nameYesSTRINGThe account’s name
domainYesSTRINGThe account’s domain
contract_valueNoNUMBERThe account’s contract value
created_atYesDATEWhen the account was created
updated_atYesDATEWhen the account was last updated

​
Custom Tables

Sometimes, you may not be able to map your data to the existing schemas. In this case, you can share your own, existing tables. This will require custom engineering work on our end, so understand that time will be required to support this. If you are providing custom tables, then what we will need to do is to effectively write custom queries and map the data to schemas above on our end. Given that, helping us understand how to do that mapping will expedite the process and lead to better, faster results for getting your data into Reforge Insights. When sharing custom table information, please provide the following: 1. Table Information The table names, column names, column types, and a description of the data in each column. For example: Customer Table: client_organizations
Column NameColumn TypeDescription
org_idSTRINGThe unique identifier for the organization
org_nameSTRINGThe name of the organization (maps to account name)
org_websiteSTRINGThe organization’s website domain (maps to account domain)
annual_revenueNUMBERThe organization’s annual contract value
creation_dateDATEWhen the organization was created (maps to account created_at)
last_modifiedDATEWhen the organization was last updated (maps to account updated_at)
Customer Table: client_users
Column NameColumn TypeDescription
user_idSTRINGThe unique identifier for the user (maps to contact id)
full_nameSTRINGThe user’s full name (maps to contact name)
user_emailSTRINGThe user’s email address (maps to contact email)
org_idSTRINGForeign key to client_organizations (maps to account_id)
signup_dateDATEWhen the user was created (maps to contact created_at)
profile_updatedDATEWhen the user profile was last updated (maps to contact updated_at)
Customer Table: support_tickets
Column NameColumn TypeDescription
ticket_idSTRINGUnique identifier for the support ticket (maps to conversation id)
opened_atDATEWhen the ticket was created (maps to conversation created_at)
closed_atDATEWhen the ticket was closed (maps to conversation updated_at)
user_idSTRINGUser who opened the ticket (maps to contact_id)
org_idSTRINGOrganization the ticket belongs to
statusSTRINGCurrent status of the ticket
prioritySTRINGPriority level of the ticket
Customer Table: ticket_messages
Column NameColumn TypeDescription
message_idSTRINGUnique identifier for the message (maps to message id)
ticket_idSTRINGForeign key to support_tickets (maps to conversation_id)
message_textSTRINGThe content of the message (maps to message content)
sent_timeDATEWhen the message was sent (maps to message created_at)
edited_timeDATEWhen the message was edited (maps to message updated_at)
from_customerBOOLEANWhether the message was from the customer (maps to incoming)
user_idSTRINGUser who sent the message (maps to contact_id)
2. Relationship Information If there are any relationships between the tables, please point out how the tables should be joined, as in which column on table A should be joined with which column on table B. 3. Data Mapping An explanation of how you would expect the data to map to the schemas defined above. If you are interested in sharing custom tables, please reach out to your primary contact at Reforge.