Skip to main content
Full Circle Insights

How Full Circle Interacts with Salesforce

Full Circle Response Management IT Overview


This guide is intended to provide technical information for System Administrators who are tasked with evaluating, installing and managing the Full Circle Response Management application. This document does not cover configuration of the application, but rather discusses the application as it relates to the platform, custom integrations and other packages.

This document reflects the 1.21.x release of Response Management.

What is Response Management?

Response Management is a native Salesforce managed application that empowers marketers to track key analytics for four key areas:

  • Marketing to sales handoff of leads and outcomes
  • Snapshot data at the time of the handoff and during the sales engagement
  • Capture inquiry-to-close funnel analytics including stage attainment dates, velocity and conversion rates
  • Multi-touch weighted campaign attribution calculations related to opportunities

All of this data is collected and stays in the Salesforce org to facilitate the following:

  • Real time funnel analytics
  • Drill down and filtered reports
  • Familiar Salesforce reporting and dashboard user interface
  • Data alignment with the sales and other teams that work within Salesforce to optimize revenue

For a quick overview of the solution you can watch an eight minute video here:

Response Management Evaluation Sequence

The Response Management evaluation sequence references the part of the application that captures funnel metrics and outcomes.

For the application to monitor and track the hand off from marketing to sales, it has to understand the criteria for the hand off, including criteria for qualification, lead and contact status values, lead conversion and opportunity association.

The application has a configuration section where hand off criteria are defined. 

The deployment process consists of ensuring that business process definitions are clear and configured, as well as identifying any custom requirements an organization may have.

Response Management monitors campaign members as they are inserted or updated to determine if they are considered Responses. They are updated and, if they are driving a new handoff from marketing to sales based on configured qualification criteria, the application will update the lead or contact status, and optionally trigger assignment of the records and send notification to the lead/contact owner.

What is a Response?

A response is a campaign member that is either inserted with the member status HasResponded set to true, or is updated from a member status where HasResponded is false to one where HasResponded is true.

At that point the application populates a date/time field on the campaign member labeled Response Date. Once the Response Date field is populated, the campaign member is always considered a response whether or not the member status HasResponded is true.

Campaign Member Configuration Example.  Note that the member status label doesn’t matter.

Campaign Member Field Response Date. The Response Status field indicates the outcome of the engagement.

Evaluation Sequence Flow Chart

The evaluation sequence is triggered when a response is generated or updated. This is a high-level view of the response evaluation sequence. There are additional criteria or actions that are not reflected here, but this should be sufficient to give you the general idea of how it works.

Expanded version of Evaluation Sequence Flow Chart (opens in new window)

Key takeaways:

  1. Response Management uses lead and contact record types to exclude business processes from evaluation and updates.
  2. For non-excluded record types, the application may update a new lead’s Lead Status value to the configured default.
  3. If a qualified response is not currently being worked (as defined by the lead/contact status) the application will update the lead or contact status and may optionally trigger assignments or notification. This is the ‘Active Response’ and funnel metrics are now tracked on the active response.

Please watch these videos on Response Management key Concepts:

Key Concepts

Response Management Overview

The Funnel


Mode Options

Campaign Attribution Overview

Response Management Solution Design & Deployment

Response Management is deployed after an extensive business process review that determines how the application should be configured and what customizations will be required in order to support an organization’s business process and reporting needs. The end of the implementation project covers the solution design, which may involve any of the following:

  • New custom fields, typically built on the campaign member object, sometimes built on opportunities, leads or contacts
  • New or modified workflow rules or processes
  • Validation rule adjustments to bypass Full Circle updates
  • Adjustment to existing Apex code that conflicts with Response Management or is not bulk safe
  • New Apex code developed internally or by the Full Circle team (this is offered additional cost if not specified during the initial purchase)
  • Updates to the marketing automation platform. These updates, if required, are typically around lead status updates, field synchronization and campaign association/updates

Remember that any of the customization above is designed to meet an organization’s business and reporting requirements.

The application is installed and the solution is built in the customer’s sandbox.  A full sandbox is not required.

All new and updated components are tracked in a standard implementation workbook, along with other information such as the deployment sequence.

Prior to deployment, typically there is data that must be cleansed and normalized:

  • Align leads to the lead status values in the picklist (there may be new values)
  • Setup contact status values
  • Campaign member cleanup
  • Campaign insertion of new field data and normalization of existing data
  • Custom data requirements

The managed package is usually installed in production three to four days prior to the deploy date. Some set up and adjustments can also be made at this time.

Deployment of the complete solution requires pausing the marketing automation inbound data. During this time the Full Circle team works with the customer to follow the deployment steps. This process also involves data adjustment and depending on the database size and the ability to bulk update records, should expect to run six to eight hours.

Response Management and Standard Objects

Response Management interacts with Salesforce standard objects and has fields on the following:

  • Leads
  • Contacts
  • Campaigns
  • Campaign Members
  • Opportunities
  • Accounts

In addition, the application has a set of custom objects that it uses to support application operations.

The application has a single trigger on each of the following standard objects. 

  • Lead
  • Contact
  • Campaign
  • Campaign Member
  • Opportunity
  • Account (this is to support the use of person accounts)

For more information on how the application interacts with objects and manages these objects, refer to the Technical Overview section of this document.

For information on the Applications triggers please refer to the Response Management Triggers documentation.

Operations on all new Leads

When a lead is created, if the lead Record Type is not set as a non-response record type, Response Management will make the following updates:

  • Set the default configured lead status
  • Set Created by Lead Conversion (Boolean) to True
  • Set Name Created Date to NOW()
  • Set Status Last Set to NOW()
  • Admin Update counter incremented

The application never creates new leads.

See Response Management Triggers.

Operations on all new Contacts

When a Contact is created, if the lead Record Type is not set as a Non-response record type, Response Management will make the following updates:

  • Set the contact status based on the status configuration
  • Set Name Created Date based to the Temp Lead Created Date if < Today() else set to Today()
  • Clear Temp Lead Created Date if populated
  • Set Status Last Set to NOW()
  • Admin Update counter incremented

The application never creates new contacts.

See Response Management Triggers.

Operations on Campaign Members

Response Management uses the campaign member object to create and track funnel metrics. Upon application installation, many managed package custom fields are created. It is also common for customers to request creation of additional custom fields to support reporting. The application makes many updates on this object.

  • For excluded record types or non-responses, set the response status to 'Not a Response'
  • For responses set any of the following:
    • Response Status
    • Response Date
    • Funnel Fields
    • Synchronization Fields
    • Owner fields
    • Response Management System fields

Campaign member records may be inserted by the application if they are defined for insertion in a configured reactivation scenario.

When an opportunity is associated to a response, the following Campaign member updates are made:

  • Opportunity Name is populated
  • Opportunity Created By is populated
  • Funnel stages may be set

See Response Management Triggers.

Operations on Leads when a response is added

When a response is added, it may not be the active response, but there are still updates made to the lead:

  • Response Score
  • Admin Update counter incremented
  • Prior Response score may be set depending on scoring mode

For an active response, additional fields may be updated:

  • Lead Status
  • Owner (if assignment was triggered)

See Response Management Triggers.

Operations on Contacts when a response is added

When a response is added, it may not be the active response but there are still updates made to the contact:

  • Response Score
  • Admin Update counter incremented
  • Prior Response score may be set depending on scoring mode

For an active response, additional fields may be updated:

  • Contact Status
  • Owner (if assignment was triggered)

If an opportunity is created off a contact with an active response, the following updates are made:

  • Contact Status set to the defined active opportunity status
  • Admin Update counter incremented

See Response Management Triggers.

Operations on Campaigns

Campaigns may be inserted by the application when creating a repeat response.

When a repeat campaign is inserted:

  • It references the originating campaign by populating the campaign field Cascade Parent
  • It copies over existing campaign fields, but clears some of the Response Management Fields

During the campaign influence rebuild, one of the batches aggregates campaign members in repeat campaigns to summary fields on the repeat parent campaign.

See Response Management Triggers.

Merging Leads and Contacts

The application introduces code to manage merge scenarios and active responses.

If during a merge operation of leads or contacts, the records had campaign membership in the same campaign, one of the records will be deleted. Salesforce does not provide a delete trigger for this event nor does it put the record in the trash can, so the data is lost forever. For this reason, we recommend that companies avoid creating duplicate records, and if they must, they rotate their Salesforce campaigns frequently.

In the case where leads are merged to leads, or into existing contacts, if each had an active response, the older response will be preserved, and the more recent response will be updated on the inactive response status of Resolved – Merged.  The surviving record will have the lead or contact status corresponding to the surviving response status.

In the case where the surviving record has two responses with the Net New Name field checked, this field will be cleared on the more recent response.

The application preserves the oldest value for the Name Created field.

The application has configuration settings to manage how to set the contact status after a lead is converted into a contact or merged into an existing contact.

Opportunity fields and how they are updated

An opportunity can be created in different ways. There may or may not be an active response that is associated to the opportunity.

If there is no active response, but there is a contact role, the application does the following in an asynchronous context; the time delay is configurable by the application:

  • Set the First Campaign Touch and Last Campaign Touch
  • Admin Update counter incremented
  • Primary campaign source may be cleared

If there is an active response and the opportunity is created from the contact record:

  • The opportunity name default, if the opportunity is created from the contact, may be pre-populated with the Account Name – (similar to the default set when an opportunity is created by lead conversion)
  • Any configured field mapping from the contact will be populated in the corresponding opportunity field

If there is an active opportunity, in all cases the following managed package fields on the opportunity will be updated:

  • Admin Originating Contact
  • Primary Campaign source may be updated to the active response’s campaign
  • Admin_CMArchive is populated
  • Admin Update Counter is incremented
  • Async: First Campaign Touch, Last Campaign Touch, Admin update counter is incremented.

The only standard opportunity field updated by the application is the Primary Campaign Source field.

See Response Management Triggers.

Campaign Attribution Models and Database

The campaign attribution database is built with scheduled batch jobs. This typically runs every 24 hours but can be scheduled to re-build weekly. The database initiates a series of jobs, and detects batch size errors and will save records and process them in another batch.  We call this dynamic batch processing. Depending on the size of the database being processed, the operations may take hours to run. In some organizations where many scheduled jobs are being run, they can conflict with each other and slow the processing.  For these organizations, weekly batch scheduling may be an option.

The database is comprised of records created for the object called ‘Campaign Influence Detail’. This object has lookup relationships to the following objects:

  • Campaign
  • Account
  • Contact
  • Opportunity
  • Lead (optionally)

The database size generated is based on the number of opportunities, campaign members and campaign influence models running and their configurations.

The application has the ability to restrict the size of the database generated in the following ways:

  • Global timeframe cutoff for opportunities; do not calculate influence on opportunities created or with a closed date earlier than a specific date
  • Model support for exclusions by opportunity type, campaign type or contact role
  • Model support for exclusion Boolean fields (formula Boolean fields supported) on the Campaign, Opportunity and Contact objects

During a database rebuild, all records are re-evaluated and when a record is deleted, it is hard-deleted so as not to fill up the trash can.

Response Management Advanced Topics

The following functional areas are not covered in detail in this document. For more information refer to appropriate articles in the Full Circle Customer portal.

  • Application configuration settings and functionality
  • Generating repeat responses
  • Nurture Timeout and bypassing nurture timeout
  • Campaign field settings
  • Reactivation scenarios
  • Sync Fields
  • Active & Passive Mode

Technical Overview


When installing a managed package, System Administrators have the choice to run unit tests. If unit tests are not run, it is possible that the package may fail to install. If the a managed package is successfully installed, and unit tests are subsequently run manually, it is possible that unit tests may fail.

Because package unit tests do not impact your ability to deploy change sets or local code, this has no impact on organizations. However, these failures may indicate interactions or incompatibilities that may cause the application to fail to operate correctly.

The Full Circle Response Management application combines the two approaches. By default, all unit tests are designed to run upon install. However, we can deploy a static resource that selectively disables some or all unit tests. We have found that most unit test failures represent testing issues and do not reflect issues with the application. These test failures help us identify the following:

  • Instances where validation rules require updates to accommodate application elements.
    • The Response Management application sometimes updates records, and those validation rules can be easily modified to recognize when records are being updated by our application so that those rules can be bypassed.
  • Bugs in integrations.
    • Failures in our unit tests sometimes help us discover bugs in existing integrations of which you may not have been aware. We can help your team resolve these issues.
  • Interactions with existing software or applications.
    • Some organizations have older packages  installed that have not updated. Due to changes in the Salesforce platform, very old packages can sometimes interfere with correct operation of newer packages or integrations. We can help identify these situations.

On/Off Switch

After the Response Management application is installed, it will have no impact on your existing organization. All object triggers are gated by an “on/off” switch, which keeps the application off by default. This allows you to completely configure the application before enabling it.

Native Application

The Full Circle Response Management application is 100% native code. It makes no callouts and has no published entry points. At no time does your data leave the platform. The only time your data may be processed externally is during the data adjustment or data migration stage in preparation for deployment (if you have purchased this service), or should you choose to enable us to monitor event logs. The Full Circle Customer Success Team will discuss this process and your options.

Objects and Limits

As a native managed AppExchange package, the Response Management application has its own set of object, field and tab limits, as well as its own set of governor limits (SOQL calls, DML calls, etc.). The application is designed for efficiency and we have seen no significant issues with global limits. The following benign limits errors may occur:

  • CPU time limit, SOQL row count, DML or heap limits during influence batch processing.
    • These can be resolved by lowering the batch size for influence calculation (influence configuration).
  • Failure to schedule job because only 5 concurrent Apex jobs are available.
    • This error is benign – the application will try again later. This limit is also in the process of being removed from the platform.


Internally, the Full Circle Response Management application uses best practices for enterprise applications, including:

  • Bulk-safe highly efficient code
  • Scalable, with queries designed for selectivity when applied to large data sets
  • Error trapping and logging to ensure application and organization stability
  • Data recovery, in the event of concurrency (DML Lock) errors, help maintain data integrity. Read the following article on DML Lock Errors and Response Management.
  • For information on the Applications triggers please refer to the Response Management Triggers documentation.

System Monitoring

  • Check reports and event logs help detect issues relating to organization changes (validation rules or workflows)
  • Optional remote monitoring allows us to proactively address issues that may occur (such as organization changes that can impact the application)


The Full Circle Response Management Application provides a number of ways that you can customize the application to meet your business needs and processes:

  • Extensibility API – Global functions that can be called from Apex to perform a variety of application related functions
  • Extensibility Plugin Model – You can create Apex plugins that are called during various application tasks allowing you to customize the behavior of the application and embed your code at various points in our response evaluation sequence
  • Campaign Influence SDK – A software development kit that allows you to create your own campaign attribution models using Apex code

Impact on Data

Please review the Campaign Influence Database section earlier in this document. We have not found that adding fields to the campaign member object has increased the 2K per record Salesforce minimum, although it is possible if an organization builds out hundreds of fields on that object.

Salesforce Updates that May Impact Response Management


This section discusses the types of Salesforce updates that may require adjustments to the Full Circle Insights configuration.

Full Circle Insights configuration updates are made by navigating to: Setup | App Setup | Installed Packages | Configure (Next to the Full Circle Insights listing)

Changes to the Lead Status, Contact Status or Opportunity Stage fields

Changes to the Lead and Contact status fields MUST be reviewed before updates in order to identify how to configure the Response Management application. If your organization sets funnel stages based on opportunity stages, updates to Opportunity stages must also be reviewed in order to identify other dependencies.

Changes to Picklist Values

Picklist value updates may effect the following  - assess if the Full Circle Insights System references the picklist values:

  • Formulas referencing picklist values (Nurture timeout formulas, Score formulas etc.)
  • Workflows referencing picklist values (Custom funnel stages, lead reassignment etc.)
  • Picklist fields configured as synchronization fields

Changes to Synchronized fields

Fields that are synchronized to their response are defined in the Full Circle Insights Configuration Sync Field tab.

These types of changes will impact synchronization:

  1. Field deletion (remove synchronization – should be removed if you refresh the page)
  2. Picklist value adjustments (be sure to adjust picklist values on the corresponding synched campaign field)
  3. Field type change; select the Refresh Field Cache button and then edit in the Sync Field page

New Users and Profiles

  • In an active org, a new profile may need to be set as a passive profile
  • There may be profile specific customizations that you need to adjust
  • If the Marketing Automation user is changed, the user defined to process repeat responses should be updated in configuration 

Score Field Change

If you change the field to which you are posting scores, be sure to either update the field which the scoring configuration points to - or if you are referencing a score formula field currently, update the formula field to reference the new score field.

The same applies in cases where you interpret a text or picklist score field and the values change; be sure the formula is updated to account for the new values.

Importing/Updating Records

If you are importing or updating Campaign Members through the Campaign Update Wizard - and your configuration updates campaign member records via workflow – be sure to select the checkbox that triggers workflow for new and updated records.

NOTE: the same holds true for Lead or Contact imports through the Campaign Update Wizard if your process requires workflow updates on create or update.

Validation Rules

Validation rules on Lead, Contacts, Opportunities, Campaigns and Campaign Member objects may impact Full Circle Insights’ ability to update records. The system updates a counter field on these objects when doing updates. You can prevent validation rules from firing when the system updates a record by ensuring it will not meet validation criteria when we update the counter field. Below is a simple example of the syntax to use:


Custom Triggers

 Response Management could be impacted when developing triggers on the following objects:

  • Opportunity
  • Contact
  • Lead
  • Account
  • Campaign Member
  • Campaign

 As you know, one of the characteristics of development is that it supports both declarative development (validation rules, workflows, etc.) and traditional software development (Apex). It is possible for validation rules and workflows to interact with other software in unpredictable ways.  This applies to any application. Even your own Apex code can be impacted by careless changes elsewhere in the system.

This is why we have extensive unit tests, and work hard to make sure that the tests themselves work correctly on every system. When you create new triggers you will want to run unit tests for our application. The practice of running unit tests after any application changes is best practice for any Salesforce or organization.

Our application self-monitors and optionally notifies our Full Circle team of errors, so we can also detect problems when they occur, but it's always better to catch these things early.

For information on the Applications triggers please refer to the Response Management Triggers documentation.

Advanced Apex Programming Information

Advanced Salesforce platform architects who wish to know more about the internal architecture of the application should refer to the book “Advanced Apex Programming for and” by Dan Appleman. The design patterns and principles in the book are largely based on the architecture and lessons learned during the development of the Full Circle Response Management application.


  • Was this article helpful?