Provision customer entitlements in DynamoDB when a deal is won
When a HubSpot deal hits Closed Won, the customer's plan, seats and renewal dates land in your DynamoDB accounts table, with a Slack note showing what changed.
HubSpot
Amazon DynamoDB
Slack BotOperationsSalesData SyncOnboarding AutomationWhen 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.
Example output
What does this prompt do?
- Starts the moment a deal moves to Closed Won in HubSpot, so nobody has to remember to tell engineering.
- Pulls the agreed amount, close date, contract term and line items from the deal, plus the company name and domain.
- Creates or upgrades that customer's record in your DynamoDB accounts table with their plan tier, seat count, contract start and renewal date, and the deal it came from.
- Posts a plain language confirmation to your provisioning channel in Slack showing the before and after values, and asks a person first when no matching account can be found.
What do I need to use this?
- A HubSpot account where deals move through a Closed Won stage
- An Amazon Web Services login with access to the DynamoDB table that holds your customer accounts
- The name of that table and the field it uses to identify each account, usually the company domain
- A Slack workspace and a channel where provisioning updates should land
How can I customize it?
- Change how deal values map to plan tiers, for example which amount or which product counts as Pro rather than Enterprise.
- Send unmatched deals to a separate channel for the team who owns account records, so provisioning confirmations stay clean.
- Adjust which details get written alongside the plan, such as the account manager, billing owner or support tier.
FAQs
Will this overwrite a customer's existing record?
What happens if the customer is already on a higher plan?
What if we cannot tell which account the deal belongs to?
Does this work if our table does not use the company domain to identify accounts?
Does this need a paid HubSpot plan?
Related templates
When someone leaves, we check which shared passwords they used in their final months and post a ranked rotation list to your security channel.
Every Monday, check every S3 bucket for public exposure, missing encryption and weak backup settings, then get the risks ranked in Slack.
Twice every weekday, the conversations from your social inbox land on the right HubSpot contact timelines, with a Slack recap for sales.
Every weekday at 7am, sign in to the tender portals you track, filter new notices against your bid criteria, and open a deal for the ones worth chasing.
Every morning, find the addresses that hard bounced or filed a spam complaint, update the matching HubSpot contacts, and post a short Slack recap.
Every weekday at 4pm, spot the threads that went quiet, stage a ready-to-send nudge in your mailbox, and get a ranked Slack recap.
Stop hand-editing the database every time sales closes a deal.
Let closed won deals provision themselves, with a Slack trail showing exactly what changed and for whom.