FAQ: Salesforce connection and data flow

The Fullcast platform's interaction with Salesforce relies on two key components working together: a dedicated Integration User and a Connected App.

1. Integration user: This provides the identity that executes Fullcast-driven changes, namely the standard go-to-market (GTM) plan import and export. You provide a dedicated Salesforce user that acts as the default identity for all automated operations performed by the Fullcast package.

   Note

   Using a dedicated user license is essential for maintaining a single, unambiguous audit trail for all automated changes.

2. Connected app (the secure communication channel): The package's Connected App uses the OAuth 2.0 protocol to establish a secure link from our platform to your Salesforce org. Its primary role is to be the secure entry point that allows the Fullcast platform to initiate real-time processes, like a policy execution. While the Connected App initiates the request, the underlying Apex logic is designed to execute in the context of the Integration User described above.

The Integration User is a dedicated Salesforce account that serves as the identity for all Fullcast operations. To ensure a complete and consistent audit trail, any record created or modified directly by Fullcast will be attributed to this user in the LastModifiedBy field. Additionally, if you have downstream Salesforce automation that is triggered by Fullcast’s change, this will be attributed to this user in the LastModifiedBy field.

For example, consider a scenario where a single Fullcast action triggers the following series of automated updates in Salesforce:

1. The standard Fullcast export job updates a coverage assignment by updating data on an Account Team Member.

2. This update triggers a custom Salesforce Flow that automatically changes the Account Owner.

3. The change in Account Owner then triggers another custom Flow that updates the owner on all associated Opportunities.

In this entire sequence, the audit history for the account team, the account owner, and all the updated opportunities will show that the change was made by the Fullcast Integration User.

The integration user requires a comprehensive set of permissions to ensure all processes run correctly. We provide two options for configuration, with the System Administrator profile being the most straightforward approach.

• System administrator profile (recommended): The simplest and most reliable method is to assign the System Administrator profile to the integration user. This ensures the package has all necessary permissions to perform its functions without encountering access-related errors during operations.

• Custom permissions (alternative): For organizations with security policies that prevent the use of the System Administrator profile, a custom permission configuration is available. You can use our pre-built permission sets as a base. If you choose this path, it is critical to ensure the user has all required object and field permissions to prevent any disruption of service.

The data model for GTM plans is designed to translate your strategy into a set of linked records in Salesforce. It has three main parts:

• Core object: The model supports three primary plan types: territory, team, and product plans. The Fullcast GTM object is the core of this structure, where each record represents a single node from one of these plan hierarchies (for example, a specific sales territory or an individual team).

• Junction objects: These objects connect the Fullcast GTM records to your standard CRM data. The key relationships directly correspond to the plan types:

  • Fullcast GTM records are linked to Accounts via our Territory Member object.

  • Fullcast GTM records are linked to Users via our Team Member object.

  • Fullcast GTM records are linked to Products via our Product Member object.

• Coverage assignment execution: For territory plans, the primary output of this model is the creation of standard Account Team Member records. This grants users the correct access to their assigned accounts based on the plan's logic.

At a high level, Fullcast is the platform for GTM planning and logic, while Salesforce remains your system of record and execution. This relationship works as follows for each plan type:

Territories

• Salesforce: Acts as the system of record and source of truth for all your customer relationship data: such as Account, Contact, Lead, Opportunity, Case records.

• Fullcast: You design your complete territory model in Fullcast, creating rules that define which accounts fall into each territory. You then assign users to cover those territories.

• Result in Salesforce: When your plan is exported, Fullcast creates, updates, or deletes standard Account Team Member records to perfectly match your territory model. This is the core mechanism that grants users access to the correct accounts, making Fullcast the source of truth for account alignment and coverage, via Account Teams.

Teams

• Salesforce: Acts as the system of record for User records. All user creation and activation happens here.

• Fullcast: User data is imported into Fullcast, where you build your team hierarchy. This structure is used for planning, defining reporting lines, and setting rules for automated team placement.

• Result in Salesforce: The team plan's structure is exported to Salesforce as data within Fullcast's custom objects (Fullcast GTM and Team Member). No standard User or other standard object records are modified by this process.

Products

• Salesforce: Acts as the system of record for all Product records.

• Fullcast: Product data is imported into Fullcast to build a product hierarchy or grouping model for use in territory or other GTM rules.

• Result in Salesforce: Similar to team plans, the product hierarchy is exported to Salesforce as data within Fullcast's custom objects (Fullcast GTM and Product Group Member). No standard Product records are modified.

A Note on Targets/Quotas

Targets and quotas can be created in territory, team, and product plans. They managed within the Fullcast platform are not exported to any standard or custom Salesforce objects out-of-the-box. This data is typically configured to integrate directly with a dedicated commissions or performance management platform.

You have granular control over the data imported into Fullcast at multiple levels:

• Object and field selection: In the Fullcast Entities & Fields settings, you can specify exactly which Salesforce objects and fields are imported. While a default set (including Account, Opportunity, and User) is enabled at setup, you can add or remove objects and fields to meet your needs. The integration user must have read access to any data you select.

• Data filtering: For more advanced control, you can apply filters to exclude specific records:

  • Tenant-level filters: These are global rules to exclude records you will never need for any GTM planning (for example, Exclude all Accounts where Type = Obsolete).

  • Plan-level filters: These scope the data for a specific GTM plan. For example, a CSM territory plan could be configured to exclude prospect accounts, while the Sales territory plan includes them.

Imported Salesforce data is the foundation for all GTM planning, modeling, and rule creation in Fullcast.

• GTM Plans: Each plan type is built around a primary data set. For example, a territory plan uses your imported Account data, which can be viewed in a grid (table) in the territory plan. Similarly, a Team plan is built upon your User data, and product plan is built on your Product data. Further, the data you bring in can be used to define rules. For example, you can use account data to allocate records to territories.

• Metrics: Data from other objects (like Opportunities or Leads) can be aggregated into "Metrics." For instance, you can create a metric for Annual Recurring Revenue or Count of Open Opportunities per account. These metrics can then be displayed in reports or used directly in your GTM plans. For example, you can use metrics in a Smart Plan to create balanced territories.

To ensure your planning is based on current information, an import job from Salesforce to Fullcast is scheduled to run at least once daily. You can manage the frequency of these import schedules based on your business needs.

The standard export job is designed to sync your GTM plans from Fullcast into Salesforce. The scope of this job is intentionally precise to protect your core data:

• What it does: The export primarily creates and updates records for your GTM plan within Fullcast’s own custom objects. For territory plans, its key action on standard objects is to create, update, and delete AccountTeamMember records to grant users access according to your territory design.

• What it does not do: By default, the export job does not modify other standard objects or fields. For example, it will not change the OwnerId or a custom Territory Name field on the Account record.

• Extensibility: If you require such updates, you can build your own custom Salesforce automation (typically a Flow) that uses the data exported by Fullcast as the source of truth. This gives you full control over changes to your standard object data.

The standard territory plan export is illustrated below.

The export job runs in a series of phases to ensure data integrity. Jobs can either export all records or only modified records, processing only records that have changed since the last successful export. For details, refer to Export job process overview

The primary phases of the job are:

• Cleanup: Removes orphaned Fullcast-managed records in Salesforce (for example, an Account Team Member for an account that is no longer in a territory).

• Fullcast GTM and member object sync: Creates or updates records in Fullcast's custom objects to reflect the current plan structure.

• Account Team Member sync: Creates or updates standard Account Team Member records based on the latest territory assignments.

There are three methods for making changes in Salesforce, each designed for a different use case:

• Scheduled exports (for routine batch updates): You can configure a recurring schedule for the main export job. The typical best practice is a nightly export that runs after your daily data import completes. This is the standard, automated method for keeping your Salesforce org in sync with your plan. Scheduled jobs are always partial, that is they export only modified records.

• Manual "ad hoc" exports (for on-demand batch updates): If you make a significant plan change (such as altering which coverage roles are exported) that needs to be reflected in Salesforce immediately, you can manually trigger an ad hoc export. This runs the export job on-demand, without waiting for the next scheduled run. Manual exports can be partial or full.

• Real-time policies (for instant transactional updates): For changes that must happen instantly on a record-by-record basis (such as routing a new lead as soon as it's created), you use Policies. These are not export jobs, as all of the execution occurs in Salesforce. They are designed to evaluate a single record and execute an action in near real-time, separate from the main export job. They can be configured to update specific fields on standard Salesforce records.  They can, however, update the GTM and Territory Member, so that the change can be propagated back into Fullcast during the next import job.