Update to Salesforce

"---\nname: salesforce-writeback\ndescription: 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.\nallowed-tools:\n  - get_record_id_by_name\n  - get_record_v2\n  - create_record_v2\n  - update_record_v2\n  - soql_query\n  - create_account_plan\n  - get_account_plan_v2\n  - query_agent_type\n  - assign_target_to_sdr\n  - get_user_info_v2\n  - describe_global\n  - describe_sobject\n---\n\n# Salesforce Writeback\n\nUse 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.\n\n## Preconditions\n\n- Resolve the exact object API name and record ID before updates.\n- Confirm field API names, updateability, createability, required fields, picklist values, and record type constraints with `describe_sobject` when not already known.\n- Read current values before user-visible or risk-bearing updates so failures or unexpected provider behavior can be repaired or clearly explained.\n- For ambiguous targets, show candidates and ask for the exact record before writing.\n- Do not perform delete or upsert requests; this Agentforce Sales MCP app does not expose delete or upsert tools.\n\n## Write Patterns\n\n- `create_record_v2`: `inputs: [{objectApiName, recordData}]`. Create leads, cases, tasks, events, notes, or other records with only the intended, createable fields in `recordData`. The created-record widget shows the result; no additional commentary is needed.\n- `update_record_v2`: `inputs: [{recordId, objectApiName, recordData}]`. Send only changed, updateable fields in `recordData`. For opportunity updates, show before-and-after values when practical. The updated-record widget shows the result; no additional commentary is needed.\n- Never pass the older `fields` or `fieldsToUpdate` parameters to `create_record_v2` or `update_record_v2`; both take `recordData`.\n- `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.\n- `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.\n\nFor creates and updates, do not send unchanged fields. Preserve user-visible format constraints by writing API-native values, not display-formatted guesses.\n\nDo 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.\n\n## Verification\n\nAfter 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_v2` or a narrow SOQL query before summarizing.\n\nReturn the Salesforce record link, fields changed or created, verification method, and anything Salesforce rejected or left incomplete.\n"