AWS Partner Central

Cotillion’s AWS integration ships registered deals into the AWS Partner Central — Customer Engagements (ACE) program. Once connected, every opportunity you mark for AWS in Cotillion is mapped to the ACE schema and created / updated through the AWS Partner Central Selling API on your behalf — no manual re-keying in the Partner Central UI.

At a glance

How the connection works

Cotillion backend  ──AssumeRole(roleArn, ExternalId=<tenant>)──▶  AWS STS
       │                                                              │
       │◀──── temporary AccessKey/SecretKey/SessionToken ─────────────┘
       │
       └──── PartnerCentralSellingClient(credentials, region) ──▶  AWS Partner Central

The trust policy you put on the IAM role pins two identities:

1. Principal — Cotillion’s production AWS account (arn:aws:iam::<COTILLION_ACCOUNT_ID>:root), so only Cotillion can call sts:AssumeRole on your role.
2. ExternalId — a unique identifier for your organization that Cotillion shows you on the connect screen and supplies to STS at every AssumeRole call. This binds the IAM role to your tenant — even another Cotillion tenant inside the same AWS account cannot assume your role by accident (defends against the confused-deputy problem ).

Setup

How registration works

Once connected, the flow for shipping a deal from Cotillion to AWS is:

1. Propose — AI maps your Cotillion deal (and selected AWS Products from the AWS Products catalog) into the ACE payload shape.
2. Refine — you can edit fields directly or re-prompt the AI with a natural-language hint (e.g. “set sales involvement to co-sell”).
3. Write — Cotillion calls CreateOpportunity (first time) or UpdateOpportunity (subsequent edits) under your assumed role, then brings the attachments in line with what you reviewed: AssociateOpportunity for anything added, DisassociateOpportunity for anything you removed.
4. Submit — when you press Submit in Cotillion, it calls SubmitOpportunity, which hands the opportunity off to AWS for AM review.
5. Engagement — for opportunities that progress to an ACE engagement, Cotillion calls StartEngagementFromOpportunityTask and polls ListEngagementFromOpportunityTasks for the task state.

The form mirrors the AWS Partner Central Create opportunity wizard — the same section names, the same field names, the same order — so what you review here can be read against what you would have typed there. Every field the wizard offers is here, including the APN program, the marketing details and the deal-size estimate; you are free to change any of them, and free to change none.

Mapping is informed by an AWS field-rules table (per-field allowed values, max lengths, state transitions) generated from the AWS Partner Central Selling SDK. AWS performs authoritative server-side validation on every submission; rejections are translated into typed errors in Cotillion with the field-level reason attached, so the opportunity stays in Draft until the offending field is corrected.

What stays in AWS Partner Central

One part of a solution has no API behind it, so it happens in the portal rather than in Cotillion:

• Creating a solution. Solutions are created only in AWS Partner Central (Build → Solutions). Cotillion associates an existing one; if the solution you need is missing from the picker, create it in the portal first, then refresh the catalogue on the registration screen.

What a registration already sells IS readable, and Cotillion shows it: when you update a registered deal, the Solutions field opens carrying what AWS currently holds against it, with anything the mapper proposes added alongside. That list is the answer — leaving an entry keeps it attached, and removing one detaches it at AWS when you submit.

Naming a solution, and what it costs to skip

AWS states its own rule as a choice: associate at least one solution, or describe what you are selling in free text. Cotillion asks for exactly that — the description is required only while no solution is attached, and naming a solution clears it.

The choice matters later than it looks. A deal registers and passes review on the description alone, but AWS declines to close it as won until a real solution is attached, and by then the opportunity is locked to your edits. The registration screen is the last point where you can settle it, which is why it says so there.

If AWS refuses a close Cotillion pushed for you, the deal shows a banner on the Synced tab with AWS’s own words. Nothing needs to be re-sent by hand: the close is offered again on its own as soon as the deal or the AWS record moves.

Asking AWS to co-sell, or just sharing the deal

The registration carries one more answer AWS asks for first in its own wizard: whether you want AWS sellers working the deal with you (co-sell) or you are sharing it for visibility only. It sits on the Working with the vendor card while you review the draft, and the submit uses it — nothing asks you again days later.

Choosing visibility only drops the Co-sell needs question, exactly as AWS’s wizard does, and those needs are not sent with the registration. What Cotillion generated for them stays on the draft: switch back to co-sell and the answer is there again.

What you can edit, and when

AWS decides which fields it takes back, and when — before submission the sales stage is fixed, while it is reviewing nothing may change, in Action required it opens fourteen named fields, and after approval it freezes seven for good. Cotillion follows that table rather than working around it: a field AWS will not take is shown read-only with the reason next to it, so nothing you type is quietly dropped on the way.

One more of AWS’s own limits: a deal carries up to ten solutions, so the picker stops there.

If AWS asks for changes

AWS can send a registration back instead of approving it: it sets the review status to Action required and writes what it needs into the deal’s review comments. Cotillion shows those words as a banner on the deal, with Update Deal beside them, and the deal keeps its own tag in the Synced tab so it is visible without opening anything.

While a deal is in that state AWS opens a specific set of fields for editing — the customer’s address and website, the target close date, the spend estimate, the customer’s business problem and your own opportunity identifier — and refuses the rest. Cotillion sends only what AWS accepts and leaves everything else exactly as AWS holds it. Once you have made the changes, Submit for Review hands the deal back.

After AWS approves: moving the deal along

AWS keeps two answers about a deal, and they move independently. Review status is AWS’s verdict on the registration — pending, submitted, in review, approved. Stage is how the sale itself is going: Prospect, Qualified, Technical Validation, Business Validation, Committed, then Launched or Closed Lost. Approval does not move the stage, and your CRM cannot state it — the middle stages describe the conversation with AWS, not anything your CRM records.

Once AWS approves the registration, the deal drawer offers the stage as a picker, with AWS’s own list of stages. Choosing Closed Lost opens AWS’s list of reasons beside it; naming one is optional, and AWS records its own catch-all reason when you name none. Before approval the picker explains itself instead of acting: AWS locks the stage until it has reviewed the deal, and blocks every edit while the review is open.

You do not have to drive the last two by hand. When your CRM closes the deal, Cotillion pushes the matching close — Launched for a win, Closed Lost with a reason for a loss — and a stage you set yourself stands until that happens.

What AWS sees on its side

GetOpportunity returns your side of the registration, not AWS’s. The deal drawer reads AWS’s own view as well, and shows it under How the vendor sees this deal: the involvement type and visibility your submission was accepted with, AWS’s own stage and next steps, its opportunity quality score and trend, the actions it suggests next, and the AWS people on the deal. It is read-only, and it is empty until AWS has picked the opportunity up — an approved registration nobody at AWS has engaged with yet has no side to show.

Identifying the customer to AWS

AWS maps each opportunity to a company in its own CRM, and it says plainly which fields do that work: “Ensure customer website accuracy because it’s pivotal for AWS CRM mapping. Pair it with the customer name for superior CRM account mapping.” The API reference makes the same point on the website field — “This value is crucial to map the customer within the AWS CRM system.”

So the field worth keeping accurate on your CRM customer records is the company website. Cotillion reads it from the customer record, and falls back to the domain of a customer contact’s email address when the record carries none.

A DUNS may also be supplied and Cotillion sends it when your CRM names one, but AWS rates it below the website itself: “DUNS number is useful to map the opportunity to an account but not the most reliable value since all customers do not have DUNS.” Write it on the customer record as what it is (“DUNS: 75-166-3428”) — a bare nine-digit number is left alone, because company registers in several countries issue numbers of exactly that length.

Unlike Microsoft, AWS publishes no customer-identifier check you can read before submitting. What a poor match produces is the ACE review loop: the opportunity comes back Action Required with AWS’s comments, and the fields AWS lets you correct are the address and the website — the mapping keys themselves.

What you can verify

If you’re an auditor reviewing AWS access:

• CloudTrail in your AWS account logs every AssumeRole call against this role, with the source account (Cotillion’s) and the ExternalId used. Filter by eventName = AssumeRole and requestParameters.roleArn.
• Partner Central UI → Opportunities → Filter “Submitted by API” shows every opportunity Cotillion created on your behalf. The AssumeRole session name (vendor-service-<uuid>) appears in your CloudTrail audit trail alongside the call.
• Cotillion’s operational dashboards count every Partner Central Selling API call per tenant — request via support if you need an export.

Reference

• AWS Partner Central — Customer Engagements (ACE) 
• AWS Partner Central Selling API Reference 
• IAM role trust policy with ExternalId 

Troubleshooting

PRM_AUTH_REVOKED — AWS access denied on Test & Connect

The IAM role’s trust policy doesn’t allow Cotillion’s account to assume it, OR the ExternalId is wrong. Re-check both — the ExternalId is case-sensitive.

PRM_AUTH_REVOKED — AWS rejected identity token

The role’s trust policy is structurally invalid (wrong JSON shape, or references a non-existent principal). Validate the policy with aws iam validate-policy (or the IAM console’s policy validator) and re-create the role.

Opportunity rejected with a validation error

AWS Partner Central rejected one or more fields (typically a PrimaryNeedFromAws enum value outside the allowed set, or a TargetCloseDate more than 24 months out). The opportunity stays in Draft in Cotillion with the AWS validation reason attached; edit the offending field and re-submit.

STS session expires mid-batch

The role’s Max session duration is set to AWS’s default 1 hour. Bump it to 4–12 hours in IAM → Role → Edit. Cotillion refreshes credentials 2 minutes before expiry, but a single long-running submission run may exceed a 1-hour session.

For the AWS-side review process (Partner Central enrolment, sandbox access, OLAs), contact your AWS Partner Manager. For Cotillion-side issues, email [email protected].