Introduction to the Fullcast + Salesforce Integration
This article provides an overview of how the Fullcast to Salesforce integration is designed. Understanding the integration between Fullcast and Salesforce will help you optimize the configuration to best align with the rhythm of your business. If you are in an IT or CRM Admin role, this overview will help you understand how Fullcast will align with your data model and interact with your other systems. If you are working in the app to manage Plans, this article will help you understand various options and settings to sync the system and your processes.
Data Model, Job Types, and Common Scenarios
This article begins with a description of the import-export data model, then provides a breakdown of job types, and finally, gives examples of common scenarios to demonstrate how the import-export will execute specific changes, given the settings you select.
IN THIS ARTICLE:
Import from Salesforce to Fullcast
- Objects: All records for the Account, User, Product, Opportunity, and Opportunity Line Items Objects are imported into the Fullcast System.
- Required Fields: Fullcast’s standard functionality requires access to a specific set of fields from those objects. 📋 For more information, refer to this article section on Salesforce Integration Data Requirement.
- Additional Fields: Beyond the standard import fields, users can control what fields are imported into Fullcast by selecting them in the Fields and Entities Settings page. 📋 For more information, refer to the articles Import Jobs and Creating and Editing Field/Custom Field Values in the Entity.
- Alignment: Data that is imported from Salesforce into Fullcast gets written to various places. Below is an overview of the primary location where each Salesforce record type’s data will be housed in Fullcast. That is, if you access a Territory Plan, the data table will display Account records, whereas the data table in a Product Plan will display Product records.
| Salesforce Records → | Fullcast Import Location |
| Account records | Territory Plan(s) |
| User records | Team Plan(s) |
| Product records | Product Plans(s) |
| Opportunity / Opportunity Line-Item records | Custom Metrics in Any Plan |
| Selected data from any objects related to those above | Custom Metrics in Any Plan |
Export from Fullcast to Salesforce
- Objects: All records for the Fullcast Custom Objects (Fullcast GTM, Territory Member, Product Group Member, Team Member) are exported to the Salesforce System.
- Required Fields: Fullcast’s standard integration exports all fields on these records into Salesforce.
- Alignment: Data that is exported from Fullcast into SFDC gets written, primarily, to the Fullcast Custom Objects that are a part of the Managed Package. Below is an overview of the Fullcast Custom Objects and what information they contain.
📋For more information, refer to the article Export Jobs.
| Fullcast-Updated Objects | Information |
| Fullcast GTM Object | Captures the hierarchical territory structure created in Fullcast |
| Account Team Member | Captures coverage assignments from a Territory Plan and writes it to the Account Team Object in Salesforce |
| Fullcast Member Objects | These records link the Fullcast GTM record to a specific Salesforce Record |
|
Links Fullcast GTM records to Account records in Salesforce |
|
Links Fullcast GTM records to Product records in Salesforce |
|
Links Fullcast GTM records to User records in Salesforce |
NOTE: Account Team/Account Team Member (Standard Salesforce Object) and Team Member (Fullcast Custom Object) are different
Examples of Fullcast Custom Object Records
- Fullcast GTM Record - captures the Plan structure that has been created in Fullcast. Territory, Team, and Product Plans impose hierarchical structures. Thus, every Node in a Territory, Team, or Product Plan will have its own Fullcast GTM Record. The example record below shows the Fullcast GTM Record for a Territory called AMER_MM_West_3
- Territory Member - Links the Fullcast GTM Record to an Account. The example record below shows APAC_Korea_Territory 5 as the Fullcast GTM and Coupang as the Account.
- Team Member - Links Fullcast’s Coverage Assignment(s) to an Account. The example below shows the Salesforce User Celvva Vetrivelu's role as a Solutions Engineering team in the Fullcast GTM.
- Product Group Member - Links Fullcast GTM records to Product records in Salesforce. The example below shows an item in the Car Subscription Product Group, which is in the Manufacturing Fullcast GTM.
Job Types - Full vs Partial and Scheduled vs Ad Hoc
- Import Jobs
- A Full Import brings all records from SFDC into Fullcast
- A Partial Import brings only CHANGED records from SFDC into Fullcast
- Export Jobs
- A Full Export looks at every record and pushes all the data - Territory Structure (Fullcast GTM Record), Territory Assignments (SFDC Account Team Object), and Fullcast Territory/Team/Product Member Objects)
- A Partial Export looks only at records with changes and pushes those to SFDC – specific logic: look at last modified date, which is a Fullcast system field, not to be confused with the last modified date in salesforce, and we compare that date against the last time the job was run. If the modified date is greater than the last time the job ran, then we export. It is a date:time field.
- Ad Hoc jobs can be full or partial.
- Scheduled jobs are always partial.
- They occur at a set time, this is usually overnight, but this is up to the tenant admin.
- They serve to keep the two systems in sync.
- Most Common Scheduled Job Process:
- The scheduled import happens at a set time.
- The import triggers Auto Rerun rules to execute.
- The scheduled export happens at a set time after the import time, so that the import can complete before the export occurs.
An Alternative Scheduled Job Sequence
While the most common scheduled job setup is one import and then one export, jobs can also be scheduled as follows: Import, Export, Import – where the final Import serves to reconcile any differences that are triggered by the Export from Fullcast to Salesforce.
A common example of how differences occur would be:
- An Account changes from a Prospect to a Customer, when this change is detected during the Import to Fullcast, the Fullcast rules move the account to a new territory. When the new territory is exported into Salesforce, a flow detects the territory change and updates the account owner.
If the process concludes here, there will be a discrepancy between Fullcast and Salesforce for the Account owner - until the next scheduled Import. However, if you decide to run a second import as the final step of a scheduled import/export process, this discrepancy won’t occur. As the Account owner would be correctly imported during the second scheduled import.
Factors That Impact What Happens During Import and Export
Here are the main settings and factors that impact what happens during Import and Export.
Entities and Fields Settings
- Adding a Field to Import - you can customize the fields that Fullcast imports. 📋For more information, refer to the article Creating and editing field/custom field values in the Entity
- Import Filters - When configuring a Standard Import, users may create criteria around which records to import. 📋For more information, refer to the article Import Jobs
Auto Rerun Rules Settings
- Specifying the Nodes that Auto Rerun rules will and will not run on
- Allowing Auto Rerun rules to detect changes and rerun rules only if a certain change is detected.
- 📋 For more information on Auto Rerun Rules, refer to the article Auto Rerun Rules
Proposed vs Committed State
- Proposed changes don’t get exported.
- Committed changes get exported (the mechanism for this is the modified date, which cues the system to take action at the next export)
Export Triggers
- Forthcoming: a list of specific actions that trigger data to be exported when the next job runs
Common Changes
Here are the types of changes that could happen in one system (either Fullcast or Salesforce) and could potentially trigger a change in the other system.
Changes Originating in Fullcast
- Territory Rule changes such as a new territory being created or the rules being changed.
- Manual account moves such as manually moving an account from one territory to another or designating an account as a named account or named exception.
- Changes to a Coverage Assignment
- Manual Rerun Rules - there are a few reasons why a user might manually rerun rules while working in the Fullcast system. One is that you change rules of your GTM. Another reason is that you have account data that changed, but you don’t have auto rerun rules set up, so you manually rerun rules. Another is that you previously set an account as a named account/exception but you want to remove that setting, so you rerun rules to send it where it belongs.
Changes Originating in Salesforce
- Essentially data changes on the records Fullcast imports or on related objects can be detected and impact the import process. The most typical ones are changes in account, opportunity, and user data. For account data, this could be a new account gets created or field such as ARR gets filled in after having been empty. Opportunity data, such as close date is input or modified. User data, such as new user being created.
Example Scenarios
These example scenarios are meant to provide realistic changes and demonstrate what would happen during the import/export process. As you review these examples, imagine you are reviewing accounts to understand changes that happen in the import/export process, given specific criteria and settings.
Example 1 - Firmographic Data Updated but Account Does Not Move Territories
Account: Acme Company
- Initial Territory: US Mid-Market_Territory_1
- Territory Rules Applied: Acme has a US address and employee count within the set Mid-Market thresholds. In the Mid-Market segment, accounts are set to be evenly distributed across territories, which is why it is assigned to US Mid-Market_Territory_1
- Account Status: It is currently being worked by the AE assigned to US Mid-Market_Territory_1 and has an active opportunity attached to it.
- Change: A data refresh occurs in Salesforce, and the employee count is increased, so that the employee count now falls within the Enterprise employee count threshold
- Fullcast Settings:
- Auto Rerun rules is enabled on the entire MidMarket Segment
- However, there is a filter set so that that data changes on accounts with open opportunities do not trigger Auto Rerun rules.
- What happens in the Import/Export Process:
- The account data in Fullcast updates, so that in the Territory Plan table view the correct employee count is displayed.
- The account does not move.
- Fullcast - Resulting Territory: US Mid-Market_Territory_1
- Salesforce - Resulting Territory: US Mid-Market_Territory_1
Example 2 - Auto Rerun Rules Removes Disqualified Accounts and Proposes Additional Accounts to Top Off Territories
Account: Bologna Company
- Initial Territory: US_West_SMB_Unassigned
- Territory Rules Applied: In the US_West_SM segment, each territory has a maximum of 50 accounts. Reps work through accounts and use a yes/no checkbox field to mark them as Disqualified. Bologna has a US West Billing state and employee count within the set SMB thresholds. Bologna Company has never been worked and is currently in the Unassigned territory.
- Account Status: The account is not assigned to any reps and has no Leads or Opportunities associated with it
- Change: In Salesforce, multiple accounts in the US_West_SMB_Territory_5 have Leads which are Disqualified.
- Fullcast Settings:
- Auto Rerun Rules is enabled on the entire US_West_SMB Segment, specifically set to use the Committed state.
- Accounts which are Disqualified go to the Disqualified territory.
- What happens in the Import/Export Process:
- Upon Import, The disqualified accounts trigger Auto Rerun rules to move multiple accounts from Territory_5 to the Disqualified territory.
- The number of accounts in Territory_5 triggers the rules engine to move a number of accounts from Unassigned into Territory_5
- The GTM Member gets updated with the new hierarchy details, which set the node territory as US_West_SMB_Territory_5
- Fullcast - Resulting Territory: US_West_SMB_Territory_5 (Committed)
- Salesforce - Resulting Territory: US_West_SMB_Territory_5
Example 3 - Billing Country Update Triggers Change to Propose but Not Export
Account: Lager Company
- Initial Territory: EMEA_Dach_Territory_5
- Territory Rules Applied: Lager Company has a billing country of Germany, so it gets assigned to EMEA_Dach.
- Account Status: The Account is being worked by the Rep who is assigned to the EMEA_Dach_Territory 5 and has an open opportunity associated with it.
- Change: The billing country gets updated to Spain in Salesforce
- Fullcast Settings: Auto Rerun rules is enabled on EMEA_Dach but not EMEA_Spain; Changes triggered by Auto Rerun rules are made in a Proposed state.
- What happens in the Import/Export Process: move to EMEA_Spain gets proposed. But no changes get pushed to Salesforce during the Export process.
- Fullcast - Resulting Territory: EMEA_Spain_Territory_1 (Proposed)
- Salesforce - Resulting Territory: EMEA_Dach_Territory_5
Example 4 - Account Moved from Unassigned to a Territory
Account: Jinro Soju Co.
- Initial Territory: Unassigned
- Territory Rules Applied: Employee count is missing so the account does not get assigned to a territory
- Account Status: Account is not being worked
Change: A manager identifies the account as one that should be worked. They manually move it from Unassigned to APAC_Territory 4, marking it as a Named Exception.
Fullcast Settings: Auto Rerun Rules is set so that Named Accounts do not get re-evaluated under the rules.
- What happens in the Import/Export Process: The new APAC_Territory 4 gets updated on the Fullcast GTM Member. For future import/exports, the account will remain in APAC_Territory 4, until the Named Exception status is manually removed.
- Fullcast - Resulting Territory: APAC_Territory 4
- Salesforce - Resulting Territory: APAC_Territory 4