What reward versioning means
Reward versioning ties every submission to the reward that was visible to the submitter at the moment they submitted. If you later edit the reward on a live campaign, the new value applies to submissions made from that point forward. Existing submissions keep the reward they were promised.
The point of this is trust. A submitter who saw 100 Credits when they submitted gets credit for 100 Credits even if you change the campaign reward to 150 Credits an hour later. You can iterate on amounts, copy, and reward types on a live campaign without breaking that promise.
What gets snapshotted at submission time
When a submission is created, HighAdvocacy copies the reward configuration into the submission record. The snapshot stores:
- Reward type: Credits, Discount, Cash, Gift Card, or Custom.
- Amount: the value entered on the reward (for example,
100,10,50,25). - Name or description: the reward name and any description that goes with it (for example, “Share your success story” or “Free T-shirt”).
These three fields are the source of truth for everything the submission displays and emails downstream.
How rewards appear in the Submissions table
The Submissions table has a Reward column. The value shown is built from the snapshot, not from the current campaign reward.
| Reward kind | Column format | Example |
|---|---|---|
| Standard rewards (Credits, Discount, Cash, Gift Card) | amount + type | 100 credits, $10 cash, 10% discount, $25 gift card |
| Custom rewards | reward name | Free T-shirt |
The column is always visible. There is no separate indicator that the campaign reward has been edited since the submission was created: the value in the column is already the version that belongs to that row.
Submission detail shows reward at submission time only
Open any submission and the detail view shows the reward as it was when the person submitted.
- The detail view does not compare the snapshotted reward to the current campaign reward.
- There is no manual override on the submission: the snapshotted reward cannot be edited from this view.
- Webhooks delivered on approval use the current webhook configuration on the campaign, not the snapshot.
If you need to know what an older submitter was promised, the snapshot in the submission detail is the answer. If you need to know what a brand-new submitter would be promised right now, the campaign reward configuration is the answer.
The inline warning on mid-flight reward edits
Open a campaign’s Rewards step in the editor and the Reward configuration panel shows this warning before you change anything:
Changing rewards on a live campaign? Existing submissions will keep their original reward values. Only new submissions will receive the updated reward.
The warning is always present in the reward configuration panel, so the snapshot rule is visible the moment you start editing, not after you save.
The warning is the only signal you get. There is no separate confirmation step or audit log entry. The submissions that already exist keep their snapshot.
Why there is no comparison view or manual override
A few things are intentionally not offered:
- No side-by-side comparison. The submission detail shows the snapshot only, not the snapshot and the current campaign reward. The campaign reward is one click away if you need it.
- No manual override on a submission. You cannot edit the reward on a saved submission. Submission-time wins.
- No audit log of reward changes on the submission. The snapshot itself is the record.
This keeps the behavior simple: submission time decides, every time.
Reward off by default on new rows
When you add a new reward to a campaign (Write a Post, Engagement, or any other type) the row is created with its toggle in the off state. Submitters do not see the reward until you flip the toggle on.
This protects you from publishing half-built rewards. You can save a row, walk away, come back, and finish it without an incomplete configuration going live in the meantime.
The toggle is on the row header in the reward list and on the reward configuration card.
What stays current
Not everything is snapshotted. The submission record captures the reward content; the delivery layer keeps using the live integration config.
| What | Snapshotted at submission? |
|---|---|
| Reward type | Yes |
| Reward amount | Yes |
| Reward name or description | Yes |
| Webhook endpoint | No (current campaign config used at approval) |
| Integration configuration (auth, mappings) | No (current campaign config used at approval) |
In practice this means that if you change your webhook URL or rotate an integration credential, approvals on older submissions still deliver through the new config. Only the reward content the submitter was promised is locked.