Salesforce

View saved version →

---
name: salesforce
description: Safely work with Salesforce Agentforce Sales through the third-party MCP app. Use when the user asks to find, query, read, summarize, create, update, plan, assign Agentforce Lead Nurturing, inspect Salesforce objects or fields, or resolve record IDs before acting. Prefer metadata discovery over guessing, use SOQL deliberately, and write only when the user explicitly requests a Salesforce change.
allowed-tools:
  - get_record_id_by_name
  - get_activity_history_v2
  - get_record_details
  - create_record
  - update_record
  - soql_query
  - query_calendar_events_v2
  - create_account_plan
  - get_account_plan_v2
  - query_agent_type
  - assign_target_to_sdr
  - summarize_conversation_transcript
  - get_user_info_v2
  - describe_global
  - describe_sobject
---

# Salesforce Agentforce Sales

Use this as the top-level workflow for the Salesforce plugin. The Salesforce app is `salesforce` in `.app.json` and is bound to Agentforce Sales MCP app id `asdk_app_697d413990c88191a2bf4799604f8f6c`; tool access is resolved from the installed plugin connector in the user's workspace.

If Salesforce tools are not available, use the connector setup and auth recovery rules in `../../references/provider-api-rules.md` before asking the user to connect Agentforce Sales themselves. Do not satisfy Salesforce data requests from unrelated sales, support, or warehouse tools unless the user explicitly asks for that fallback.

Read `../../references/provider-api-rules.md` for non-trivial metadata, relationship, high-volume, write, UI-context, account plan, call summary, or Agentforce assignment tasks.

## Focused Workflows

- Use [salesforce-account-brief](../salesforce-account-brief/SKILL.md) for account intelligence, meeting prep, buying committee, recent activity, cases, and opportunity-context briefs.
- Use [salesforce-pipeline-review](../salesforce-pipeline-review/SKILL.md) for pipeline summaries, forecast review, stale deal hygiene, close-date risk, and owner or segment rollups.
- Use [salesforce-writeback](../salesforce-writeback/SKILL.md) for explicit creates, updates, account plan creation, opportunity next-step changes, and Agentforce Lead Nurturing assignment.
- Use [salesforce-automation](../salesforce-automation/SKILL.md) for account plans, calendar reads, call transcript summaries, and Agentforce-specific actions.
- Use [salesforce-querying](../salesforce-querying/SKILL.md) when the hard part is SOQL construction, field filtering, record lookup, UI-aware reads, or query recovery.

## Core Rules

- Prefer discovery over guessing. Use `describe_global` for object matching and `describe_sobject` for field matching before non-obvious queries or writes.
- Include `Id` in `soql_query` `SELECT` clauses whenever records may be shown or updated.
- Use user-facing labels in final answers when known, and API names only when needed for precision or follow-up.
- Keep result sets narrow. Select only fields needed for the task and add a reasonable `LIMIT` unless the user asked for a complete export.
- Use `get_user_info_v2` for requests involving "my", "me", or the current Salesforce owner.
- Use `get_record_id_by_name` when the user gives a name and the next step needs a Salesforce id.
- Use `get_record_details` for UI-oriented record displays and pass both `Compact` and `Full` layout types.
- Omit empty optional parameters on `get_record_details`; `optionalFields` values must be non-empty, fully qualified names such as `Account.Name`.
- Do not use aggregate or grouped SOQL through this connector. Fetch bounded ordinary records with `Id` and summarize locally instead.
- Write only when the user explicitly asks to create, update, create an account plan, or assign a target to an Agentforce Lead Nurturing agent.
- After any write, inspect the response and verify with returned fields, `get_record_details`, or a narrow `soql_query` before summarizing the result.
- Do not promise SOSL, query continuation, Bulk API, Composite API, Data 360, Tableau Analytics, Prompt Builder, upsert, delete, or custom Salesforce automation support unless those capabilities are exposed by the installed app.

## Record Disambiguation

- Prefer exact name or id matches before broad text matching when locating records.
- Treat broad `LIKE '%...%'` filters as candidate discovery, not proof of the canonical record.
- Account names can match regions, subsidiaries, brands, domains, and email-like records. Do not silently pick the first result when multiple plausible records remain.
- Use available business context such as country, website, industry, owner, active opportunities, recent tasks, or the user's wording to disambiguate.
- If one additional targeted filter will not clearly disambiguate the result, present the candidate records to the user before taking write actions or using the record as the basis for a deal summary.

## Query And Search Routing

Use `soql_query` for structured reads and filters on SOQL-filterable fields. Do not use aggregate or grouped SOQL such as `COUNT()` or `GROUP BY`; the connector expects clickable record rows. Use `INCLUDES` or `EXCLUDES` only on fields described as `multipicklist`, and do not filter on readable-but-not-filterable fields such as long text, history `OldValue` or `NewValue`, and priority/activity flags. This Agentforce Sales MCP surface does not expose SOSL; if a request requires cross-object keyword search, ask for a narrower object, field, or exact identifier instead of inventing another search tool.

## Write Safety

- Confirm object API name, record id, and field API names before writes.
- For `update_record`, send only changed fields in `fields`.
- For `create_record`, send only intended create fields.
- Do not probe writes to discover validation rules. If Salesforce returns `FIELD_CUSTOM_VALIDATION_EXCEPTION`, surface the exact message and ask for the missing business input or corrected value.
- Use `create_account_plan` for account plan creation instead of generic record creation.
- Before `assign_target_to_sdr`, call `query_agent_type`, show available agents, and ask which Agentforce Lead Nurturing agent to use.
- Stop if the user asks to delete or upsert; those operations are outside this MCP app.

## Output

When `get_activity_history_v2` or `query_calendar_events_v2` fulfills a standalone show or view request in a widget-capable conversation, rely on the rendered UI as the complete response. Do not add commentary, confirmation, summary, analysis, or repeat the rendered records.

For an explicit summary or analysis request, a composite workflow such as an account brief or pipeline review, or a Codex, non-widget, or background workflow, use the returned activity or calendar data to produce the requested textual or structured result. Include only relevant evidence rather than repeating the complete record list unless requested.

Return concise, business-facing results for other Salesforce requests. Include clickable Salesforce record links when `Id` is available:

- Known object and id: `https://<your-domain>.lightning.force.com/lightning/r/<ObjectApiName>/<Id>/view`
- Only id known: `https://<your-domain>.lightning.force.com/<Id>`

View saved version →

---
name: salesforce-account-brief
description: Build Salesforce Agentforce Sales account intelligence, meeting prep, opportunity deep dives, contact maps, activity context, account plan context, and recent activity briefs. Use when the user asks for an account or opportunity summary, customer meeting prep, buying committee context, account risks, next-best actions, or a consolidated brief from Salesforce account, opportunity, contact, task, event, account plan, and call records.
allowed-tools:
  - get_record_id_by_name
  - get_activity_history_v2
  - get_record_details
  - soql_query
  - query_calendar_events_v2
  - get_account_plan_v2
  - summarize_conversation_transcript
  - get_user_info_v2
  - describe_global
  - describe_sobject
---

# Salesforce Account Brief

Use this workflow for read-only Agentforce Sales briefs that combine account, opportunity, contact, task, event, activity history, account plan, and call context. Read `../../references/provider-api-rules.md` when relationship names, record-type-sensitive fields, UI/display context, or call summaries matter.

## Workflow

1. Resolve the target account or opportunity first. Prefer exact Salesforce IDs or URLs; otherwise use `get_record_id_by_name` or narrow `soql_query` calls to find candidates.
2. Confirm the needed object and field API names with `describe_sobject` when the fields are non-obvious or custom.
3. Read only the fields needed for the brief. Include `Id`, names, owners, stage/status, dates, amounts, priority, and last activity fields when relevant.
4. Pull adjacent context selectively:
   - account profile and owner fields;
   - open opportunities and current stage/amount/close date;
   - contacts or buying committee records;
   - recent tasks, calendar events, or activity history;
   - account plan details when the user asks for plan, strategy, strengths, gaps, or relationship context.
5. Use `get_record_details` when presentation-ready layout or optional fields are useful. Always include both `Compact` and `Full` layout types unless the user asks for a narrower read.
6. Use `summarize_conversation_transcript` only after resolving a specific VoiceCall or VideoCall id. If needed, query VoiceCall and VideoCall separately and ask which call to summarize.
7. For relationship-heavy briefs, confirm relationship names with metadata before using nested SOQL. Do not guess child relationship names.
8. If fields are missing from a UI/layout-oriented response, retry with explicit fields before concluding Salesforce does not expose them.

## Output

Return a compact business-facing brief with:

- resolved Salesforce record links;
- current state and important risks;
- recent activity or evidence used;
- gaps or fields that should be verified live;
- suggested next actions, clearly separated from facts.

Do not write back to Salesforce from this skill. Route explicit changes through `salesforce-writeback`.

View saved version →

---
name: salesforce-automation
description: Run Agentforce Sales MCP workflows beyond ordinary record reads. Use when the user asks to create or get account plans, assign a Contact or Lead to Agentforce Lead Nurturing, summarize a call transcript, query calendar events, or find active Agentforce sales agents.
allowed-tools:
  - get_record_id_by_name
  - get_record_details
  - soql_query
  - query_calendar_events_v2
  - create_account_plan
  - get_account_plan_v2
  - query_agent_type
  - assign_target_to_sdr
  - summarize_conversation_transcript
  - describe_global
  - describe_sobject
  - get_user_info_v2
---

# Salesforce Automation

Use this workflow for Agentforce Sales MCP actions that are more specialized than ordinary record reads. Read `../../references/provider-api-rules.md` before creating account plans, assigning targets, summarizing calls, or relying on calendar context.

## Preconditions

- Use ordinary Salesforce reads first when the task can be completed without a specialized action.
- Treat `create_account_plan` and `assign_target_to_sdr` as consequential writes. Restate the target and expected change before calling when there is any ambiguity.
- Do not invent tools or custom Salesforce automation surfaces that are not listed in this skill.
- Resolve record IDs before calling specialized tools.

## Workflow

1. For account plans, resolve the account and use `get_account_plan_v2` before creating a duplicate plan.
2. For Agentforce Lead Nurturing assignment, call `query_agent_type`, present available agents, and ask which agent to use before `assign_target_to_sdr`.
3. For call transcript summaries, query VoiceCall and VideoCall separately when the call id is unknown, then ask the user to choose a specific call before `summarize_conversation_transcript`.
4. For calendar requests, use `query_calendar_events_v2` with a bounded date or owner scope. Call `get_user_info_v2` first to determine the user's timezone for correct ISO-8601 offset.
5. Verify mutating results with returned fields, `get_record_details`, `get_account_plan_v2`, or a narrow SOQL read when the response does not prove the outcome.

## Output

When `query_calendar_events_v2` fulfills a standalone show or view request in a widget-capable conversation, rely on the rendered UI as the complete response. Do not add commentary, confirmation, summary, analysis, or repeat the rendered events.

For an explicit calendar summary or analysis request, a composite workflow such as an account brief or pipeline review, or a Codex, non-widget, or background workflow, use the returned event data to produce the requested textual or structured result. Include only relevant evidence rather than repeating the complete event list unless requested.

For other Agentforce workflows, summarize the target records, response status or payload, and verification performed. Say plainly when a requested action is unavailable on the installed MCP surface.

View saved version →

---
name: salesforce-pipeline-review
description: Review Salesforce Agentforce Sales pipeline, forecast, stale opportunities, hygiene gaps, close-date risk, stage movement, owner rollups, segment rollups, and quarter summaries. Use when the user asks for open pipeline analysis, commit/upside risk review, deals needing manager review, missing next steps, stale activity, calendar context, or opportunities that changed stage, amount, close date, or forecast category.
allowed-tools:
  - get_record_id_by_name
  - get_activity_history_v2
  - get_record_details
  - soql_query
  - query_calendar_events_v2
  - get_user_info_v2
  - describe_global
  - describe_sobject
---

# Salesforce Pipeline Review

Use this workflow for read-only opportunity and forecast analysis. Read `../../references/provider-api-rules.md` when using custom fields, relationship fields, UI reads, or high-volume result sets.

## Workflow

1. Resolve the review scope: quarter or date range, owners, segments, accounts, opportunity type, and forecast categories. For "my" or "me", use `get_user_info_v2`.
2. Inspect `Opportunity` metadata before using custom fields such as segment, forecast, next step, product, or stale-activity signals.
3. Query in narrow passes:
   - bounded ordinary opportunity rows with `Id`, stage, owner, amount, close
     date, forecast category, and other fields needed for local summaries;
   - detail rows for the largest, riskiest, or stale opportunities;
   - activity, task, calendar, or account plan context only for records that need explanation.
     Do not use aggregate or grouped SOQL such as `COUNT()` or `GROUP BY`; this connector expects clickable record rows and aggregate rows can fail output validation.
4. Flag hygiene gaps such as missing next steps, past close dates, no recent activity, stage/amount/close-date changes, and obvious owner or account mismatches.
5. Use `get_activity_history_v2` for Account, Contact, Lead, or Opportunity activity summaries when recency explains pipeline risk.
6. If the requested review would require a very large export or bulk processing, state that Bulk API and query continuation are not exposed by this MCP app and narrow to a synchronous slice such as owner, date window, stage, or top-risk records.

## Output

Lead with the review scope and run timestamp. Then return a concise table or grouped list of opportunities with Salesforce links, owner, stage, amount, close date, risk signal, and recommended action.

Keep recommendations evidence-backed. Do not change forecast category, stage, amount, or close date from this skill; route explicit updates through `salesforce-writeback`.

View saved version →

---
name: salesforce-querying
description: Choose and author Salesforce Agentforce Sales MCP reads. Use when a Salesforce task requires SOQL, metadata discovery, record lookup, UI-aware record details, field filtering, query failure recovery, or explaining why SOSL/pagination is unavailable on this MCP surface.
allowed-tools:
  - get_record_id_by_name
  - get_record_details
  - soql_query
  - describe_global
  - describe_sobject
  - get_activity_history_v2
---

# Salesforce Querying

Use this skill for Salesforce Agentforce Sales query construction and query failure recovery. Read `../../references/provider-api-rules.md` when the task involves metadata, relationship fields, high-volume result sets, UI-aware reads, or write follow-ups.

## Choose The Primitive

- Use `soql_query` for structured object reads, relationship fields, ordering, and filters on fields Salesforce marks as filterable.
- Use `get_record_id_by_name` for name-to-id lookup before record detail, activity, account plan, or update workflows.
- Use `get_record_details` for presentation-ready UI API reads, layout fields, optional fields, and child relationship context. Omit optional parameters when they would be empty. When `optionalFields` is present, pass only non-empty, fully qualified names such as `Account.Name`.
- This MCP app does not expose SOSL or a query continuation tool. If the user's request needs cross-object keyword search or additional pages beyond a bounded SOQL response, explain the surface limitation and ask for a narrower object, field, exact id, or smaller result window.

## SOQL Rules

- Always include `Id` when returning records that may be shown, linked, or used for a follow-up action.
- Keep selected fields minimal and add a `LIMIT` for exploratory queries.
- Use SOQL `LIMIT` when the total result count must be capped.
- Do not send aggregate or grouped SOQL to `soql_query`, including `COUNT()`, `SUM()`, `GROUP BY`, or aggregate aliases. This connector renders clickable record rows; aggregate rows do not have record URLs and can fail output validation. For counts or rollups, retrieve a bounded record set with `Id` and summarize locally, or state that exact aggregate coverage is unavailable on this surface.
- Do not use `WHERE` filters on fields that Salesforce reports as not filterable.
- Treat readable but not filterable text fields as fields that need another filter strategy on this MCP app.
- Long text and rich text fields are common traps: they may be readable in `SELECT` but rejected in `WHERE`.
- History value fields such as `OldValue` and `NewValue` are common readable-but-not-filterable traps. Filter history objects by parent id, changed `Field`, `CreatedDate`, or another described filterable field, then post-filter old/new values locally.
- Use `INCLUDES` or `EXCLUDES` only when `describe_sobject` reports the field type as `multipicklist`. For ordinary picklists, strings, references, or text fields, use `=`, `IN`, or another operator valid for that field type.
- Confirm every selected or filtered field on the actual target object before use, including fields that seem standard or obvious. Some orgs omit optional standard fields, and custom fields, custom objects, and `__r` relationship names are org-specific.
- For relationship queries, use describe metadata to confirm relationship field paths and child relationship names before querying.
- For field discovery by label or API name, a narrow `FieldDefinition` SOQL query is acceptable after the target object is known.
- Scope `FieldDefinition` metadata queries to a known entity with `EntityDefinition.QualifiedApiName`, `EntityDefinitionId`, or `DurableId`; broad org-wide scans can be rejected.
- In `FieldDefinition` metadata queries, keep every `OR` disjunction scoped to a single field. Same-field alternatives are acceptable, and exact alternatives should usually use `IN`; cross-field alternatives such as `Label LIKE ... OR QualifiedApiName LIKE ...` are rejected. For cross-field discovery, run one narrow query per field or predicate and merge or dedupe the results by `DurableId` or `QualifiedApiName`.
- If writing a raw SOQL parent-to-child subquery against `ActivityHistories`, include a child `LIMIT` inside the subquery. Prefer `get_activity_history_v2` to display activity history for a single Account, Contact, Lead, or Opportunity. When it fulfills a standalone activity-history request, rely on its rendered UI as the complete response and do not summarize or repeat the activity history.

Example field-discovery queries:

```sql
SELECT DurableId, QualifiedApiName, Label, DataType
FROM FieldDefinition
WHERE EntityDefinition.QualifiedApiName = 'Task'
AND Label LIKE '%description%'
ORDER BY Label
LIMIT 25
```

```sql
SELECT DurableId, QualifiedApiName, Label, DataType
FROM FieldDefinition
WHERE EntityDefinition.QualifiedApiName = 'Task'
AND QualifiedApiName LIKE '%Description%'
ORDER BY Label
LIMIT 25
```

Do not use this unsupported `Task.Description` pattern:

```sql
SELECT Id, Subject, Description
FROM Task
WHERE Description LIKE '%customer kickoff%'
LIMIT 10
```

Salesforce can reject the SOQL form even though `Description` can be selected. Since this app does not expose SOSL, recover by asking for a narrower date, owner, status, related record, or another confirmed filterable field.

## Recovery From Query Errors

- If Salesforce says a field cannot be filtered, choose a different filterable field or ask for a narrower record scope.
- If a requested summary sounds like an aggregate query, fetch a bounded set of ordinary records and calculate the summary locally instead of using aggregate SOQL.
- When a `FieldDefinition` lookup needs alternatives across multiple fields, split it into separate narrow queries before calling `soql_query`; do not distribute a common object filter across `OR` branches.
- If a field or object is unknown, call `describe_sobject` or a narrow `FieldDefinition` query before retrying.
- If the first result set is too broad, tighten by object, date, owner, status, or another confirmed filterable field rather than adding unsupported text filters.
- If the user asks for a large export or bulk write workflow, say that the current MCP app does not expose Bulk API or Composite API and ask for a narrower synchronous scope.

View saved version →

---
name: salesforce-writeback
description: Safely create or update Salesforce Agentforce Sales records after the user explicitly requests a Salesforce change. Use for updating opportunity next steps, close dates, amounts, stages, creating records, creating account plans, and assigning Contact or Lead targets to Agentforce Lead Nurturing agents.
allowed-tools:
  - get_record_id_by_name
  - get_record_details
  - create_record
  - update_record
  - soql_query
  - create_account_plan
  - get_account_plan_v2
  - query_agent_type
  - assign_target_to_sdr
  - get_user_info_v2
  - describe_global
  - describe_sobject
---

# Salesforce Writeback

Use this workflow only when the user explicitly asks to create or update Salesforce data, create an account plan, or assign a Contact or Lead to Agentforce Lead Nurturing. Read `../../references/provider-api-rules.md` before non-trivial creates, updates, account plans, assignment, or record-type-sensitive writes.

## Preconditions

- Resolve the exact object API name and record ID before updates.
- Confirm field API names, updateability, createability, required fields, picklist values, and record type constraints with `describe_sobject` when not already known.
- Read current values before user-visible or risk-bearing updates so failures or unexpected provider behavior can be repaired or clearly explained.
- For ambiguous targets, show candidates and ask for the exact record before writing.
- Do not perform delete or upsert requests; this Agentforce Sales MCP app does not expose delete or upsert tools.

## Write Patterns

- `create_record`: create leads, cases, tasks, events, notes, or other records with only the intended fields.
- `update_record`: send only changed fields. For opportunity updates, show before-and-after values when practical.
- `create_account_plan`: create account plans instead of using generic record creation. When the user explicitly requests Account Plan creation but omits required field values, follow the tool description and populate those required fields using Salesforce Account data and reliable public information. Do not add unrelated optional fields.
- `assign_target_to_sdr`: assign a Contact or Lead to an Agentforce Lead Nurturing agent only after `query_agent_type` has listed available agents and the user has selected one.

For creates and updates, do not send unchanged fields. Preserve user-visible format constraints by writing API-native values, not display-formatted guesses.

Do not probe writes to discover validation rules. Custom validation rules are org-specific and are not exposed by this connector as ordinary metadata. If Salesforce returns `FIELD_CUSTOM_VALIDATION_EXCEPTION`, surface the exact message, preserve the user's requested change without guessing a workaround, and ask for the missing business input or corrected value. If a write unexpectedly succeeds with a value that looked invalid, verify the record and report the actual outcome rather than assuming picklist metadata was enforced.

## Verification

After any write, inspect the action response. When the response does not include enough detail to prove the outcome, read the record back with `get_record_details` or a narrow SOQL query before summarizing.

Return the Salesforce record link, fields changed or created, verification method, and anything Salesforce rejected or left incomplete.