| Name | Description | Date |
| Sandbox Update | For customers enrolled in automatic updates, Sandbox environments will be updated on May 21st at 10 pm PDT. | 5/21/2026 |
| Production Update | For customers enrolled in automatic updates, Production environments will be updated May 28th at 10 pm PDT. | 5/28/2026 |
New Features
Campaign Member History
Full Circle Response Management now includes Campaign Member History tracking, giving your team visibility into changes made to Campaign Member records over time. Salesforce does not provide native history tracking for Campaign Members, so this feature fills an important gap for support, troubleshooting, and auditing purposes.
Who does it benefit?
Support teams, implementation specialists, and administrators who need to troubleshoot Campaign Member issues or audit changes to response data over time.
What problem does this new feature solve?
Until now, there was no way to see a history of changes made to Campaign Member records in Salesforce. This made troubleshooting difficult and time-consuming, as there was no audit trail to reference when investigating unexpected changes to response data.
Enablement Instructions
Step 1 — Enable Campaign Member History Navigate to Funnel Metrics Configuration and click the Campaign Member History button. Toggle the feature using the on/off switch.
Step 2 — Configure your settings Once enabled, configure the following options to match your organization's needs:
- Retention period — Set how long history records are retained. Options: 1 month, 3 months, 6 months, or 1 year.
- Fields to track — Select which Campaign Member fields you want to include in the history log. No fields are tracked by default; you must select the fields you want to monitor.
-
Delete data — If needed, you can clear history records in two ways:
- Delete All Data — Removes all history records from the database.
- Delete Data Before Date — Removes all history records prior to a date you specify using
Step 3 — Add the View History button to the Campaign Member page layout
Once the feature is enabled, you will need to add the history button to your Campaign Member page layout. There are two options:
- A custom button (1) that can be added to the top right corner of the Campaign Member record page.
- A Lightning component (2) that can be placed anywhere on the page layout.
Once added, users with access to the Campaign Member record will be able to click the button to view a history table showing the date and time of each change, the field that was modified, the user who made the change, the original value, the new value, and who made the change.
Improvements
Alternate Opportunity Created Date Field
A new setting has been added to Funnel Metrics Advanced Configuration that allows you to select an alternate date field to use in place of the standard Salesforce Opportunity Created Date. Once configured, you can specify which Full Circle operations should use this alternate date, including Campaign Attribution, Opportunity Association, and First/Last Touch assignment.
Who does it benefit?
Organizations whose business processes rely on a custom opportunity date field rather than the standard Salesforce Created Date, and who want Full Circle's attribution and association logic to reflect that date.
What problem does this improvement solve?
Previously, Full Circle always used the standard Opportunity Created Date field for Campaign Attribution, Opportunity Association, and First/Last Touch logic. Organizations that capture a more meaningful opportunity date in a custom field had no way to use it within Full Circle's core operations.
Enablement Instructions
Navigate to Funnel Metrics Configuration > Advanced Configuration, scroll down the page to Alternate Opportunity Created Date Field and select an alternate created date field from the new dropdown. Use the checkboxes to specify which operations — Campaign Attribution, Opportunity Association, and/or First/Last Touch — should use the alternate date.
Zoomed in view
Full view
Important Implementation Note:
If you enable this for Opportunity Association or First/Last Touch, additional configuration is required beyond the dropdown selection. You must implement two Salesforce Flows to manage the timing of these operations:
Flow 1 (Disable Initial Trigger): This flow must call the DisableApplicationForContext method from our SupportAPI to prevent FCI from firing automatically upon opportunity creation. This results in a "partial association" where the Admin Originating Contact is identified, but touch fields are not yet stamped.
Flow 2 (Target Date Trigger): This flow should execute when your custom target date field is populated. It should use the “FCI - Associate Opportunities” Apex Action (introduced in RM v1.51) to trigger association based on the new date.
This will associate the Opportunity to the original contact, taking into account the target date field when determining the response to associate as well as for the Last Touch campaign.
For more information or help in setting this up, please reach out to us with LMA access granted so that we may set those flows for you. We’ll keep them deactivated until you have a chance to review and approve them.
Fixes
Anonymous Digital Touch Funnel Stage Assignment (included from Release 1.53.3)
This release resolves an issue affecting customers using Digital Source Tracking (DST) where anonymous digital touches — both first and middle touches — were not having their funnel stage fields set correctly when a new response was inserted. With this release, new anonymous digital touches will have their appropriate funnel stages set as expected upon response insertion.
Who does it benefit?
Customers using Digital Source Tracking (DST) with anonymous first and/or middle digital touch campaigns configured.
What problem does this fix solve?
When a new response was inserted for an anonymous digital touch, the funnel stage fields triggered by the New Response event were not being populated. For most customers using the recommended Full Circle funnel, this meant the Inquiry stage — and its associated checkbox and date fields — were not being set on the campaign member record.
Enablement Instructions
This fix does not require enablement and will apply automatically to all new responses inserted after this release. See the recommended post-upgrade data remediation steps below.
For further context, this update was originally introduced in release 1.53.3; view the full release notes here.
Campaign Attribution Opportunity Exclusion Affecting Downstream Models
Resolved an issue where excluding an opportunity from a Campaign Attribution model using the Opportunity Exclude From Attribution field would incorrectly exclude that opportunity from all downstream attribution models as well. Opportunity exclusions will now apply only to the model in which the exclusion is configured.
Who does it benefit?
Organizations running multiple Campaign Attribution models who need to exclude specific opportunities from individual models without affecting others.
What problem does this fix solve?
When an opportunity was excluded from Model 1, it was also being excluded from Models 2 and 3, even though no exclusion had been configured on those models. This caused inaccurate attribution data across downstream models and required a workaround of reordering models, which was confusing and error-prone.
Enablement Instructions
This fix does not require enablement.
Async Request Reprocessing for First/Last Touch
Resolved an issue where failed asynchronous requests for First/Last Touch processing could not be rerun due to malformed data in the Params field. When an async request failed, the list of failed record IDs was being appended to the existing Params field without a delimiter, making the data unreadable and preventing reprocessing. Failed async requests will now correctly store only the IDs of records that need to be retried, allowing them to be reprocessed successfully.
Who does it benefit?
Administrators who monitor and reprocess failed async requests in the Check Report Dashboard.
What problem does this fix solve?
When a First/Last Touch async request partially failed, the system was unable to rerun the failed records because the parameters field had been corrupted during the error logging process. This meant failed records could not be automatically retried, requiring manual intervention.
Enablement Instructions
This fix does not require enablement.
Comments
0 comments
Article is closed for comments.