Do Multi-Partner Opportunity Stages Sync Automatically?
Short answer
No. When Partner A invites Partner B into a multi-partner engagement and B accepts, each partner owns a separate opportunity record. Partner A marking their opportunity as Launched does not automatically move Partner B's opportunity to Launched. Partner B must update their own Stage manually.
1. How multi-partner opportunities are structured
AWS Partner Central uses an “engagement” as the shared container for a multi-partner deal. An engagement is an AWS-owned resource that connects multiple partner accounts (and AWS itself) around one customer opportunity. Partners can invite up to nine other partners into an engagement using Engagement Invitations.
Engagements are built to facilitate information sharing and collaboration, but they explicitly preserve individual opportunity, ownership and control. When an invited partner accepts, they receive their own opportunity record inside that same engagement. From that point on, Partner A and Partner B each have distinct opportunity records, each with its own independent lifecycle.
2. What syncs automatically, and what doesn’t
There is exactly one automatic inheritance behavior, and it happens only once, when the invited partner’s opportunity is created. It applies to Lifecycle.ReviewStatus (AWS's validation status), not to Lifecycle.Stage (the Prospect → Qualified → … → Launched/Closed sales pipeline).
Field | At invitation acceptance | After opportunity is created |
Lifecycle.ReviewStatus | Inherited from sender: Submitted stays Submitted until sender is Approved, then auto-updates to Approved. | No further auto-sync described; treated as a one-time inheritance at creation. |
Lifecycle.Stage (Prospect → … → Launched) | Not copied or synced — each partner’s opportunity stage is independent from creation. | Never auto-synced. Each partner updates their own Stage manually via UpdateOpportunity. |
Other opportunity details | Copied once from sender at creation (title, use case, business problem, etc.). | Shared only via point-in-time snapshots; receiving partner must manually pull changes in with UpdateOpportunity. |
In other words: ReviewStatus can auto-inherit once at creation time. Stage (which is what “Launched” refers to) never auto-syncs, at creation or afterward.
3. How updates flow after the opportunities are created
Once both opportunities exist, partners maintain and update them independently. Progress is shared through snapshots, point-in-time, immutable copies of specific fields from a partner’s opportunity, rather than through any live, push-based sync.
Partner A updates their opportunity (e.g., marks it Launched).
A new snapshot revision of Partner A’s opportunity is created (assuming the ResourceSnapshotJobRole is configured) and shared within the engagement.
Partner B can retrieve that snapshot using ListResourceSnapshots / GetResourceSnapshot to see that A launched.
Nothing happens automatically after that. Partner B must explicitly call UpdateOpportunity on their own record to change their own Stage to Launched.
If Partner A never sets up the snapshot job role, Partner B won’t even see the update, they'll continue to view a stale snapshot of Partner A’s opportunity.
4. Key takeaway
Partner A marking their opportunity “Launched” has no direct effect on Partner B’s opportunity Stage.
Partner B will only see A’s status change if snapshot sharing is correctly configured on both sides, and even then only as a visible snapshot, not a status change.
Partner B must manually update their own opportunity's Stage to Launched.
The only field that can auto-propagate at all is ReviewStatus, and only once, from Submitted to Approved, at the time the invited partner's opportunity is created. This is unrelated to the Launched stage.