Salesforce configuration requirements¶
For the digital-campaign pilot to produce reports with proper end-to-end funnel attribution (ad → landing → lead → MQL → SQL → opportunity → pipeline), a set of Salesforce configurations is required. The scope is ordered by priority to facilitate planning by CIAL's Salesforce team.
Summary by priority¶
| # | Priority | Configuration | Launch blocker |
|---|---|---|---|
| 1 | P0 | UTM fields on Lead + Landing Variant | Yes |
| 2 | P1 | Connected App + Integration User + read-only Permission Set | Required for end-to-end reporting |
| 3 | P2 | Custom field Lead_Score__c and Flows |
Recommended, does not block launch |
| 4 | P3 | UTM propagation to Opportunity and Account | From month 2 onward |
P0 — UTM fields on the Lead object¶
Rationale. Without these fields, leads coming in through campaign landings lose their origin when created in Salesforce. It is not possible to tell a LinkedIn Ads lead from an organic one, nor to know which creative or landing generated it. Pilot attribution depends entirely on this.
Required fields on the Lead object¶
Five UTM fields, type Text(255):
| API Name | Label | Type |
|---|---|---|
UTM_Source__c |
UTM Source | Text(255) |
UTM_Medium__c |
UTM Medium | Text(255) |
UTM_Campaign__c |
UTM Campaign | Text(255) |
UTM_Content__c |
UTM Content | Text(255) |
UTM_Term__c |
UTM Term | Text(255) |
Two fields for platform click identifiers (needed to reconcile against Google Ads and LinkedIn):
| API Name | Label | Type |
|---|---|---|
GCLID__c |
Google Click ID | Text(255) |
LI_FAT_ID__c |
LinkedIn Click ID | Text(255) |
One control field identifying the landing that generated the lead:
| API Name | Label | Type | Values |
|---|---|---|---|
Landing_Variant__c |
Landing Variant | Picklist | velocidad, dolor, riesgo, otra |
Complementary configuration¶
Field-level security: read access for Sales User and Marketing User profiles, edit restricted to Admin / System. Page layout: add the eight fields in a collapsible "Marketing attribution" section within the standard Lead layout. Capture of values on the form side in Webflow (URL reading and submission as hidden fields) is configured in parallel with the Webflow technical team.
P1 — Read-only API access for Looker Studio¶
Rationale. Monthly client reports combine LinkedIn Campaign Manager, Google Ads, GA4, and Salesforce data in a Looker Studio dashboard. Without read access on the Salesforce side, the report stops at form-submit and loses the cross-reference with MQL, opportunity, and pipeline, which is the metric the commercial team needs to see.
The standard Salesforce pattern for this type of access has three components: a Connected App with OAuth 2.0, a dedicated Integration User, and a read-only Permission Set. This architecture follows the least-privilege principle and avoids sharing human credentials.
a) Connected App with OAuth 2.0¶
A Connected App dedicated to this integration (suggested name: EON_Looker_Studio_Reporting), configured with:
- OAuth Settings enabled
- Callback URL provided by the chosen Looker Studio connector
- Selected OAuth Scopes:
Manage user data via APIs (api),Perform requests at any time (refresh_token, offline_access) - Require Secret for Web Server Flow: Yes
- IP Relaxation: restricted to an IP allowlist if security policy requires
b) Dedicated Integration User¶
A Salesforce user exclusively for this integration, without UI login capability. Salesforce Enterprise offers the Salesforce Integration license (also known as "API Only User"), designed for exactly this case: it does not consume Sales or Service licenses, operates only via API, and limits exposure risk. If that license is unavailable in CIAL's current environment, the alternative is a Sales user with a restricted Profile — less clean but functional.
- Suggested username:
eon-integration@cialdnb.com.mxor the internal domain defined by CIAL - License: Salesforce Integration (preferred) or Sales with restricted Profile
- Profile: Minimum Access — API Only Integrations, or a custom Profile cloned from "Minimum Access" with no UI permissions
c) Read-only Permission Set¶
A Permission Set assigned to the Integration User with read-only permissions over the funnel objects:
| Object | Read | Create | Edit | Delete |
|---|---|---|---|---|
| Lead | ✓ | — | — | — |
| Contact | ✓ | — | — | — |
| Account | ✓ | — | — | — |
| Opportunity | ✓ | — | — | — |
| Campaign | ✓ | — | — | — |
| CampaignMember | ✓ | — | — | — |
| Task / Event (Activity) | ✓ | — | — | — |
Field-level read access includes the UTM fields created in P0, plus the standard fields on each object (Status, OwnerId, CreatedDate, CloseDate, Amount, StageName, and similar).
What this configuration explicitly does not require: access to sensitive objects (User, LoginHistory, Profile), modification permissions, administrative permissions. Access is by design the least privileged possible.
Custody and audit on the EON side¶
- Integration User credentials kept in a corporate secrets manager (1Password Business).
- API token usage logs available for audit by CIAL.
- Documentation of which dashboards consume which objects and fields.
Alternative if direct API is not viable¶
A scheduled export (daily or weekly) of the relevant objects to a shared channel (SFTP bucket, Google Drive, S3). It is a more rigid architecture and adds latency to reporting, but respects a closed Salesforce perimeter. If CIAL's internal policy does not permit API access to third parties, this alternative is acceptable and the client report cadence is adjusted accordingly.
P2 — Custom field and Flows for Lead Scoring¶
Rationale. CIAL's commercial team identified MQL quality and ICP fit as a key pilot metric. Without an automated score, that qualification is subjective per SDR and does not scale. The hybrid scoring model (firmographic and behavioral) is documented in Lead Scoring model.
Custom fields on Lead¶
| API Name | Label | Type |
|---|---|---|
Lead_Score__c |
Lead Score | Number(3,0), default 0 |
Lead_Score_Updated__c |
Lead Score Last Updated | DateTime |
Lead_Stage__c |
Lead Stage | Picklist: Lead, MQL, SQL, Disqualified |
Flows in Flow Builder¶
A set of record-triggered Flows that update Lead_Score__c according to the model's rules. Technical build of the Flows is specified in a joint session between the Salesforce Admin team and EON: EON provides the rule and weight logic; the CIAL team executes configuration in sandbox first, then in production.
Estimated effort: 6 to 10 hours of Salesforce Admin work spread across Flow construction, external-source mapping (Customer.io, Gong Engage, Gong Foundation, GA4), and sandbox QA.
This configuration is not a blocker to start campaigns. Without Lead Scoring the pilot reports volume and CPL, but loses the quality reading of MQL.
P3 — UTM propagation to Opportunity and Account¶
Once P0 is implemented and leads flow with populated UTMs, replicate the same five UTM fields on the Opportunity and Account objects, and configure a Flow that copies them from the originating Lead at conversion time. This propagation enables pipeline and account attribution to the originating channel months after the initial conversion, closing the revenue attribution loop.
It is not a priority for the pilot itself, but it is for the commercial-impact reports generated at pilot close.