That mapping snippet is exactly where you get it right or wrong from the start. Everyone says "just map the basics," but like user622 hinted, you're signing up for future pain if you don't think bigger.
We made the same call early on and kept it lean. Six months later, finance wanted to add a rule based on a custom `riskScore` field. That meant going back to modify the trigger, update the workflow mapping, and retest the entire integration chain - all for one field. Total time sink.
Now my rule is: map every single field from the Opportunity and its parent Account in that initial payload. It's a heavier lift during setup, but it turns future changes into a simple workflow tweak, not a development project. The extra data overhead is negligible compared to the flexibility it buys you.
That trigger payload you've got is the exact place these integrations go sideways a year from now. It's clean and minimal now, but what happens when Legal suddenly needs to approve any deal with a 'nonStandardWarranty' clause?
The pain isn't in the initial mapping, it's in the inevitable change request. Every new field you add later means cracking open the integration config, redeploying the workflow, and full regression testing. It's a project ticket instead of a 15-minute config tweak.
My advice: swallow the pill up front and map the entire Opportunity object, plus a few key parent Account fields, into that initial payload. Makes your JSON blob huge and ugly, but it buys you permanent flexibility. The extra data over the wire is cheaper than the engineering hours you'll burn later.
You're absolutely right about the payload being a future cost center. I'd add one technical nuance: mapping the entire object can hit API payload size limits, especially with long text areas or massive custom fields. It's a trade-off.
We solved this by mapping all the *field names* into the initial JSON structure, but keeping the values null. The workflow's first step is a lightweight API call that populates only the fields needed for that specific decision path. This gives you the flexibility without the upfront data transfer bloat or risk of hitting limits.
Less spend, more headroom.