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)
3. Autonomous updates: Should the agent update opportunity fields autonomously, or only suggest updates for user review?
4. 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.
5. 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.
6. 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.
7. 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.
3. Investigate errors silently - When something fails, do your diagnosis (check data, run queries, fix environment issues) in background without narrating each step. Only surface the conclusion and action: "I need to create a test opportunity first. Let me do that..." NOT "The --json output is corrupted... let me check... ANSI color codes... let me fix..."
4. Narrate in plain language: Say "Setting up the platform..." NOT "Running setup-all.sh Phase 1.5"
5. Hide technical details: No SOAP responses, curl commands, jq parsing, phase numbers, or script paths unless user asks to debug
6. Check exit codes: Always parse success/failure and translate technical errors to admin-friendly messages
7. Set time expectations: "This takes ~3 minutes..." prevents "is it frozen?" questions
8. Handle errors gracefully: Auto-retry transient failures; explain and offer choices for real blockers

See references/admin-communication.md for detailed error translation patterns, examples, and recovery strategies.

Workflow

IMPORTANT — Primary Entry Point: For end-to-end setup, drive scripts/setup-all.sh. It handles all prerequisites, enablement, flow deployment, permissions, and verification in the correct dependency order. Only use individual scripts when diagnosing or repairing specific components after setup-all.sh has run.

setup-all.sh is a 3-phase, field-selection-driven setup: (1) platform enablement + agent user + PSG assignment; (2) field selection → prompt template creation/activation → stage descriptions (only if StageName selected) → prompt verification; (3) flow build (selected fields only), flow activation, agent activation, PSG recalc. It is safe by default: suggestions-only mode, no stage-description creation unless asked, and the flow does not go live until the prompts are in place.

Canonical agent path — two calls with an interactive tune-loop between them

See references/canonical-agent-path.md for the full two-call pattern with code examples, agent rules, narration templates, and internal step map.

Summary: Split setup into Call 1 (--through-phase prompts) and Call 2 (--from-phase flow) with a tune-loop between them where you drive prompt approval per field. Call 2 is MANDATORY — without it no flow exists and no suggestions generate.

Unattended / CI path (single call, no tune-loop)

For fully unattended runs (cron/CI, or when the user explicitly declines prompt review):

bash setup-all.sh <org-alias> --fields "NextStep,StageName,Risk__c" \
  [--field-goal "NextStep:<text>"] [--field-instruction "NextStep:<text>"] \
  [--autonomous] [--create-stage-descriptions] [--skip-prompt-verification] \
  --non-interactive [--users "a@x.com,b@x.com"]

In single-pass mode the verification step still prints each field's suggestion (informational). Relay them to the user.

Flags

See references/flags.md for complete flag documentation. Key flags:

• --check-license — preflight only (exit 0 = capable, 1 = blocker). Run FIRST.
• --through-phase prompts / --from-phase flow — split-run endpoints (mutually exclusive)
• --fields "NextStep,StageName" — required field set (at least 1, max 5)
• --autonomous — enable auto-apply mode (off by default)
• --non-interactive / --yes — unattended mode (requires --fields)
• --users "a@x.com,b@x.com" — explicit user list for PSG assignment (email-validated)

The phases below explain the decision logic for manual/repair scenarios. See references/setup-order.md for step-by-step details.

Automation Summary

Every configuration step and whether it's CLI-automatable (and how) or UI-only lives in references/automation-matrix.md. In short: prerequisites, enablement, flow clone/activation, agent publish/activation, permissions, field suggestions, and stage descriptions are all CLI-automatable (setup-all.sh does them in dependency order); only Agent Analytics is UI-only.

Phase 0 — Authentication and Org Assessment

1. Authenticate — See references/auth-and-cli.md. Always use 2>/dev/null on sf --json | jq.

2. Assess org state — Branching signals (NOT PSG existence — PSGs ship with the license even in unconfigured orgs):

   • Enablement: SalesDealAgentSettings.enableDealAgent via SOAP readMetadata
   • Setup-has-run (any of): (a) agent user holds SalesManagementAgentUserPsg, (b) flow Process_Field_Update_Suggestions exists (by ApiName, not label), (c) BotDefinition with AgentTemplate IN ('SalesMgmt__NGASalesAgent','SalesMgmt__SalesAgent')

3. Run scripts/setup-all.sh <org-alias> — handles branching automatically:

   • No enablement + no signals → greenfield (Phase 1)
   • Partial signals → repair (Phase 3)
   • All present → verification only

Phase 1 — Enable Prerequisites and Pipeline Management

See references/setup-order.md for complete scripts. Enable in dependency order: Einstein GenAI → Agentforce Agent → Agent Platform → Enhanced Notes → Opportunity Team → Pipeline Management → Pipeline Inspection. Then deploy the flow (scripts/create-flow.sh) and verify agent architecture (references/agent-creation.md).

What auto-creates on enablement: agent user + PSGs (auto-assigned). What you must create: BotDefinition:SalesAgent (via authoring-bundle publish) and the schedule-triggered flow (via template deploy).

Phase 2 — Assign Permissions

1. Define Agent Access: bash scripts/define-agent-access.sh <org-alias> — creates custom permset, links into both PSGs. See references/agent-creation.md → "Agent Access".

2. Assign PSG to target users: HARD RULE — never bulk-assign. Grant SalesManagementUserPsg only to: (1) the running user, and (2) explicit --users list. No enumerate-and-grant.

Phase 3 — Repair Mode (Partially Configured Org)

See references/repair-diagnostics.md for the full checklist. Common issues: flow deactivated → Tooling API PATCH; agent not active → sf agent activate; prompt template inactive → version round-trip redeploy; agent missing → SOAP toggle off/on.

Phase 4 — Customize (Admin Decisions Required)

1. Define Opportunity Stage Descriptions — Use the "propose and correct" pattern from references/opportunity-stages.md. Query active stages, present defaults from reference file, apply user corrections, bulk-create via Tooling API.

   IMPORTANT: Stage descriptions MAY be auto-provisioned when Pipeline Management is enabled (test orgs showed MEDDIC descriptions pre-populated). Always CHECK for existing descriptions BEFORE attempting to create them. If descriptions already exist, UPDATE rather than CREATE to avoid duplicates.

2. Configure additional data sources — See references/data-sources.md for decision table (Einstein Conversation Insights, Einstein Activity Capture, Inbox).

3. Add custom opportunity field suggestions (AFTER setup) — Fields chosen at setup time are wired by setup-all.sh --fields. To add a new field to an already-configured org, run scripts/add-field-suggestion.sh <org-alias> <FieldApiName> (e.g. a Risk__c field). The script validates the field, fills the canonical template (assets/field-completion-template.genAiPromptTemplate-meta.xml), deploys and activates it via the version round-trip, and idempotently wires the field into the live Process_Field_Update_Suggestions flow (respecting the 5-field cap). Optional flags: --label, --goal, --instruction (the two field-specific prompt lines), --verify-with-note (seed a Note + run a synchronous generation), --opp <Id>, --skip-flow, --force. See references/field-completion-prompts.md for mechanics and references/field-completion-prompt-template.md for writing the goal/instruction lines.

   Naming note: the prompt-template <type> is einstein_gpt__fieldCompletion (used in all metadata — never change it). The Setup UI (Prompt Builder) labels this category "Field Generation" — same thing. Admins should look for "Field Generation", not "Field Completion".

4. Configure autonomous updates — Autonomous mode is a single org-wide toggle (SalesDealAgentSettings.enableDealAgentAutoApproveAllTasks), not a per-field setting: when ON, the agent auto-applies all field suggestions without review; when OFF (the default), every suggestion waits for human approval. It is opt-in via setup-all.sh --autonomous. See references/autonomous-updates.md for the toggle and safety considerations.

5. Enable Agent Analytics — Setup → Einstein Feedback and Monitoring → Agent Analytics (UI-only).