Rocketbrew Salesforce Integration
Overview
Rocketbrew integrates with Salesforce sandbox and production environments.
This guide will walkthrough how data is written and read from the CRM, how to setup logic specific to your CRM and validate your setup.
This guide is written for sales operations teams with admin/integration user CRM access.
Setup Prerequisities
The integration must be performed by a Salesforce Admin or a seat with the following permissions (like an integration user).
Read/Create/Edit on the Standard Objects:
- Accounts
- Contacts
- Leads
- Opportunities
For Administrative Permissions:
- API Enabled
- View Setup and Configuration (used to see API quota limits)
- Use CRM Analytics
- Modify Metadata Through Metadata API Functions
- Update Email Messages
- Edit Tasks
How to Find Salesforce Field Mapping
For this integration, it’s important to use the exact API names specified in Salesforce.
To find these API names:
- Navigate to Object Manager in Salesforce
- Search for relevant object (ie. Lead)
- Go to Fields and Relationships
- Use the API Name for mapping
What to Expect Once Integration is Completed:
- Rocketbrew will exclude working any leads/contacts/accounts that should not be worked
- Rocketbrew will create leads/contacts and associate them with accounts according to your standard Salesforce data flow
- Rocketbrew will write back all necessary fields and activities so the sales team can access conversations that led to a meeting and have accurate reporting
- Users will be to setup new campaigns and source leads from Salesforce
How to Connect Your CRM
You can integrate to either the sandbox or production environment using the integration user credentials. The integration user should contain “rocketbrew” in the name.
Once you test the full workflow in the sandbox environment, you’ll be able to automatically copy the inputs and test in the product environment.
How to Write Data to Salesforce
This section lets you specify what data to write back to Salesforce. The objective is to preserve your regular data flow and write back high quality data in an automated way.
Object Selection
There are three ways to write data to Salesforce:
- Only use the leads object - Best if you want sales to be responsible for converting qualified leads into Salesforce contacts.
- Only use the contacts object - Best if you only use the contacts object.
- Use both the lead and contact object - Best if you want all prospects without accounts to sync as leads and prospects with accounts to sync as contacts. This is the most common implementation.
Object Mapping
For each Rocketbrew field, select the corresponding Salesforce field to sync the data. If needed, you can create a new field in Salesforce and this will populate automatically in Rocketbrew.
The Lead Source and Lead Source Detail Rocketbrew fields are especially important so you can attribute conversations and meetings booked back to Rocketbrew. By default, Rocketbrew will use the static value "Rocketbrew" if not specified. You can use custom mappings if you wish to specify a different value or use a different Salesforce field for reporting purposes.
You can verify this section was done correctly in the last step, "Verify Settings", which write sample data to Salesforce using the mapping created here.
How to Setup Rocketbrew Logic
This section helps Rocketbrew define basic logic like when to start and stop prospecting and the relationship between objects.
For each section, you can answer the defined question by picking the value that best answers the question or typing a custom field. You can click "Verify this Rule" for each question to ensure the data being pull correctly answers the question.
How to Specify Exclusions
This section allows you to specify records to exclude Rocketbrew from working.
You can do this by defining current customers, open opportunities, leads/contacts with sales activity and/or with other custom fields with rules.
Creating Conditions
For each rule, you can set up multiple conditions and groupings depending on complexity.
Conditions can be joined by AND or OR operators. The first condition is the base object meaning future conditions will refer to this base object. You should define all possible ways that the agent could reach this exclusion.
Groupings are used to create more complex logic. Groupings can be joined by AND or OR but this selection affects all groupings.
Conditions are best used for rules within an object and groupings are best used for rules between objects. For example, you can use conditions to define multiple rules within the contacts object, whereas you would use groupings to differentiate between rules for the contacts object vs account object.
Defining Matching
For every rule, you'll need to specify fields Rocketbrew will use to match leads to your conditions. Typically, Rocketbrew will use:
- Email and/or LinkedIn field to match to leads and contacts
- Website field to match to accounts
This is the reason we want to separate objects into their own rules instead of using a long list of conditions.
Verifying Data
Once a rule is completed, you can verify the rule by clicking “Verify This Rule”. This will pull in example records to exclude based on your specifications.
You can check the correct exclusion data is being pulled and make changes as needed.
How to Source Leads From Salesforce
By default, Rocketbrew will source net new leads so this section is optional. This section helps Rocketbrew source leads from Salesforce so it can work MQLs, closed lost, target accounts and more.
Source People - This lets you define specific leads or contacts Rocketbrew should work.
Source Companies - This lets you define accounts that Rocketbrew should work.
You can then select which object to source from to define where Rocketbrew can find these leads.
Source People: Best for targetted inbound
- Lead Object - Work these leads
- Contact Objection - Work these contacts
Source Companies: Best for leveraging inbound into an outbound motion
- Account Object - Find net new leads/contacts associated with this account
Similar to before, you’ll need to specify industry, email, company name, job title and LinkedIn URL so Rocketbrew can match net new leads to your specifications.
Similar to the Exclusions sections, you can create rules with conditions and groupings to specify which leads to pull in. You can verify each rule to ensure it’s working as expected.
These lead sources will show up in Campaign so users can select this lead source for their campaign.
How to Send Test Data to Veriy Implementation
Once all fields are completed, you can verify your work by generating a test link to send sample data to your sandbox or production instance.
Check that all expected fields and logic are written back correctly. If you see anything incorrect, you can go back into the previous sections to make changes and verify again when ready.
Standard Rocketbrew Fields
On top of the fields specified in “Write to CRM”, Rocketbrew will also write back the following standard Rocketbrew fields:
1. RB Status: Rocketbrew lead status
- Pending Connection: Outreach has been initiated (e.g., a LinkedIn request sent), but the lead has not yet accepted or responded.
- Connected: The lead has connected on LinkedIn, but has not yet responded.
- Awaiting Response: The lead has been contacted via LinkedIn or email, but they have not responded.
- Response Ready: The lead has responded, and Rocketbrew is crafting a tailored reply based on their message.
- Conversing: Rocketbrew has responded to the lead's response via email/LinkedIn and is waiting for their reply.
- Out of Office: The lead is out of office. The model will resume outreach when the lead is back in office
- Attention:
- Attention:Needs Information: The lead has responded and Rocketbrew is searching for a response. If no response can be generated from the knowledge base, you will be notified to provide more information.
- Attention:Not Interested: The lead has conveyed that they are not interested but there may still be room to follow up.
- Attention:Initiating Call: Rocketbrew is in the process of scheduling a meeting with the lead.
- Closed
- Closed Accepted: The lead has converted successfully (i.e., booked a meeting).
- Closed Unsubscribed: The lead has opted out of further communication, and no additional follow-ups will occur.
- Closed Rejected: The lead is no longer being pursued because they have explicitly declined interest.
2. RB Campaign Name: The campaign title that the lead is associated with. This campaign is created from Rocketbrew by the user.
3. RB Campaign Type: The specific campaign type that the lead is associated with, denoting which channel the campaign is targeting.
- Includes: LinkedIn, email, multichannel (LinkedIn and email)
4. RB Sequence Stage: The sequence stage of a Rocketbrew message. Each sequence stage also includes a number denoting which message the sequence is on.
- Includes: Sent Outreach, Sent Followup # 1, 2, 3, etc..,
5. RB Last Activity: Timestamp marking the last activity from Rocketbrew.6. RB Conversation: Formatted messages and conversation sent to and from Rocketbrew and the associated leads.
API Usage and Limits
Rocketbrew generally uses up to 9,000 requests per active sender daily. For a team of ten, this scales to 90,000 requests daily. There can be some variation in requests depending on quantity and complexity of conditions set up in the CRM configuration.
The main processes are:
Checking for Exclusions and Syncing Activities: Up to 6,000 requests per sender daily. This is used to check for existing customers, open opporutnitites and other custom exclusions.
Polling for CRM changes: Up to 1,000 requests per sender daily. This is used to check the CRM for changes for leads that are mid sequences (ie. Rocketbrew is about to send a third message but has this account become a customer).
Pulling Leads: Up to 1,000 requests per sender daily. This is used to pull in leads and contracts when Rocketbrew is setup to work MQLs, target accounts, closed lost, etc...
Buffer: Up to 1,000 requests per sender daily. This is used to account for mass CRM changes (ie. clean up) or instances where leads are being heavily disqualified by Rocketbrew.
For further support or detailed troubleshooting, please contact Rocketbrew’s support team.
FAQ
Net new leads: A lead whose email address is not already present in your Salesforce CRM.
Net new accounts: A lead whose domain (e.g., company website) is not already associated with an account in your Salesforce CRM.
Yes this can be setup as a custom rule in the Exclusion process
Yes Rocketbrew can exclude leads with custom exclusion rules or with activity in the past x number of days.
If all data from other tools (e.g., Outreach) is written back to Salesforce, Rocketbrew will apply the same exclusion rules automatically.If data is not shared between tools, a common approach is to divide accounts between Rocketbrew and other tools based on size, product, or geography.
Defining net new leads as those whose email addresses are not in the CRM.Defining net new accounts as those whose domains are not in the CRM.Matching leads to the correct account or creating new accounts if necessary.
You can use the standard Rocketbrew fields and your custom write fields to access the data in Salesforce. For example, you can create Salesforce campaigns to track Rocketbrew meetings booked. Our app also has basic analytics to understand volume, conversion and dropoff reasons.
We'd love to help. You can contact us at our email - support@therocketbrew.com. We will get back to you in the next few hours.
