What it does
A deal in HubSpot starts a piece of work in Briedo, and the properties you map travel with it. Instead of asking a client something their record already answers, Briedo uses the record.
What Briedo reads
- The deal that triggered the rule, and the properties you mapped on that rule. Nothing else.
- The associated company and contact, for identity — who this piece of work is about.
What Briedo may write
Nothing. Connecting HubSpot gives Briedo read access only, and HubSpot’s consent screen asks for nothing else.
Writing back is a separate permission. If you later set up CRM write-back, Briedo asks you to approve that one additional permission on a new HubSpot screen. Until you do, Briedo cannot write to HubSpot at all.
Permissions you are granting
| Scope | Why |
|---|---|
| crm.objects.deals.read | To see the deal that started the work. |
| crm.objects.companies.read | To identify the company. |
| crm.objects.contacts.read | To identify the contact. |
| crm.objects.deals.write | Only if you set up write-back, and only after you approve it separately. |
How to connect
- Go to Settings, then Integrations, then Before discovery.
- On the HubSpot card, choose Connect and complete HubSpot’s own authorisation screen.
- Confirm the card shows Connected and names the account you expect.
How to route work
A connection on its own does nothing. A rule says which HubSpot events matter. Without one, Briedo receives events and correctly ignores them.
- In the same section, add a rule.
- Choose when it fires: A deal is created, or A deal changes.
- Narrow it to one pipeline and stage, so that only deals that have reached the point you care about start work.
- Map Contact email — it is required, because it is how Briedo knows who the work is about. Company name, first name and last name are optional.
- Choose which of your services this work is for, or let it follow your usual setup.
How mapping works
Beyond identity, you map HubSpot properties onto the things Briedo wants to know. Pick the Briedo item from the list and name the HubSpot property that holds it.
Only mapped properties travel. An unmapped property is not sent, not stored and not visible in Briedo — which is the point: your CRM holds a great deal that has nothing to do with this piece of work.
How to test it
- Use the test action on the connection card to confirm Briedo can reach the account.
- In HubSpot, move a real-but-harmless deal into the pipeline and stage your rule watches.
- Check that a piece of work appears in Briedo within a few seconds.
- Open it and confirm the properties you mapped are there, showing HubSpot as their source.
How to know it is working
- The connection card says Connected and names the right account.
- New deals in the watched stage produce work in Briedo.
- Mapped values are visible on the work, attributed to HubSpot.
- Your team is asked fewer questions than before, because the record answered them.
When it goes wrong
| What you see | What it means |
|---|---|
| Needs re-authentication | HubSpot revoked or expired the permission. Reconnect with the SAME account — Briedo refuses a reconnection from a different one rather than silently re-pointing your rules at another portal. |
| Nothing arrives | Usually no rule, or a rule watching a stage the deal never reaches. |
| A value arrives but nothing is settled | Expected in some setups. See Why a value did not count. |
How to disconnect
Disconnect on the HubSpot card. Briedo deletes its stored permission and asks HubSpot to revoke it. This does not uninstall anything from your portal.
What happens to what it already told us
Nothing is deleted. Work that was already prepared keeps everything it learned, including the record that this system is where it came from. Those are records of what was true at the time, and disconnecting a system later does not make them untrue.
What stops is new information arriving. Deleting historical data is a separate request, and a deliberate one.