Privacy Policy

Effective date: September 9, 2026 · Applies to the OrgTriage browser extension, version 0.8.5 and later. Published by Everything Virtually LLC.

The short version

OrgTriage runs entirely in your browser. We do not collect, transmit, store, sell, or share any of your data — because there is nowhere for it to go. OrgTriage has no servers, no analytics, no telemetry, no accounts, and no third-party services.

What OrgTriage reads, and where it goes

OrgTriage analyzes how your Salesforce org is configured. To do that it reads metadata from your org — Apex classes and triggers (inventory, coverage, and source), Flows and their definitions, workflow rules, validation rules, custom field definitions, custom buttons and links (their URLs), reports and dashboards (their definitions, never their results), page layouts, Lightning pages, custom stylesheets, permission sets and their assignments, licence seat counts, Salesforce's own Health Check results, release-update status, org limits, scheduled jobs and job run history — and turns them into findings. All analysis happens in your browser. Nothing is uploaded anywhere.

OrgTriage does not read your business records. It never runs a report, and it queries no Account, Contact, Opportunity, Case, or custom business object rows. It does read Apex source code, because two of its checks need it: the code-quality lint (queries inside loops, missing sharing declarations, empty catch blocks, hard-coded ids) and the field-reference scan, which looks for field names inside Apex bodies, flow definitions and validation rules. That source stays in your browser like everything else, and only findings about it — a class name and a line number — are kept in the local cache.

Where people appear in the results

Some findings are only useful if they name a person, so two analyzers read a limited amount of user information from your org. This is the complete list:

Ops — user names and active status (User: Id, Name, IsActive), to say who owns a scheduled job that has stopped, or who a stalled approval is waiting on. A nightly process silently failing because its owner was deactivated is one of the problems OrgTriage exists to catch, and it cannot be reported without the name.
Ops — pending approval requests (ProcessInstance and its work items): the record id the approval is for, the approval process name, when it was submitted, and the assigned and original approver. The record id is kept so the finding can link to it; the record itself is never read.
Ops — failed and paused flow runs (FlowInterview): the flow's label, the element it stopped at, the pause label, and who started it.
Ops — failed Apex jobs (AsyncApexJob): the job's class, type, status, and the first 120 characters of its error message, which can contain whatever the failing code put there.
Ops — login counts, grouped by user, application, and login type over the last week — so you can see what is calling your API. This is an aggregate count only: no IP addresses, individual timestamps, or browser details.
Access — who holds powerful permissions (User: Id, Name, Username, IsActive, UserType, LastLoginDate, CreatedDate, Profile name and the profile's licence id; PermissionSetAssignment with the same assignee fields). These are needed to say who holds Modify All Data, whether they still log in, and by which route. Usernames are read here because permission set assignments identify people by them; email addresses and passwords are never read.
Access — licence seat counts (UserLicense: name, label, total and used seats, status). These are the numbers on Setup > Company Information. They are joined to the users above to count seats held by people who no longer log in; the finding reports counts per licence type, not names.

This is your own organization's employee information, and it stays on your device exactly like everything else. It is never transmitted to us.

OrgTriage can never see more than your own Salesforce permissions allow — field-level security, object permissions, and sharing rules are always enforced by Salesforce itself. If your user cannot see something, neither can OrgTriage.

Your Salesforce connection

OrgTriage reuses the Salesforce session from your existing browser login to call the Salesforce API directly from your browser to your org — the same approach used by browser extensions that Salesforce administrators install. Your session token and your org's data never pass through any OrgTriage system, because none exists.

The session token is handled only inside the extension's service worker. It is held in memory for at most five minutes, is never written to disk, never logged, never shown, and is discarded the moment you sign out of Salesforce. OrgTriage never asks for your password and creates no credential of its own.

What stays on your device

Scan results are cached in your browser's local storage so reopening the panel does not re-run a scan — every scan spends your org's daily API allowance, so caching saves you real quota. Your panel preferences are stored the same way.

The cache holds analysis output: component names and labels, Salesforce record ids, dates, counts, rule verdicts, and — for the people-related findings above — user names, usernames, and the approval and job details listed. Note that your component API names and the names of your users are your organization's confidential information; they remain on your device, and should be treated like anything else cached locally on a shared or managed machine.

You can clear it at any time with Clear local snapshots in the panel overview, and removing the extension deletes everything.

Exporting

The remediation plan page can export a plan as CSV or Markdown, or print it. These files are generated in your browser and saved only where you choose. They are not uploaded, and no copy is kept.

Browser permissions, explained

OrgTriage requests the minimum its features need: cookies (reuse your own Salesforce session for API calls, limited to Salesforce domains) and storage (keep your cached scans and preferences on your device). Host access is limited to the Salesforce domains listed in the extension's manifest, including sandbox, Government Cloud, and China instances.

OrgTriage deliberately does not request tabs (it cannot see your browsing history), scripting, declarativeNetRequest, activeTab, or downloads. It does not run on, read, or affect any website that is not Salesforce.

What we don't do

No analytics or usage tracking. No crash reporting. No advertising or ad identifiers. No selling or sharing of data (there is none to sell). No remote code: everything the extension runs ships inside the extension package reviewed by the Chrome Web Store. The extension's Content Security Policy restricts it to Salesforce hosts, so there is no other destination it could reach.

Children's privacy

OrgTriage is a business tool for Salesforce administrators, not directed at children, and — consistent with everything above — collects no data from anyone of any age.

Changes to this policy

If a future feature ever changes this picture, we will update this policy before that feature ships and clearly label any mode in which data leaves your machine. The core promise will not change: OrgTriage's analysis runs locally.

Terms of use

This policy covers what OrgTriage reads and where it goes. What the extension warrants — nothing — and how its findings should be treated is in the terms of use: OrgTriage is a diagnostic tool, not an adviser, it is provided as is, and every finding is a recommendation for an experienced administrator or developer to verify.

Contact

Questions: mike@everythingvirtually.com · Everything Virtually LLC.