Provision customer entitlements in DynamoDB when a deal is won

When a deal in HubSpot moves to the Closed Won stage, provision or upgrade that customer's entitlement record in our Amazon DynamoDB accounts table, so engineering stops hand editing the database every time sales closes something. Trigger this from a HubSpot webhook on deal stage changes, and only continue when the new stage is Closed Won.

Start with the HubSpot Get Deal operation for the deal id in the webhook payload, requesting associations so I also get the associated company. Pull the deal amount, close date, contract term and the line item properties. Then use the HubSpot Get Company operation on the associated company to pull the company name and domain.

Look up the matching account with the Amazon DynamoDB Get Item operation, using the company domain as the key. Ask me for my table name and the name of the attribute that identifies an account if I have not already given them to you. The Key you send must contain exactly the table's partition key, and the sort key as well if the table has one, otherwise the read will fail validation.

If Get Item returns no item for that domain, do not guess and do not create a new record. Post the deal details to my provisioning channel with the Slack Bot Send a Message operation, including the company name, domain, deal name, amount and deal id, and ask someone to confirm the right account key before anything is written. Then stop without writing.

If a matching account does exist, write the entitlement with the Amazon DynamoDB Update Item operation rather than Put Item. Update Item modifies only the attributes named in the update expression, while Put Item fully replaces the item and would wipe attributes this workflow knows nothing about. Set the plan tier, seat count, contract start date, renewal date, and the HubSpot deal id for traceability.

Send every attribute in DynamoDB's tagged wire format, and remember that numbers travel as strings: a seat count of 5 is {"N": "5"} and never {"N": 5}. Write dates as ISO 8601 strings.

Guard the write with a condition expression so the update is skipped when the stored record already reflects a higher plan tier or a newer deal than this one. This is what stops an older or smaller deal from quietly downgrading a customer who has already been upgraded.

When that guard blocks the write, DynamoDB returns ConditionalCheckFailedException. Treat this as the expected and successful outcome of the guardrail, not as an error to alarm on. It means the account is already provisioned at this tier or a newer one, and the Slack message should say exactly that in plain words.

Finish by posting a confirmation to the provisioning channel with the Slack Bot Send a Message operation. Keep it in plain language for a sales or operations reader: which customer, what plan they are now on, how many seats, and when it renews, with the before and after values side by side so it is obvious what actually changed. Include the HubSpot deal id so anyone can check the source.