Commerce edits aren't synced to Salesforce
MoveData processes commerce transactions — ticket sales, merchandise sales, raffle entries, paid event registrations — when they are first created on your fundraising platform. Edits to the same transaction made later are not reflected in Salesforce.
Examples of edits MoveData does not propagate:
- A full or partial refund applied to a sale.
- A cancellation of a sale or of a specific ticket within an order.
- A line item adjustment (changing the ticket type, quantity, or attendee on an existing order).
- A change to a custom field or attendee detail captured at the time of purchase.
Once the Opportunity, Opportunity Products, Product, and Price Book Entry records are in Salesforce, MoveData will not update them to reflect downstream edits on the source platform.
Donation refunds are different
This article is about commerce transactions. Donation refunds — handled by the donation pipeline — do continue to flow through to Salesforce, where MoveData adjusts the Opportunity (or Gift Transaction) to reflect a full or partial refund. The limitation described here applies only to commerce transactions processed through the commerce pipeline.
Why this is a deliberate limitation#
The reason varies depending on the fundraising platform and the type of edit:
- No webhook or API event for the edit. Some platforms don't emit a webhook or expose an event when a commerce transaction is edited after creation. With nothing to react to, MoveData has no way to know the change happened.
- The edit maps awkwardly to the Salesforce data model. Commerce uses Opportunities with Opportunity Products and Price Book Entries. Reflecting a partial refund against a specific Opportunity Product within a larger order, or a single cancelled ticket within a multi-ticket purchase, has no clean automated handling — the right Salesforce outcome depends on how your organisation accounts for it.
- The edit is rare enough that supporting it isn't worth the engineering effort. Some commerce edits affect a small enough fraction of transactions that customers prefer to handle them manually rather than wait for a feature.
What you will see in the Notifications tab#
Where the source platform emits an event for the edit but MoveData chooses not to apply it, the notification appears in the Notifications tab with a status of Skipped and a short explanation in the notification body.
Where the source platform doesn't emit anything for the edit, there is no notification built at all — the change happened only on the source platform and MoveData has no record of it. In this case, you'll need to spot the difference by reviewing the source platform directly.
Handling edits manually#
When you make an edit on the source platform that needs to be reflected in Salesforce, update the Salesforce record by hand.
- Locate the original Opportunity in Salesforce. Use the platform key, Stripe transaction ID, receipt number, or another reliable identifier from the source platform to find it.
- Edit the Opportunity, Opportunity Products, or related records to reflect the change. For example:
- Full refund or full cancellation — change the Stage to Closed Lost (or your equivalent), and optionally adjust the Amount.
- Partial refund — adjust the Amount on the Opportunity and the relevant Opportunity Product.
- Ticket cancellation within a multi-ticket order — adjust or remove the affected Opportunity Product, then recalculate the Opportunity Amount.
- Record a note of the manual adjustment on the record (in a description field, custom field, or chatter post) if you need an audit trail of when and why the change was made.