What DewWow Org Launcher Calls

If your security team wants to know what this app talks to, this page is the answer.

It describes the Mac app. A Windows version is coming in the near future, and this page will be updated for it. Every call listed below is made to Salesforce in the same way whichever computer the app is running on.

Org Launcher never asks for a Salesforce password and never stores one. It uses the login the Salesforce CLI already holds on your Mac. When a feature needs to call Salesforce directly, the app asks the CLI for that login. The token it gets back is kept in memory while the app runs, and is never written to disk, never written to a log, and never sent anywhere except the org it came from.

Three features never handle a token at all — Storage and Limits, Setup Audit Trail, and Inspect Changes. They ask the Salesforce CLI to do the work and read back the result.

The Salesforce CLI's answer to sf org list also contains an access token for every login. Org Launcher reads that answer for names and connection status only. It does not keep those tokens, use them, or save them with the org list.

More than one login to the same org. You can sign in to one org as several different users — an admin and a test user, for example. Each user sees different records and fields, so Org Launcher treats every login as its own card and always acts as exactly that user. Every call below that names an org passes the login's username, never an alias, because an alias can be moved to a different user at any time. A token is only used after the app has checked it belongs to that username.

Which API version

One version is used for everything the app calls directly, and your org chooses it, not the app. It is the version the Salesforce CLI reports for that org. If the CLI does not report one, the app uses 62.0. Paths are built as <your instance>/services/data/v<version>/…

Three things sit outside that rule: paging links come back from Salesforce already formed, so the app follows them exactly as given; retrieving metadata for Inspect Changes is pinned to 62.0; and the Salesforce Trust status service has its own version, v1, which has nothing to do with your org.

Anything run through the Salesforce CLI passes no version at all, so the CLI picks its own. Those rows are marked CLI below.

Opening and managing orgs

Opening an org gets a one-time login link and hands it to your browser. The app makes no request to that link itself.

The org list checks every login at the same moment. When it cannot refresh a login's access, it reports only that the refresh failed, not why, and with many logins most of those failures come from the check itself: on a list of 111, 79 logins reported this way and every one of them opened normally. So a login reported that way shows as "Checking…" and is asked about again on its own, at most four at a time, in the background. Only that answer can mark it as needing a login, and it is remembered for 30 minutes.

Removing a login checks the alias list first. The Salesforce CLI logs out every login that matches the name it is given, by username or by alias, so if an alias somewhere else happened to equal this username, a second login would go too. The app refuses in that case and says which alias to rename.

While it is waiting for a login you started in the browser, Org Launcher watches the folder where the Salesforce CLI keeps its stored logins, ~/.sfdx. It reads the file names and modification times only — it never opens those files, because their contents hold the refresh token, and it never writes or changes anything there. That is how it can tell a login has landed without running a command, which on some Macs takes several seconds.

Two of the rows above exist only to notice when a login you started in the browser has finished. Listing the orgs normally checks every stored login, which is a round trip to Salesforce per org; while it is waiting for a new org to appear the app asks for the list without those checks, and while it is waiting for one org to reconnect it asks about that org alone. Both are read-only, and the same look runs when you press I’ve finished signing in.

Storage, limits, and Trust status

The Trust requests carry no login, no token and no org id. Only the instance name travels, in the address. They can be switched off in Settings.

Inspect Changes

Release Updates

The only call in the app that uses the Tooling API — release updates are not in the ordinary data API, so there is no other way to read them. One request per org, and reading changes nothing: the app never activates a release update, because doing that changes how an org behaves. That decision stays in Salesforce Setup.

Email Domains

Salesforce reports whether it considers a domain verified. It cannot report whether the DNS record behind it is still published, so the app can check that itself. Those DNS lookups are switched off until you turn them on — they are the only requests the app makes that go neither to Salesforce nor to this site. They go to whichever DNS resolver your Mac uses, they reveal which domains are being checked, and they read only public records. A lookup that does not answer is reported as “could not check”, never as a fault, because a slow or filtered DNS server would otherwise look identical to a misconfigured client.

Setup Audit Trail

One query, up to 2,000 rows, limited to the last 7, 30 or 90 days. Searching and filtering happen on your Mac.

Query Records

One round trip per 2,000 records. Copy, CSV export and Excel export all work on data already downloaded.

Choosing an object reads that object's fields and related lists once, then looks at up to 200 of its most recently changed records to see which fields your org fills in. That is one extra read-only query — or, where the org refuses the shorthand for asking about every field, the fields are named instead, split across at most four requests so a wide object cannot overrun the address — and only when you pick an object — a query that arrives another way is not sampled unless you ask for it. Nothing is written, and the records are counted in memory and never saved. The record counts are the ones Salesforce reports itself; they are approximate and are used only to decide which objects to show you first.

Data Import

Up to 200 records per call, always with allOrNone off, so one bad row never rolls back the rest and every row gets its own result. Updates and deletes read the existing records first and write a backup file to your Mac before anything changes.

Find Duplicates

To read what this feature does for you, see the page about finding and merging Salesforce duplicates.

A match field can live on a record the chosen one points at — a contact's account name, for example. Salesforce's Bulk query accepts that directly, so it simply joins the list of fields asked for and comes back as another column; no extra request is made for it. The only extra call is one describe, to list the fields that linked record has, and it happens when you open that link on screen rather than up front. Comparing more than one kind of record runs one Bulk job per kind, one after another, each with its own paging cursor so an interrupted download resumes in the right place in the right job. After that, every record is read, checked and changed as its own kind: extra fields and related records are asked of each kind's own object, the check before a change asks each kind separately, tags and filled-in values are sent one kind at a time, and a group holding more than one kind is never merged.

Leads that have already been converted are left out unless you ask for them, by adding IsConverted = false to that download's filter. It is added only to the query for a kind of record that has the field — asking a Contact for it is a query error, not an empty answer — and any filter you typed yourself is wrapped in brackets before it, so an OR in your filter still means what you wrote.

Records arrive in pages of up to 50,000 and are saved to your Mac as they come, so an interrupted download resumes exactly where it stopped. The matching itself happens entirely on your Mac — no record is sent back to Salesforce to be compared. That includes checking a large group a second time to see whether it is really one group of duplicates or a chain of near-misses, and holding a group back when it holds more different-looking records than your limit: both read nothing new and call nothing, and changing either compares again using the copy already on your Mac. Merging exists only in the SOAP API, so the app uses SOAP for merges. The only other SOAP call it makes is Put Back, in Data Backup. Merges are sent one at a time to stay clear of record locks. Accounts, Contacts and Leads can be merged. Salesforce's merge call refuses Cases, so duplicate Cases, like duplicates of every other object, can be tagged, or deleted to the Recycle Bin, instead.

Data Backup

To read what Data Backup does for you, see the page about backing up Salesforce to your Mac.

Data Backup is the one paid part of the app, and it is also the one part that writes a lot to your disk. What it reads from Salesforce, and what a restore writes back into your org, is listed here. What it writes to your disk is listed further down. Nothing it backs up is ever sent anywhere, except back into your own org when you restore. The records and files go from your org straight to a folder on your Mac. There is no DewWow server in the middle and no DewWow cloud storage.

A backup belongs to one login of an org, never to the org as a whole, because two users of the same org see different records and different fields. Every call below is made as exactly that user.

Working out what to back up

Objects are the ones the org says it will read in bulk and that Salesforce's own replication rules support, plus Salesforce Files, attachments and documents by name — Salesforce does not mark Files as replicateable, so the plain rule would leave every file out without a word. That is fewer objects than everything the org will read, so it is worth knowing which: measured on a developer org, 541 objects by default out of the 1,514 that org can read in bulk, every custom object holding records among them, and 331 more if you switch history and feed records on. Sharing tables, Libraries, Reports and Dashboards are not backed up, and the app has no setting to add them. Fields are every field except compound address and geolocation fields (their separate parts are included), file bodies, which come as real files instead, and formula and roll-up fields, which Salesforce works out and cannot restore. Describes go 25 at a time in one call, which Salesforce counts as a single request.

The permission question is asked when the backup window opens, before anything is backed up, because a login without View All Data copies only what sharing lets it see and one without Query All Files gets only the files shared with it. The window says so in both cases. If the question itself is refused, it says nothing rather than reporting a problem nobody has.

Reading the records

Every backup counts first. One call per 25 objects asks how many records each object would give — everything on a first backup, and what has changed after that. An object holding nothing is not asked for at all, and still gets its file, with the column names and no rows. An object of 10,000 records or fewer is read with an ordinary query, which answers straight away in pages of 2,000 — unless its own query is too long to travel in a web address, which an object with hundreds of fields manages however few records it holds. A larger one, and a wider one, are read with a bulk job, which carries the query in the body of the request and takes several seconds to prepare whatever its size. Which route an object takes can change as it grows, so the two write identical rows: the file does not change because the backup got faster. If Salesforce refuses to count an object, it is read in full rather than assumed to be empty. Up to six objects are read at the same time.

Records arrive as CSV in pages of up to 50,000 rows. A page that comes back larger than 64 MB is asked for again at half the size, down to a floor of 10,000 rows. Each page is written to disk with its place in the download in one step, so an interruption anywhere carries on exactly where it stopped, and a download stops rather than filling the disk. The room it leaves clear is a tenth of the drive, never more than 2 GB and never less than 50 MB: a flat two gigabytes is right for a hard disk and impossible on a small USB stick, which would then refuse every backup however empty it was.

The first backup reads everything. After that each object is asked only for what changed since a mark left by the last backup — SystemModstamp, LastModifiedDate or CreatedDate, whichever it has. That mark is Salesforce's own clock, five minutes before the last job was created; your Mac's clock never decides what has changed. queryAll is used wherever the object has an IsDeleted field, so one job brings back edits and Recycle Bin deletions together, and for Tasks and Events, whose archived rows a plain query does not return. Counting first is also what keeps an hourly backup inside Salesforce's limits — 541 objects with a bulk job each, every hour, would be 13,000 jobs a day against a limit of 10,000.

Files, and which record each belongs to

A bulk query cannot return a file's contents, so each file body is one REST request. Bodies stream straight to disk and are never held in memory: a Salesforce File is checked against the checksum Salesforce publishes for it, an attachment or document against the length Salesforce reports, and only then does the file move into place. A body already on your disk is never fetched again and never written over. A file that fails is tried once in each backup. After three failed tries it is left out with the reason recorded, and the next complete backup tries it again. The list of which record each file belongs to is fetched in full every run, because Salesforce refuses every filter on it except the ones naming ids, so there is no way to ask for only what changed.

Deletions

Salesforce keeps about a month of purge history, so the app asks for a window of at most 29 days and falls back to comparing record ids beyond that. Comparing ids reads every id of an object, so at most 25 objects fall back in one run; the rest keep their place and the next run reaches them.

Putting records back

These are the only Data Backup calls that write into your org, and each happens only when you press it.

Put Back happens only when you press it, after the window has said how many records and which org. It works as the backup's own login, so it can only put back what that login may undelete. A record can come back with its parent, and a call that timed out may still have been carried out, so no record is reported as not put back until the org has been asked whether it is back.

Putting changed values back happens only when you press Restore, for the records and fields you ticked, after the window has said how many records and which org. The backup's time is Salesforce's own clock when that backup started, less five minutes. One look reads up to 20,000 changed records, newest change first, and Look Further Back carries on from there. Before anything is written, the values the chosen fields hold now are saved to a CSV file in your Downloads folder, which Data Import can load to undo it. Encrypted text fields are never offered, because a backup can hold the mask Salesforce shows in place of the value, and writing the mask back would replace the real one.

Staying out of the org's way

GET /limits is read before a backup starts and again every 50 file bodies — not before each one, which would double the requests this part of the app makes. It can be read that much less often because a file's contents are exactly one request, so the app always knows how many more of its own it may make before the line below, and never goes past that without asking again. When the org's remaining daily API requests fall below a fifth of its allowance, file downloads stop and the next run carries on — a first backup of a large library cannot finish in a day on most orgs and must not starve the org's own integrations. The same answer's Date header is what the app uses as "now".

The subscription check

These are the only requests in the whole app that identify a customer, and they happen only after somebody has entered a subscription key. A copy of the app with no key never contacts the subscription service at all — not during the 14-day free trial, which needs no card, no account and no network, and not if backup is never used. What the check sends is three things: the subscription key, a value standing for this computer which is a one-way code made from the Mac's hardware id and cannot be turned back into it, and the app's version number. Nothing else: no org name, no username, no instance, and nothing read from Salesforce. Releasing a computer sends the key and either this computer's code or a handle the server gave out for the other computer; one computer is never told another computer's code. Cookies are off for both requests and nothing is cached.

The answer carries a short signed permit. The app checks the signature and the dates on your Mac and writes the permit to a file, so a scheduled backup decides entirely offline. While the app is open it checks once a day, once more the first time a new version of the app is opened, and whenever a key is entered or Check Now is pressed. A scheduled run makes this call only when the stored permit is within three days of running out. The key and the permit are files under ~/Library/Application Support/OrgLauncher/ readable by your user only, not Keychain items — a scheduled run with nobody at the Mac would stop on a Keychain prompt. This check is deliberately separate from the anonymous launch count, so that count's "cannot tell one install from another" stays true.

What it writes outside the app's own folders

A backup is a folder of ordinary CSV files, one per object, and a short manifest saying what was asked for and what came back. The files themselves are kept once, in a Files folder beside the backups, named with their Salesforce Id and their real name, because the same file belongs to every backup that lists it. Nothing needs Org Launcher to read it. Those folders hold real records from your org, including every file attached to them, and they can be large. When a backup finishes, the app removes old backup folders under the rule you choose. By default it keeps the last three full backups; you can choose the last six, or everything. The backup just taken is never removed, nor is anything a later set of changes is rebuilt from, and a downloaded file is removed only when no remaining backup lists it. You may point a backup at any folder, including one in Documents, on the Desktop, in iCloud Drive or on an external drive, and the app warns when you pick one of those because macOS can ask permission for it and a backup running with nobody at the Mac cannot answer. /bin/launchctl is macOS's own tool. The only other program this feature runs is the Salesforce CLI, which hands over the login's access token the way it does for everything else in Org Launcher. Removing the app removes neither the backups nor the schedule file: turn scheduling off first, or delete that file by hand.

The app itself

Both can be switched off in Settings. What the launch counter does and does not send is set out in the privacy policy.

Every host contacted

Opened in your browser rather than requested by the app: your org's login link, the Salesforce Trust page, these pages, and the Salesforce CLI setup guide. login.salesforce.com and test.salesforce.com are reached by the Salesforce CLI and your browser when you add or reconnect an org — the app itself does not call them.

What is never sent to us

• The login token, held in memory only.
• All duplicate matching, over a local copy of the records.
• The records downloaded for a duplicate check, kept in one file per check under ~/Library/Application Support/Org Launcher/Dedupe/ — a different folder, with a space in the name. These hold real record data, can run to hundreds of megabytes, and stay until you delete them.
• Reading and writing spreadsheets, and every CSV and Excel export.
• Comparing metadata between two orgs.
• Your saved org list, limits readings, query history and saved queries.
• Backup files written before an import changes anything.
• Everything Data Backup copies down — the records, the files, and the list of which record each file belongs to — as CSV files and real files under ~/Library/Application Support/Org Launcher/Backups/ or a folder you choose. None of it is ever sent anywhere, except back into your own org when you restore. The subscription check sends a key, a one-way code for the computer and the app's version, and nothing else.
• Your subscription key and the signed permit that goes with it, as files under ~/Library/Application Support/OrgLauncher/ readable by your user only.

Accurate for version 1.1.17. If you find something on this page that does not match what the app does, please tell us.

Questions?

Email ejbantz@dewwow.com and include the version number from Org Launcher > About Org Launcher.

Overview  ·  Find duplicates  ·  Data Backup  ·  Release notes  ·  Privacy  ·  What it calls

DewWow LLC · Wisconsin’s Odoo Partner · dewwow.com

Salesforce and related marks are trademarks of Salesforce, Inc. Org Launcher is an independent product and is not affiliated with, endorsed by, or sponsored by Salesforce, Inc.