Update to Salesforce

"---\nname: salesforce-querying\ndescription: 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.\nallowed-tools:\n  - get_record_id_by_name\n  - get_record_v2\n  - get_records_v2\n  - soql_query\n  - describe_global\n  - describe_sobject\n  - get_activity_history_v2\n---\n\n# Salesforce Querying\n\nUse 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.\n\n## Choose The Primitive\n\n- Use `soql_query` for structured object reads, relationship fields, ordering, and filters on fields Salesforce marks as filterable.\n- Use `get_record_id_by_name` for name-to-id lookup before record detail, activity, account plan, or update workflows.\n- Use `get_record_v2` for one record's fields: `inputs: [{recordId, objectApiName, fieldNames}]`. Check available object-specific field-mapping resources first and use explicit API names from a mapping when present; leave `fieldNames` empty only when no mapping resource exists, to get the default Full View. The server automatically adds context fields for a rich layout. Its rendered widget is the complete answer; no additional commentary is needed.\n- Use `get_records_v2` only when the user wants a collection shown as an interactive table, never for a single named record: `inputs: [{objectApiName, fieldNames, filterCriteria?, sortBy?, recordLimit?}]`. Verify filterable/sortable fields with `describe_sobject` first. `filterCriteria` and `sortBy` are JSON-encoded array strings, for example `[{\"fieldName\":\"StageName\",\"operator\":\"EQ\",\"value\":\"Prospecting\"}]` and `[{\"fieldName\":\"CloseDate\",\"direction\":\"ASC\"}]`; allowed operators are `EQ`, `NEQ`, `GT`, `GTE`, `LT`, `LTE`, `LIKE`, `IN`, `NIN`, and `NULL`. Leave the rendered table to speak for itself; do not add a text summary or repeat its rows.\n- 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.\n\n## SOQL Rules\n\n- Always include `Id` when returning records that may be shown, linked, or used for a follow-up action.\n- Keep selected fields minimal and add a `LIMIT` for exploratory queries.\n- Use SOQL `LIMIT` when the total result count must be capped.\n- 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.\n- Do not use `WHERE` filters on fields that Salesforce reports as not filterable.\n- Treat readable but not filterable text fields as fields that need another filter strategy on this MCP app.\n- Long text and rich text fields are common traps: they may be readable in `SELECT` but rejected in `WHERE`.\n- 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.\n- 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.\n- 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.\n- For relationship queries, use describe metadata to confirm relationship field paths and child relationship names before querying.\n- For field discovery by label or API name, a narrow `FieldDefinition` SOQL query is acceptable after the target object is known.\n- Scope `FieldDefinition` metadata queries to a known entity with `EntityDefinition.QualifiedApiName`, `EntityDefinitionId`, or `DurableId`; broad org-wide scans can be rejected.\n- 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`.\n- 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.\n\nExample field-discovery queries:\n\n```sql\nSELECT DurableId, QualifiedApiName, Label, DataType\nFROM FieldDefinition\nWHERE EntityDefinition.QualifiedApiName = 'Task'\nAND Label LIKE '%description%'\nORDER BY Label\nLIMIT 25\n```\n\n```sql\nSELECT DurableId, QualifiedApiName, Label, DataType\nFROM FieldDefinition\nWHERE EntityDefinition.QualifiedApiName = 'Task'\nAND QualifiedApiName LIKE '%Description%'\nORDER BY Label\nLIMIT 25\n```\n\nDo not use this unsupported `Task.Description` pattern:\n\n```sql\nSELECT Id, Subject, Description\nFROM Task\nWHERE Description LIKE '%customer kickoff%'\nLIMIT 10\n```\n\nSalesforce 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.\n\n## Recovery From Query Errors\n\n- If Salesforce says a field cannot be filtered, choose a different filterable field or ask for a narrower record scope.\n- 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.\n- 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.\n- If a field or object is unknown, call `describe_sobject` or a narrow `FieldDefinition` query before retrying.\n- 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.\n- 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.\n"