Trust is a system. Not a promise.
Three questions decide whether a platform is safe to put your business on. What happens to our systems. What happens to our data. Whether the numbers can be trusted. This page answers all three, in that order, and where an answer is awkward we would rather write it down than let you find it in week three.
Your systems stay yours
Connecting Pulse does not require moving your CRM, your workflows, or your automations. What we read, what we write, and what we cannot touch is enumerated below rather than summarised.
Your data stays yours
Where it lives, who can reach it, what leaves the platform, how you get it back, and what happens on the day you decide to go.
Every number is provable
The ledger standard, the reconciliation model, and the ten rules that fail the build rather than generate a review comment.
Pulse connects to your systems. It does not take them hostage.
Connecting Pulse does not inherently require migrating your CRM, your workflows, your automations, your payment processing, or your history. Three shapes are supported, and which one you run is a decision your team makes before anything moves.
Keep the CRM you already run
Your CRM stays the system of record. Pulse connects through the API you authorize and reads what it needs to verify revenue, attribute it, and run the floor.
GoHighLevel is the deep integration. Pulse reads and writes contacts, opportunities, conversations, and calendar appointments; it reads payment history and never writes it. HubSpot and Close are migration sources rather than ongoing syncs, and the HubSpot connection is a single read-only contacts permission. Do not read those two as GoHighLevel parity: we would rather write it here than have you find it in week three.
Nothing in your account has to be rebuilt to switch this on.
Run the floor on Pulse
Pulse becomes the system of record for what you put in it: contact records with their deal value and stage, the activity and conversation history against them, notes, enrollments, and the next step each one is waiting on.
Yes, that means we hold your records. It is the honest answer, and it is the reason the rest of this page exists. Everything below about isolation, access, retention, and deletion is written for exactly this case. Note the shape rather than assuming a Salesforce clone: one contact is one record, deduplicated on email and phone, and it can sit in several pipelines and programs at once. Collected revenue is read from the sales rails rather than typed in.
Split the responsibilities
Most floors land here. Marketing automation, forms, and existing campaigns stay where they are. The dialer, the ledger, attribution, commissions, and reporting run on Pulse.
A GoHighLevel connection is optional rather than a prerequisite, and the platform runs for an organization that has none. One honest limit before you plan around it: some surfaces that depend on a connection hide themselves cleanly, and others degrade to an empty list or fail the action when a rep reaches for it. We are converging them, and we will tell you which ones matter for the modules you intend to use.
Before anything moves, we write the architecture down
Which system is authoritative for which object, exactly what Pulse reads, what it writes, and what it never touches. Nothing should be migrated on an assumption. If a call ends with your team and ours holding different pictures of that, the call is not finished.
What Pulse can do inside your CRM
This table is generated from the permission contract our code is built against, not typed by hand into a marketing page. A permission cannot be added to the platform without a row appearing here. The authoritative list is the consent screen GoHighLevel shows you at install; this is what our software does with it.
| Object | Read | Write | Delete | What we do with it |
|---|---|---|---|---|
| Account settings and custom fields Required | Yes | No | Nothing | Configuration, tags, and custom field definitions, read only. Pulse writes values into fields you defined, but cannot create or reshape a field. |
| Calendars and appointments Required | Yes | Yes | Nothing | Availability and booked appointments. Written when a call is booked in Pulse or its outcome is recorded. Calendar objects themselves are written for one purpose, on a Private Integration connection only: setting which team members a routing calendar prioritises, so leads reach the right closer. Nothing else about a calendar is changed. |
| Contacts Required | Yes | Yes | Its own status tags, and a contact from a workflow Pulse enrolled them into | The contact record. Read to work the lead; written back so notes, tags, and the fields a rep edits in Pulse land in your CRM rather than only in ours. Pulse deletes two things anywhere in your CRM and both sit here: it replaces its own pulse-status tag when an outcome changes, and when a rep unenrols a contact from Pulse it takes them out of a workflow Pulse enrolled them into. Your CRM does not say who started an enrolment, so if your own automation has since re-enrolled that contact in the same workflow, that enrolment ends too. |
| Conversations and messages Required | Yes | Yes | Nothing | Message history, read for context. Messages Pulse sends are written back, so the CRM holds the whole thread instead of half of it. Opening a brand-new thread for a contact who has never had one is a Private Integration grant the Marketplace app does not request yet; until it is granted, those first messages wait rather than fail. |
| Opportunities Required | Yes | Yes | Nothing | Your pipeline. Read for reporting and attribution, written when a rep moves a deal inside Pulse. |
| Payments Required | Yes | No | Nothing | Orders, transactions, and subscriptions, read only. Revenue is reconciled against the processor's own record and is never written back into your CRM. |
| Staff roster Required | Yes | No | Nothing | Your CRM users, read to map them to Pulse reps so activity is attributed to the right person. |
| The connection itself Required | Yes | Yes | Nothing | The connection's own access and refresh tokens. This is what keeps the integration alive and lets you revoke it. It reads no customer data. |
| Company record Optional | Yes | No | Nothing | Optional, read only. Identifies the agency account an installation belongs to. |
| Documents and contracts Optional | Yes | No | Nothing | Optional, read only. Pulse lists the proposals and contracts in your account so a signed agreement appears against the right contact, and records who signed and when. It reads the document's status and recipients. It never creates, edits, sends, voids, or deletes a document, because the write scope is not requested. |
| Forms Optional | Yes | No | Nothing | Optional, read only. Used to attribute a lead to the form that produced it. |
| Invoices and payment links Private Integration | Yes | Yes | Nothing | The one financial object Pulse creates. When a rep mints a Text2Pay payment link, Pulse creates a draft invoice for that amount and a contact to attach it to. It never edits or deletes an invoice your CRM already holds. |
| Products Optional | Yes | Yes | Nothing | Used to price a payment link against your existing catalogue. The write permission is granted on a Private Integration connection, though no part of the product creates or changes a product or a price today. |
| Surveys Optional | Yes | No | Nothing | Optional, read only. Used for attribution and reporting. |
| Trigger links Optional | Yes | No | Nothing | Optional, read only. Used for attribution and reporting. |
| Workflows and automations Optional | Yes | No | Nothing | Read only, and optional. Pulse can enrol a contact into a workflow you already built, and can take that contact back out of one it enrolled them into. Both run on the contact permission rather than this one, which is why they appear on the Contacts row. The workflow itself is never changed: Pulse cannot create, edit, disable, or delete one, because the write scope is not requested. |
Required permissions are the ones an installation cannot run without. Optional ones feature-gate their surface off when you decline them, and the install still succeeds. The third state is different in a way worth knowing: those grants never appear on the consent screen at all, because they come with a token an administrator creates by ticking scopes inside your own CRM. You control them there rather than here.
And what it cannot do
Each of these is held in place by something other than our good intentions: a permission we never request, a read-only scope, or a rule that fails the build. Where the control is somebody else's, we say whose.
It cannot change your workflows or automations
Pulse can enrol a contact into a workflow you already built. It cannot create, edit, disable, or delete one: no such code path exists in the platform. Where you connect through our marketplace app, GoHighLevel enforces it too, because we request read access to workflows and nothing more.
It cannot reshape your CRM
Pulse writes values into custom fields you already defined, where you configure it to. The field definitions themselves are read only, so the shape of your CRM stays yours to change.
It never rewrites revenue you already recorded
Payment orders and transactions are read for reconciliation and never edited. There is one financial object Pulse creates: when a rep mints a Text2Pay payment link, Pulse creates a draft invoice for that amount and a contact to attach it to. It never alters or deletes an order, a transaction, or an invoice your CRM already holds, so a figure your books depend on cannot be moved by ours.
It deletes two things, and both of them are its own
The first is its own status tag. When a call outcome changes, the previous pulse-status tag is replaced so a contact never carries two contradictory outcomes. The removal is filtered to that namespace, so a tag you wrote, or one another tool wrote, is never removed. The second is an automation enrolment Pulse itself started: a rep who enrols a contact into one of your workflows from Pulse can end that enrolment from Pulse too, because an action you can only undo inside your CRM is a half-finished one. Pulse only offers this for a contact it enrolled from Pulse, and the workflow itself is never touched. One limit, stated plainly: your CRM does not tell Pulse who started an enrolment or when one finishes, so if that contact completes the workflow and your own automation later enrols them in it again, ending it from Pulse ends that enrolment too. Pulse does add other tags when you ask it to, for example when importing a list; adding is not removing, and only removal is constrained this way.
It does not delete your CRM records
No path in Pulse deletes a contact, an opportunity, a conversation, an appointment, or a workflow inside your connected CRM. It can set an appointment status, including to cancelled, when a call outcome says so, and it can take a contact back out of an automation it put them into, both of which change a record rather than remove one. A test in our build scans the integration modules that hold these endpoints and fails if a delete call appears in one we have not accounted for here, which forces this page to change in the same commit.
It never receives a card number
Revenue is verified from processor transaction records: identifiers, amounts, currency, status, timestamps, and the buyer name and email where the processor supplies them. Full payment card numbers are never sent to us and are never stored by us.
What happens if you go
A company confident in its product does not need to trap anybody in it. This is the part most vendors leave vague, so it is written here in the same detail as everything else.
Disconnect whenever you want
Remove the credential in Pulse, or revoke it in the CRM that issued it. Access stops at the next call. There is no instant uninstall signal, so a revocation you perform on your side is discovered when the next request or refresh fails rather than the moment you click it. For a connection authorized through our marketplace app, a dead refresh chain is caught by an hourly job, the connection is marked invalid, and we stop using it until you reconnect. For a connection using a token you issued and pasted in, the failure surfaces as a health alert to your administrator, because there is no refresh chain for us to observe.
Your systems keep running
Pulse installs no workflows, no automations, and no custom field definitions into your account, and our marketplace app does not request the permissions that would let it. It does create the objects you ask it to create, such as contacts, appointments, and payment-link invoices, and those stay in your account afterwards. Removing the connection removes our access, not your configuration.
Getting your data out
Reporting surfaces export to CSV directly, and a partner-scoped read API is available for metrics. There is no one-click archive of everything today, so a full extract is an operator-assisted request. We would rather write that sentence than imply a button that is not there. Our privacy policy commits to a 30 day export window after termination.
Retention and deletion
Several retention jobs run automatically. A 90 day window prunes internal monitoring and error telemetry, and another prunes completed workflow execution records. Your core business records, meaning sales, calls, contacts, messages, and ledger entries, are kept for the life of the account. One exception worth knowing: to control storage cost, call recordings shorter than a set threshold are not retained. Ledger entries are immutable by design, with update and delete revoked at the database role level, and are not deleted one at a time. Where erasure of personal data is required and lawful, we anonymize the identifying fields and keep the financial record so your history still balances; today that is a commitment our team carries out on request rather than a self-serve feature, and we would rather say which it is.
The ten hard gates
These are not guidelines. Each one is enforced automatically, and a violation stops the deployment. The left column is the engineering rule. The right column is what it means for your money.
Reconciliation is the product. The rest is table stakes.
Reconcile to the processor ledger, not the webhook stream
Webhooks drop, duplicate, and arrive out of order. They are hints. The balance transaction API is truth, so we poll it, store it raw, and reconcile against it.
Reconcile to the processor today, the bank next
Pulse reconciles against the processor record. The bank settlement leg — the third way — is designed and not yet fed by a live bank feed, so we say two way until it runs, because a reconciliation page that overstates its own coverage defeats its purpose.
Reconcile continuously, close daily
Not monthly. A break found 28 days late has already contaminated commission, EPSC, and every dashboard downstream of it.
Breaks are first class objects
Every break has an ID, an owner, an age, a dollar amount, and a status. Aged breaks escalate on their own. An untracked break is an unfixed break.
Payouts are modeled, not assumed
Money in transit lives in a real clearing account with a real balance. Cash collected is not cash received, and the gap between them is a number we can show you.
Suspense for anything unclassified
We never force an unknown into revenue to make a report balance. It goes to suspense, suspense is monitored, and an aged non zero balance raises an alert.
How correctness is proven rather than asserted
Application code validating itself is a user experience improvement. It is not a guarantee. Anything that must be true is enforced by the database and verified by jobs that run whether anyone is looking or not.
Invariants live in the database
Check constraints, unique constraints, foreign keys, and triggers. If it must be true, Postgres enforces it, not a code path someone can forget to call.
Continuous invariant checking
Trial balance equals zero. Cached balances match computed balances. No orphan entries. No sequence gaps. Runs on a schedule and alerts on drift, so we find the break before you do.
Tamper evidence by hash chaining
Each entry carries a hash of the previous entry plus its own canonical payload. Silent mutation becomes detectable, which is what makes immutable a verifiable claim rather than a policy.
Property based testing on the core
Thousands of randomly generated valid transaction sequences, with every invariant asserted after each one. Example based tests only find the bugs someone already imagined.
Every surfaced number has a lineage query
Any figure on any dashboard, report, or invoice expands to the exact entries that compose it. One click, no exceptions.
Sanity bounds on every metric
Upper bound, lower bound, and expected rate of change are declared per metric. Anything outside its bounds alerts before it ever reaches a screen.
Your credentials and your customers
Envelope encryption
Credentials in the platform vault are envelope encrypted: a per tenant data key, with the tenant bound into the encryption context so one partner's key cannot decrypt another partner's record. The secret itself is encrypted in our own database under that data key and never leaves it in the clear. Data keys created since the cutover are wrapped by a key held in AWS Key Management Service; keys created before it are still wrapped by a key held in our environment until the re-wrap migration reaches them, so both backends are mounted at once by design. Some older credential records predate the vault entirely and are being migrated onto it. We will not publish a blanket sentence that is true of most of our credentials, and we will walk your security team through exactly where that migration stands under NDA rather than describing it in public.
Least privilege at the database role
The application role holds insert and select on ledger tables and nothing else. Corrections route through a dedicated procedure with approval. The dangerous operation is impossible rather than merely forbidden.
Audit trail for ledger entries
Every ledger entry carries who wrote it, which system it came from, when it happened, when we learned about it, and the period it belongs to. Amendments and corrections additionally carry a stated reason and a named approver. Request ID and IP are captured on the approval workflow, not yet on every journal write.
Recovery is a drill, not a hope
Point in time restore is a documented quarterly drill with an append only log of every run — including, honestly, a log that starts empty. A backup that has never been restored is a hypothesis; each rehearsal on the record is what turns it into a fact.
Tenant isolation
Partner organizations are isolated at the data layer with per tenant encryption context. No aggregate we publish, including the live figures on this site, can be decomposed back to a single partner.
Permissions for your own team
Access is a capability model rather than a job title. Where a page or an action is bound to it, the permission resolves server side, so it is enforced at the API rather than by hiding a button from somebody who could still call the endpoint. Coverage is real but not yet total: actions that are not bound to the cascade fall back to the role checks around them, and we will show your team the map instead of implying it is finished. Your admins set role defaults and per person grants, and every change to who can do what is written to the audit log.
Who at ScaleWithData can see your data
Platform administrators can reach across organizations for support and engineering. That reach comes from holding the administrator role rather than from a curated list, so any account holding it sees every organization, and we will tell you on request how many accounts hold it today and who they are. Every other account, a partner scoped admin included, is confined to the organizations assigned to it by the same partner scope check that serves your users; an assignment can cover more than one. Administrative changes are recorded with the actor who made them, and we will state the limit plainly rather than imply more: that log records changes, not every read.
What reaches an AI model
Call audio goes to a transcription provider to become a transcript. That transcript, with its speaker labels, and the CRM context needed for one specific task then go to our AI providers for call review, coaching summaries, and the assistant. There are two of them, both listed below, and which one runs depends on the feature. Where a message is being drafted for one of your leads, that lead's own details are in the prompt by design, because that is what makes the draft usable. We do not use your data to train models ourselves. Whether a provider trains on API content is governed by that provider's commercial terms rather than by anything we can enforce in code, so we will give you the current position for each one in writing rather than assert it in a sentence you cannot check. If AI processing is unacceptable to you, we can switch it off for your organization alone: no call audio, no transcript, and no CRM context is sent to a model provider for you, while other organizations are unaffected. Two limits are worth knowing before you rely on that. It covers the transcription path and the per organization AI features, and it does not yet cover the internal Pulse AI assistant, whose context is assembled across every organization by design and which only our own agency administrators can reach; scoping that one is a redesign rather than a setting, and until it is done we will say so rather than imply otherwise. Second, the switch is an operator action today rather than a control in your own settings, so it is a request you make to us and we carry out.
Period close and freeze
Once an accounting period closes, entries dated to it are rejected. Corrections post to the current open period with a reference back. Historical reporting stays stable enough to put in front of a client.
Who touches your data, and which data they touch
A list of vendor names is not a disclosure. The next question is always which of your data each one receives, so that is the table. We commit to giving notice before adding a new provider that processes customer data. That one is a promise from us rather than something a build gate holds us to, and we would rather mark the difference than let it read like the table above it.
| Provider | What it receives | Purpose | When |
|---|---|---|---|
| Amazon Web Services | The key that wraps the vault's encryption keys | Key management | Where key-service wrapping is enabled |
| Railway | Application traffic and runtime, and access tokens for connections you authorize, held as environment variables | Hosting | Always |
| TiDB Cloud | The primary database: contacts, sales, calls, messages | Application database | Always |
| Supabase | The ledger (revenue events, consent records, error reports) and stored files including call recordings and sale evidence | Ledger database and file storage | Always |
| Clerk | Identifiers and session data for your users | Authentication | Always |
| Sentry | Application error diagnostics | Error monitoring | Always |
| Inngest | Job scheduling data, including the lead name, email, and phone carried on the events that trigger a job | Background job orchestration | Always |
| Resend | Email addresses and message content for platform email | Transactional email | Always |
| GoHighLevel | The CRM data covered by the permissions above, plus messages we mirror into your conversations | Your own CRM, connected by you | If you connect a location |
| Payment processors | Buyer name and email, amounts, and any checkout we mint. Stripe, PayPal, Whop, Affirm, Klarna, FanBasis, PayFunnels, SamCart, Elective, Authorize.net, GHL Payments | Reading the transactions we reconcile against, and creating payment links | The rails you connect |
| Twilio | Phone numbers, call audio, and call metadata | Voice calling, and carrier lookup on numbers you import | If you dial through Pulse or import numbers |
| Sendblue | Phone numbers and message content | iMessage and SMS | If you message through Pulse |
| ElevenLabs | Call and voicemail audio, and text we synthesize into speech | Speech to text, and voice for roleplay | If you transcribe calls or use a voice feature |
| Anthropic | Call transcripts and the CRM context for a specific task | Call review, coaching, assistant | Where AI features are on |
| LLM gateway | Call transcripts, rep and lead names, and files you upload to the assistant. An OpenAI-compatible gateway fronting a Google Gemini model | A second model used for call analysis and drafting | Where AI features are on |
| Fathom | A search window and our key. Fathom sends us the recordings and transcripts it already made | Reading meetings you capture in Fathom | If you connect a Fathom workspace |
| The contents of a spreadsheet you connect, and email you send through a connected Gmail account | Spreadsheet revenue sync and email sending | If you sync a sheet or connect Gmail | |
| Slack | Lead names, sale amounts, and rep activity in the notifications you route | Your floor's own alerts and the internal assistant | If you connect a workspace |
| PandaDoc | Recipient name and email, and the document itself | Contracts and e-signature | If you send documents through Pulse |
| Customer.io | Customer identifiers and the attributes we push | Lifecycle messaging | If you connect it |
| Calendly | Invitee name, email, and booking details | Scheduling | If you connect Calendly |
| Other tools you connect | Whatever that tool is for. Zoom for scheduling, Typeform for form responses, Circle for community membership, SamCart for orders | The integration you switched on | Only the ones you connect |
| Meta | Email and phone SHA-256 hashed before they leave us, plus the visitor's IP address and browser user agent unhashed, and the conversion value | Conversion reporting for your own ads | Off unless you configure and enable it |
The last column is the one that matters most. Several of these receive nothing at all unless you switch on the feature that needs them, and a list that flattened that distinction would overstate our data sharing as badly as omitting a provider would understate it.
Responsible disclosure
If you believe you have found a security vulnerability, email security@scalewithdata.ai with enough detail to reproduce it. We will acknowledge within two business days and keep you updated until it is resolved.
Please do not run automated scanning against production, access data that is not yours, or degrade service for other customers while testing. We will not pursue action against researchers who follow those rules and report in good faith.
What we will not claim
We are not going to claim a certification we do not hold. If a formal audit report is a requirement for your organization, raise it on the call and we will tell you plainly where we are in that process and what we can provide in the meantime.
Ask us for the architecture review
Bring the people who will have to live with the decision. We will walk your team through exactly what Pulse would read from your systems, what it would write back, which system stays authoritative for which object, and how access is revoked. You should not have to take any of this page on faith.
Bring your engineer to the demo.
We will open the ledger schema, show you a live reconciliation run, and trace one dollar from ad click to verified commission. Technical questions welcome.