A transparent look at how FieldPulse handles your Salesforce data — our architecture, permissions, and the promises we make to the people who install us.
A plain-language walkthrough of how FieldPulse works under the hood, what it can and cannot access, and why you can trust it on your Salesforce org.
FieldPulse reads field metadata from your active Salesforce session, computes health analytics entirely inside your browser, and never sends anything to any server we control — because we don't have any.
These are not marketing claims — they are architectural facts. The rest of this document shows you exactly how each pledge is enforced in code.
FieldPulse has no backend. There is no FieldPulse cloud, API, or database. Every calculation runs inside your Chrome browser on your machine.
No analytics SDK, no event tracking, no error reporting services. We don't know when you use the extension, what records you view, or what fields exist in your org.
FieldPulse never asks for, sees, or stores your Salesforce username or password. It uses the session cookie your browser already has.
FieldPulse performs only SELECT and COUNT queries against the Salesforce REST API. It is architecturally incapable of modifying records, fields, or metadata.
If you are a Salesforce admin, consultant, or data architect evaluating whether FieldPulse is safe to install on a production org — this document exists for you. Everything here is independently verifiable: the extension source code is readable, the permissions are declared in the manifest, and network traffic can be inspected in DevTools.
Think of FieldPulse as a calculator that lives inside your Chrome extension tray. It borrows your open Salesforce session, reads field data, does math, and shows you the result. Nothing leaves the calculator.
Every byte of Salesforce data touched by FieldPulse follows this exact path. Notice what's missing: a FieldPulse server.
*.salesforce.com, *.force.com, *.my.salesforce.com, and *.lightning.force.com.A trust boundary shows which components can see which data. FieldPulse has only two boundaries: your device and your Salesforce org. Nothing else.
Most extensions introduce a third trust zone — "the vendor's cloud" — where your data is processed, logged, or stored. FieldPulse deliberately has none. If our company disappeared tomorrow, no FieldPulse-hosted data would be at risk, because no such data exists.
FieldPulse never asks for your Salesforce credentials. It borrows the session you already established when you logged in to Salesforce in your browser.
Chrome extensions declare their permissions upfront in manifest.json. Here is each one FieldPulse requests, exactly why, and what it does not let us do.
| Permission | Why FieldPulse needs it | What it does NOT allow |
|---|---|---|
activeTab |
Detect when you're on a Salesforce record page and inject the overlay only into that tab. | Cannot access other tabs, history, or bookmarks. |
storage |
Save your preferences (overlay on/off, tooltip toggle) and cache field analytics locally. | Cannot sync to any cloud. Storage stays on this device. |
sidePanel |
Render the analytics dashboard in Chrome's native side panel. | Cannot open panels outside FieldPulse's own UI. |
scripting |
Inject the overlay script into Salesforce pages when you navigate to a record. | Cannot inject into non-Salesforce sites — host permissions restrict it. |
alarms |
Run a background timer to refresh stale cache entries every 30 minutes. | Cannot schedule network calls outside Salesforce. Only triggers internal cache refresh. |
cookies |
Read the Salesforce sid session cookie to authenticate REST API calls. |
Scoped to Salesforce domains only. Cannot read cookies from Gmail, banking, or any other site. |
The extension can only execute on these four domain patterns, declared in manifest.json:
Outside these domains, FieldPulse is dormant. It cannot read, modify, or observe anything on any other website.
The extension enforces script-src 'self'; object-src 'self' — meaning only scripts bundled inside the extension package can run. No inline scripts, no remote CDNs, no eval(). This prevents injected or tampered code from executing.
FieldPulse caches analytics locally to make repeat visits instant. All cache lives on your device. You can clear it at any time from the extension settings.
| Storage Layer | What it contains | Retention | Location |
|---|---|---|---|
| Session Storage | Most recent analytics result for the current browsing session | Until tab closes | Chrome session memory |
| IndexedDB | Field metadata, fill rates, edit-frequency counts | 1 hour – 7 days (by type) | Chrome profile folder, on this device |
| Local Storage | Your preferences (fp_settings) and recent records list (fp_recent) |
Until you uninstall or clear | Chrome profile folder, on this device |
| Data type | Time-to-live | Why this duration |
|---|---|---|
| Field metadata | 7 days | Schema changes infrequently |
| Fill rates | 1 day | Daily refresh covers typical org activity |
| Edit frequency | 1 hour | Recent edit counts need to be current |
| Record counts | 6 hours | Totals change slowly |
Uninstalling FieldPulse from Chrome deletes all three storage layers. The "Clear Cache" button inside the extension performs the same wipe on demand. We have no way to recover the data because we never had a copy.
COUNT(field)), not individual record content.Sometimes the strongest trust signal is a clear list of things an extension cannot and will not do — backed by architecture, not just policy.
*.salesforce.com or its variants.Every claim in this document is independently verifiable. Here is how to audit FieldPulse in about ten minutes.
Chrome shows every permission the extension requests before you install it. Post-install, go to chrome://extensions, find FieldPulse, click "Details", and review "Permissions" and "Site access". The full set should match the table on page 07.
Open chrome://extensions, enable "Developer mode", then click "Inspect views: service worker". In the Sources panel, open manifest.json. The permissions, host_permissions, and content_security_policy blocks are the source of truth.
Open Chrome DevTools → Network tab while using FieldPulse on a record page. Filter by "Fetch/XHR". Every request's "Domain" column should show only your Salesforce domains. If you ever see a request going anywhere else, that is a bug — report it.
You will see requests to yourorg.my.salesforce.com/services/data/v62.0/... and nothing else. No analytics beacons, no third-party CDNs, no error-reporting endpoints.
Chrome extensions ship as unminified JavaScript. On Windows, the extension folder lives under %LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions\. You can open every file in a text editor — there are no bundlers, no transpilers, no hidden build steps. What you see is what runs.
The full privacy policy is published at forcenaut.com/fieldpulse/privacy-policy.html and bundled with the extension. It echoes the promises in this document in formal legal language.
We chose not to minify, bundle, or obfuscate the extension. The entire codebase is approximately 2,300 lines of plain JavaScript — readable in an afternoon by a developer comfortable with vanilla JS.
If you discover a vulnerability, privacy issue, or behavior that contradicts anything in this document, we want to hear about it first — before anyone else does.
Please email us directly rather than filing a public issue. We aim to acknowledge reports within 2 business days and issue a fix (or a mitigation plan) within 14 days for valid security issues.
Email: srbagal.ceo@gmail.com
Subject line: "FieldPulse Security"
Extension version, Chrome version, steps to reproduce, and — if relevant — a screenshot of DevTools showing the unexpected behavior.
Trust is earned by operating transparently for a long time. If you've read this far, thank you for caring about the data your team handles — that's exactly the mindset FieldPulse was built for.