HublytixBack to the app

Security & Trust

Last updated: 14 September 2026

Connecting an analytics tool to your CRM is an act of trust. Hublytix is built so that trust is easy to give: we use read-only access, we store findings rather than your customer records, and you can cut off access at any time. This page explains exactly how.

Read-only by design

Hublytix connects to HubSpot using OAuth with a small set of read-only scopes. We do not request write access and are technically unable to create, edit, or delete anything in your portal. Every fix we recommend is applied by you, in HubSpot, under your control.

Findings, not your data

We do not replicate your CRM. When an audit runs, we read your portal transiently to compute results, and we persist only what is needed to show and track those results:

  • record identifiers — the HubSpot Record IDs of the contacts we believe are duplicates of each other, grouped together, so we can show you the group and deep-link you into HubSpot;
  • scan counts and history — how many contacts were read, how many groups were found, and when;
  • why each group was matched and which record we recommend keeping, stored as codes: the rule that decided it (for example has_deals), which signals agreed and disagreed, and how many of the records are marketing contacts;
  • your decisions — which groups you approved or marked as different people, who decided, and when;
  • property names and your merge preferences for them (for example “Job title → keep the newer value”), and the version of the rule order in force when a recommendation was made.

What we never store: the values themselves. No names, no email addresses, no phone numbers, no property contents, no owner names. The name and email you see beside a duplicate group are fetched live from HubSpot while you are looking at the screen and are gone when you close it. We store that a rule called has_deals decided a group — never “has 2 deals, $84,000 most recent”.

We do not copy your contact records into our database, we do not sell your data, and we do not use it to train machine-learning models. No AI reads your contacts. Every recommendation comes from a published, deterministic rule order, and the same records always produce the same answer.

Two limits we state rather than leave implied. Properties HubSpot marks as sensitive are never compared, because we do not hold the permission to read them. And whether a contact is enrolled in a workflow is not verified — reading that requires a permission that would also let us enrol contacts, which we will not request.

How we choose which record to keep

The rule order is published because a recommendation you cannot check is one you have to take on trust. These rules run in this order, and the first one that separates the records decides. Every recommendation names which rule decided it, which of the others agreed, and which disagreed.

  1. Salesforce link — only one record keeps syncing after a merge.
  2. Deliverable email — a hard-bounced address loses to one that works.
  3. Has deals — a record with deals beats one with none. If both have deals, this rule ties and the group is flagged for a closer look.
  4. Owner assigned — assigned beats unassigned.
  5. More recent conversation — by at least 30 days, so a few hours’ difference decides nothing.
  6. More recent email engagement — the same 30-day gap.
  7. Active in a sequence.
  8. Later lifecycle stage — using your portal’s stage order, not a fixed one.
  9. More complete record — by at least two populated fields.
  10. Oldest record — the tiebreaker, when nothing above separates them.

No percentages and no scores: a recommendation says “6 of 7 signals agree”, which you can check, rather than a confidence figure you cannot. No AI is involved at any point — the same records always produce the same answer.

When we refuse to recommend

A merge cannot be undone, so there are cases where the honest answer is that we do not know. In each of these the rules stop, no keeper is suggested, and the decision is left to you:

  • You already kept them separate — you told us these are different people.
  • A unique property on both records — HubSpot itself blocks the merge until one value is cleared.
  • Both linked to Salesforce — one of them stops syncing, and that belongs to you.
  • Two different owners — a decision about a relationship, not about data.
  • Consent or legal basis differs — we never choose a consent value for you.
  • A possible job change — different company and an unrelated email domain.
  • Your own rule blocks it — a property you told us means two different people.
  • Name only — the same full name and nothing else agreeing.

What we report as done

Hublytix never merges anything, so it cannot know a merge happened by having done it. Figures for completed work — merges verified, and marketing contacts freed — appear only after a later scan hasobserved the records combine in HubSpot. Nothing is counted at the moment you approve it, because approving is not merging.

Encryption

  • In transit: all traffic is served over HTTPS/TLS, with HSTS enforced.
  • At rest: HubSpot access and refresh tokens are encrypted with AES-256-GCM before storage; our database provider encrypts data at rest.

Tenant isolation

Customer data is separated at the database layer using PostgreSQL Row-Level Security (RLS). Access is scoped per account, so one customer’s data is not reachable from another’s session.

You are always in control

You can revoke Hublytix’s access at any time — from within HubSpot’s connected-apps settings, or with one click from the Settings page in the app. When you disconnect a portal, we revoke the associated access tokens and permanently delete that portal’s stored findings.

Application security

The app is hardened with current web-security controls, including a strict Content-Security-Policy with per-request nonces, protection against cross-site request forgery on state-changing requests, HSTS, and a full set of security response headers. Secrets are held in managed environment configuration and are never committed to source control, and we rotate them when needed.

Monitoring

We use error monitoring to detect and diagnose problems quickly. We log access and key events to support security and troubleshooting.

Infrastructure and sub-processors

Hublytix runs on established cloud providers for hosting, database, authentication, email, payments, and monitoring. The full list of sub-processors, what each one handles, and where they operate is on our Sub-processors page.

Compliance posture

We designed Hublytix to align with the EU/UK GDPR and to meet India’s Digital Personal Data Protection Act, 2023 as its requirements come into force. A Data Processing Agreement is available for customers who need one — contact privacy@hublytix.ai. We describe how we handle personal data in our Privacy Policy.

We do not currently hold formal third-party certifications such as SOC 2 or ISO 27001; we will say so plainly here if and when that changes.

Reporting a vulnerability

If you believe you have found a security issue, please email security@hublytix.ai. We welcome responsible disclosure and will work with you to investigate and resolve valid reports. Please do not publicly disclose an issue until we have had a reasonable opportunity to address it.