# 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.

- Workflow type: agent
- Services: HubSpot, Amazon DynamoDB, Slack Bot
- Categories: Operations, Sales
- Published: 2026-08-10

## What it does

- 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 you'll need

- 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

## Prompt

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.

## How to customize

- 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.

## Example output

Provisioning update: Northwind Traders (northwind.com)
Plan: Growth -> Enterprise
Seats: 25 -> 120
Contract start: 1 Aug 2026
Renews: 31 Jul 2027
Source: HubSpot deal "Northwind renewal + expansion" (#14882301)

## FAQ

### Will this overwrite a customer's existing record?

No. It upgrades the record in place, changing only the details it knows about such as plan, seats and renewal dates. Anything else already stored against that customer is left exactly as it was.

### What happens if the customer is already on a higher plan?

The write is skipped and Slack tells you why. This protects you from an older or smaller deal quietly downgrading a customer who has already been moved up.

### What if we cannot tell which account the deal belongs to?

Nothing is written. The deal details are posted to Slack so someone can confirm the right account first. It will never guess at a customer record.

### Does this work if our table does not use the company domain to identify accounts?

Yes. Tell it which field your table uses to identify each account and it will look up and write against that instead.

### Does this need a paid HubSpot plan?

You need to be able to send an alert out of HubSpot when a deal stage changes. Exactly how that is switched on depends on your HubSpot tier and setup, so check with whoever administers your portal if you are unsure.

Use this prompt in General Input: https://www.generalinput.com/prompts/provision-customer-entitlements-in-dynamodb-when-a-deal-is-won