Salesforce return fraud: give agents evidence, keep denials reviewable

Three returns don’t prove fraud. The customer may have received damaged goods, ordered the wrong sizes, or encountered a product defect. An agent that labels the person before checking the evidence can turn a service problem into a bad account decision.

For a Salesforce return-review workflow, give Agentforce the job of assembling evidence and explaining unresolved questions. Keep refund eligibility in deterministic application logic, and route disputed or adverse decisions to a reviewer. Automate a clean return only after the underlying transaction controls are proven.

Start with the order and the returned item

Salesforce Order Management has return operations and records that a custom agent workflow can use. The Connect REST API reference distinguishes managed returns, which participate in financial processing, from unmanaged returns used for tracking. Verify which lifecycle your implementation uses before attaching a writable action.

For Data 360, the Commerce return-line mapping documents fields such as returned quantity, reason, product, and repayment amount. Deployment of a data stream and its mappings is a prerequisite; it doesn’t automatically supply every store’s or marketplace’s return history.

Inventory the sources you have. Keep order lines, fulfilled quantities, received returns, refund transactions, inspection notes, and disputes distinguishable. A requested return, an item received at the warehouse, and a completed refund are different events.

Your order-management workflow should establish the transaction facts before the agent summarizes them. A customer statement can explain the request, but it shouldn’t overwrite a shipment or payment status.

Compute the evidence before asking for an explanation

Calculate return counts and values in a deterministic query or service. Define the time window, currency handling, and whether the denominator includes cancelled orders. Aggregate purchases and returns separately at a compatible grain before joining them; multiple return lines can otherwise duplicate the purchase value.

A high return ratio is a signal for investigation. Compare it with the product category and known fulfillment problems, then show the underlying records. Avoid presenting a ratio as a probability of fraud without a validated model and a defined outcome.

Cross-channel history also depends on identity resolution. Test whether the profile belongs to one person before using it to support an adverse decision. A mistaken merge can give a legitimate customer somebody else’s return pattern.

The agent’s summary should identify observed facts, the applicable policy, and missing evidence separately. Ask it to link the supporting record identifiers so a reviewer can inspect the source. Where an explanation cannot be supported, preserve the uncertainty.

Separate reading, routing, and refunding

Use a read-only action to retrieve the authorized order and return evidence. Use another action to create or update the review case. Give the refund action its own checks for order ownership, eligible quantity, remaining refundable amount, and the current payment state.

An Apex action or Flow must enforce those conditions regardless of how the agent phrases the request. Instructions such as “refund only eligible orders” describe intent; the transaction code must reject an ineligible operation.

Add an idempotency mechanism so a retried request cannot issue the same refund twice. Test two simultaneous attempts as well as a simple retry. Record the downstream transaction identifier and reconcile an uncertain payment result before attempting it again.

For the initial rollout, keep denial and account restriction outside the agent’s available actions. Route those decisions to the existing review queue with the assembled evidence. This is a recommended control for the proposed workflow, not a claim that Salesforce universally prevents agents from making those changes.

Measure false positives before expanding automation

Begin in a review-only mode where the workflow prepares recommendations and a person records the decision. Compare recommendations with reviewed outcomes across product categories and channels. Keep legitimate returns in the evaluation set, including difficult cases that superficially resemble abuse.

Track how often a flagged return is cleared, how much evidence reviewers have to correct, and how long the customer waits. A queue with more flags isn’t necessarily detecting more fraud. It may be moving ordinary service work into a slower process.

Add transaction tests for a partial return, a previously refunded line, an unavailable history source, and a case where two people were merged into one profile. An unavailable source should remain visible as missing information, rather than turning into an invented clean history.

After the review workflow is reliable, consider automating a narrowly defined class of in-policy returns. Require the service owner to approve the eligibility rules and the recovery process before adding the writable action.

Keep the evidence and decision history readable. When a customer challenges the outcome, the reviewer should be able to explain which order facts and policy conditions led to it without relying on the model to reconstruct its earlier answer.