Sales Agentforce Pipeline Management Configure

Agentforce Pipeline Management Configuration

Configure Agentforce Pipeline Management end-to-end in a Salesforce org. This skill handles both greenfield orgs (zero configuration) and partially configured orgs that need repair or completion.

Scope

• In scope: Enabling Pipeline Management, configuring the Sales Management agent, activating/customizing flows (Process Field Update Suggestions, Get Opportunity Grounding Data, Get AI Recommendations from Call Transcripts), prompt template configuration, permission set assignment, data source setup, opportunity stage descriptions, autonomous field update configuration, and partial-org repair.
• Out of scope: Building custom agents from scratch (use agentforce-generate). Einstein Conversation Insights or Einstein Activity Capture initial provisioning (those are separate products). Slack app installation. Custom Apex triggers on Opportunity Team Member.

Prerequisites

You must verify (scripts cannot check or change these)

1. Edition: Enterprise, Performance, Unlimited, or Developer Edition with Agentforce for Sales add-on (or Agentforce 1 Sales Edition). Setup probes this up front (Step 0) — it fails fast with a license/edition message on an org that can't run Pipeline Management, before asking anything — but edition/license provisioning itself is still admin-owned.
2. User permissions: The executing user needs View Setup AND (Modify All Data OR Customize Application), Manage AI Agents AND (Manage Agentforce Employee Agents OR Customize Application), and Assign Permission Sets.

Enabled automatically by scripts/setup-all.sh

The following settings are toggled by setup automatically — do not enable them manually before running the script.

• Einstein Generative AI (EinsteinGptSettings.enableEinsteinGptPlatform) — required; must be on before Agentforce Agent.
• Agentforce Agent (EinsteinCopilotSettings.enableEinsteinGptCopilot) — required; depends on Einstein Generative AI.
• Agentforce Studio / Agent Platform (AgentPlatformSettings.enableAgentPlatform) — required; depends on Agentforce Agent and gates the Deal Agent. Core rejects SalesDealAgentSettings.enableDealAgent when this is off, surfacing as an opaque Deal Agent activation failure.
• Enhanced Notes (EnhancedNotesSettings.enableEnhancedNotes) — required; Pipeline Management uses ContentNote as a primary data source.
• Opportunity Team (OpportunitySettings.enableOpportunityTeam) — required; the suggestion flow uses OpportunityTeamMember and will fail deployment without it.
• Pipeline Inspection (OpportunitySettings.enablePipelineInspection) — required; provides the UI where reps view and accept/dismiss suggestions. Suggestions still generate without it, but users have nowhere to see them.
• Enhanced Email (EmailAdministrationSettings.enableEnhancedEmailEnabled) — optional but recommended; only needed for email-body indexing when Einstein Activity Capture is in use.
• Pipeline Management (SalesDealAgentSettings.enableDealAgent) — required; the feature itself.

Clarifying Questions

Run the license preflight FIRST — before asking any of these questions. As your very first action (right after resolving the org alias), run bash scripts/setup-all.sh <org-alias> --check-license. It runs only auth + the capability gate, asks nothing, and changes nothing. If it exits non-zero, relay the printed license/edition blocker to the user and STOP — do not ask any clarifying question and make no changes. Only when it exits 0 (org is capable — greenfield or already provisioned) proceed to the questions below.

Once the preflight passes, determine:

1. Greenfield or repair? Is this a new org that has never had Pipeline Management, or one with partial configuration?
2. Data sources: Which data sources should inform the agent?

• Notes (enabled by default)
• Emails (requires Einstein Activity Capture)
• Voice/Video calls (requires Einstein Conversation Insights)
• Enhanced Email (for email body indexing — requires EmailAdministrationSettings.enableEnhancedEmailEnabled)

1. Autonomous updates: Should the agent update opportunity fields autonomously, or only suggest updates for user review?
2. Which fields should the agent manage? (ask this FIRST, up front — setup is field-selection-driven). setup-all.sh builds the flow with only the fields you select, from the start — there is no deploy-both-then-strip step. Ask: "Which Opportunity fields should the agent suggest values for? The OOTB options are Next Step (`NextStep`) and Opportunity Stage (`StageName`); you can also add custom text fields (e.g. a Competitor Analysis field)."

• At least 1 field is REQUIRED — setup aborts (exit 1) if zero fields are selected. There is no default to NextStep.
• Hard cap: 5 fields total; OOTB fields count toward it. Selecting more aborts before any change.
• Pass the set with --fields "NextStep,StageName,Risk__c" in non-interactive runs, or type it at the interactive prompt.

1. Per-field prompt customization (all fields EXCEPT `StageName`). For each selected non-StageName field, setup collects an optional goal ("You must think about…") and instruction (extraction guidance):

• `NextStep` ships with a curated OOTB managed prompt. Setup only overrides it when you supply a goal/instruction (interactive: it asks whether to customize; non-interactive: pass --field-goal "NextStep:…" / --field-instruction "NextStep:…"). Skip customization to keep the OOTB prompt.
• Custom fields always get a goal/instruction (your text, or the script's sensible defaults).
• `StageName` is NOT customizable — it is a managed picklist template with no override support; setup never prompts for it.

1. Custom field eligibility: Only standard or custom text fields on Opportunity are supported — plain Text (type=string) or Text Area ≤ 255 (type=textarea, htmlFormatted=false); length ≤ 255; not Long Text Area (length > 255), Rich Text Area (htmlFormatted=true), picklist, or formula. The suggestion is capped at the field's own length. Fields selected in question 4 are wired during setup-all.sh; additional fields added after setup use scripts/add-field-suggestion.sh <org-alias> <FieldApiName> (one per field; see Phase 4.3). Both paths enforce the 5-total cap — add-field-suggestion.sh refuses to wire a 6th field.
2. Opportunity stages: Opportunity stages are picklist values, and different Opportunity record types may expose different stage subsets. Are standard or custom opportunity stages in use? Do their descriptions need to be defined/updated? Note: OpptStageDescription is global-per-stage — keyed only by OpportunityStageApiName, with no per-record-type column — so a description is written once per active stage and applies across every record type that exposes that stage. Setup works the same whether or not the org has Opportunity record types.

Admin Communication Guidelines

CRITICAL: This skill serves admin users, not developers. Follow these rules:

1. Run all bash commands in background (run_in_background: true) - this includes the main setup commands AND any log-tailing for progress monitoring
2. Monitor progress without showing commands - You can tail logs to provide progress updates, but run tail commands in background too. Parse the output and show only friendly updates like "✓ Opportunity Team: enabled". Never show the tail command itself or raw log lines.