sales-agentforce-pipeline-management-configure

Use to configure, set up, or repair the Sales Management agent and Agentforce Pipeline Management in a Salesforce org. Automates metadata creation for flows, prompt templates, permission sets, and data source configuration. TRIGGER when: user wants to enable Pipeline Management, configure Sales pipe

By forcedotcom · 2,804 installs

npx skills add forcedotcom/sf-skills --skill sales-agentforce-pipeline-management-configure

Source repository · Upstream listing

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): 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