When Can an Agent Say the Refund Is Complete?
A Salesforce agent should call a refund complete only after the request, authority, payment, and final state have been checked independently.
When Can an Agent Say the Refund Is Complete?
Checking the request, permission, payment, and result before reporting success.
A customer asks a Salesforce agent to take care of a refund. The agent finds the order, prepares the request, and calls the payment service. Before it tells the customer the refund is complete, it needs evidence that the correct amount reached the expected payment state.
Salesforce may save the refund request while the payment provider times out. The provider may already have accepted the refund, or it may not have received it. Calling again without checking could duplicate the payment. Reporting either success or failure immediately would conceal what the system does not yet know.
The agent can interpret the customer’s language and ask for clarification. The refund operation needs explicit inputs and checks: the order, amount, currency, eligibility, caller’s permissions, and any required approval. Flow or Apex can implement parts of the operation, while the payment provider remains responsible for the money movement.
Before AI: A Refund Was an Explicit Operation
Salesforce teams could build a refund path with a case screen, Flow, Apex, an approval process, and a payment integration.
The user selected an order, chose a refund reason, and submitted an operation. Salesforce validated the case and order state. A rule calculated eligibility. An approval could pause the request. An integration called the payment provider. A callback or reconciliation job updated the case with the provider’s result.
The path had plenty of failure modes, but the operation was named. A developer could define the input, the transaction boundary, the external dependency, and the record that represented progress.
Today: The Agent Interprets the Request
An agent can turn natural language into a candidate operation:
The agent first identifies the customer and order, then gathers the facts needed for the refund. It proposes an operation with explicit inputs. The application validates those inputs and the current policy, requests confirmation or approval where required, and performs the permitted steps. The final response follows the saved and independently checked result.
Salesforce actions can target Apex, Flow, or prompt templates. An action can be invoked in explicit logic or exposed as a tool the LLM may choose. This distinction matters. A model-selected tool is a useful way to handle a capability whose use is genuinely contextual. A required eligibility check or payment operation should have a deterministic path and a recheck at the boundary where it can change state.
The model’s output should become structured input, not executable prose.
Saving the refund request and completing the payment are separate facts. Reconciliation connects them before the agent reports completion.
Specify what the refund operation accepts and returns
For the refund capability, define the contract before choosing how the agent will reach it:
| Contract element | Example |
|---|---|
| Subject | customer, order, item, payment transaction |
| Requested operation | full refund, partial refund, replacement credit |
| Inputs | order ID, amount, currency, reason, evidence reference |
| Preconditions | captured payment, eligible status, no existing refund in progress |
| Authority | acting user or agent principal, permission, approval threshold |
| Local effect | refund request record and status transition |
| External effect | payment provider request with idempotency key |
| Output | provider reference, status, amount, timestamp, error code |
| Verification | query provider and reconcile Salesforce state |
The contract makes the dangerous ambiguities visible. “Refund this” is not enough. The agent must not infer a currency from a conversational phrase if the payment system has an authoritative value. It should not accept a customer-supplied order identifier without checking the caller’s access.
Enforce the checks where the refund runs
A prompt can tell an agent to refund only eligible orders. A reliable system also enforces eligibility in the action or the deterministic capability it invokes.
The validation layer should recheck:
- record identity and current status;
- amount and currency boundaries;
- duplicate or in-progress requests;
- customer and payment ownership;
- policy and approval thresholds;
- permissions and field access;
- external provider availability and contract version; and
- whether the request is still valid after the user confirmed it.
The last point matters. Confirmation is not a freeze-frame. The order can change between the agent’s explanation and the user’s approval. Revalidate at the state-changing boundary.
What does the customer’s “yes” actually approve?
Salesforce action definitions can include user confirmation behavior. Confirmation is useful when the user understands the side effect and the action is reversible or bounded. It is not a substitute for authorization or an approval process.
Use a confirmation when the user needs to acknowledge an understood action: “Issue a $75 refund to the original payment method?”
Use an approval when a person with appropriate authority must make a business decision: “Approve a refund above the service team’s threshold.”
Use a documented reversal or compensation path where the provider supports one. A completed refund may be irreversible; do not promise cancellation unless the provider’s current state and contract allow it.
Make the distinction visible in the action state. A conversation that says “Would you like me to proceed?” should not imply that the user has approved a policy exception merely by saying yes.
Recognize the same refund when it is retried
Suppose the payment provider accepts a refund but the response never reaches Salesforce. The agent sees a timeout and the customer repeats the request. The system needs to recognize both attempts as the same refund rather than issue another one.
An idempotency key identifies that business request across retries. For example, a key could combine the order ID with a saved refund-request ID. It should stay the same when the same request is retried, rather than change with every conversation turn.
Store the request identifier, amount, provider reference, and status in Salesforce. Before another submission, check the saved request and the provider’s state. The provider’s documented duplicate-handling behavior matters too; merely sending a field named “idempotency key” does not establish how it will be enforced.
This gives the team a concrete question to test: if the provider accepted the first request and Salesforce lost the response, can the system find that refund without creating another?
Check what happened before saying it is done
The final response should follow the evidence from Salesforce and the payment provider. If the response arrives before those checks, it can overstate what happened even when the agent selected the right operation.
For a refund, completion might require:
- the refund request record was created or updated successfully;
- the payment provider returned an accepted or completed state;
- the amount and currency match the requested values;
- the provider reference was persisted; and
- reconciliation has no unresolved mismatch.
If the provider timed out after accepting the request, the correct answer is not “failed” or “completed.” It is “submitted; external status is pending verification.” The customer-facing response should represent the intermediate state honestly.
Keep the proposed request distinct from a validated request, an approved submission, and a reconciled refund. Those statuses identify different facts and different next steps.
For every status, name the component that can establish it. Salesforce can show that the request was saved. The payment provider can show what it accepted or completed. Reconciliation compares those facts and identifies any mismatch. The agent should report the status those checks support.
Where this can go wrong
Natural language becomes an untyped command
The action accepts a sentence and lets the model extract amount, currency, and order state. Use structured inputs and validate them against authoritative records.
Confirmation is treated as authorization
The user said yes, but the acting principal still lacks permission or the amount exceeds policy. Check authority independently.
Local commit is treated as external completion
Salesforce saved a refund request, but the payment provider did not confirm the money movement. Maintain separate states.
Retry creates a second side effect
A timeout leads to a new provider request. Use a stable business idempotency key and reconciliation.
Verification is delegated to the same model
The agent says the refund happened because it selected the refund action. Verify through record state and the external provider’s status.
Who checks each part of the refund?
| Stage | Question | Owner |
|---|---|---|
| Intent | What did the user mean? | agent plus user clarification |
| Context | Which order, customer, and policy apply? | data and retrieval contract |
| Input | Are the values typed and complete? | action boundary |
| Authority | May this principal request this amount? | Salesforce permissions and policy |
| Execution | What commits together? | Flow, Apex, or external capability |
| Recovery | What happens after timeout or duplicate delivery? | state machine and idempotency owner |
| Verification | What proves the result? | provider query, reconciliation, and evidence |
The model can participate in every stage as an interpreter or coordinator. It should not silently own a stage whose correctness depends on deterministic state.
Where more automation could help
Salesforce may absorb more of the path from intent to verified action by generating action schemas, applying policy metadata, routing to standard capabilities, and surfacing intermediate states across channels.
That could remove repetitive orchestration. It will not remove the need to define the business operation, side effects, retry semantics, and evidence. The platform can coordinate a refund; the payment system still owns the money movement, and the organization still owns the decision to issue it.
What the customer should hear next
The customer should hear “complete” only when the payment evidence supports it. Until then, the request needs a status that the agent and service team can find and explain.
The next post asks where each part of that refund operation should run: Flow, Apex, a model call, a durable process, or an external service.
Sources
- Salesforce Developers: Agent Script Reference: Actions
- Salesforce Developers: Agent Script Language Characteristics
- Salesforce Architects: Architecture Basics
More in This Series
Subscribe
Get new posts by email
Enterprise architecture, AI systems, and platform strategy.