About
Built by an SF admin.
For SF admins.
HCMToolkit started as a browser script that found one broken picklist label three days before a go-live. It grew into eleven tools because the same problems kept appearing on every project.
The problem
SF administration has a tooling gap.
These are the problems HCMToolkit was built to close.
Manual picklist audits
Finding one option ID means exporting every list and running a VLOOKUP. A question that should take seconds takes an afternoon.
IT tickets for basic queries
You need Postman access, a whitelisted IP, and two approvals just to look at an OData endpoint you already have credentials for.
Unreadable RBP exports
The JSON is technically complete. In practice it needs an hour of reformatting before you can answer a single compliance question.
No built-in diff
Comparing picklists between releases means exporting both states, opening two Excel sheets, and squinting until something stands out.
Locale gaps you find in production
No coverage view exists. You find out a translation is missing when a user in Munich files a ticket after go-live.
Orphaned cascade references
Inactive parent values that still have active children. Silent until they break a dropdown — and then genuinely hard to trace.
Origin
A deadline forced the first version.
Three days before a go-live, a client’s dropdown was broken in German but working in English. The cause: a duplicated locale label somewhere across 800-plus picklists. The path to find it — export everything, VLOOKUP, repeat — would take hours no one had.
A quick browser script queried the OData endpoint directly and surfaced the problem in eleven seconds. The fix took two minutes.
That script became the Picklist Value Search. The next project brought a different problem, which became the Version Diff. Then an RBP audit, then a cascade hierarchy nobody had documented. Each tool came from a real deadline, not a product roadmap.
HCMToolkit is public because every SF admin hits these same walls. There’s no reason to keep rebuilding the same scripts.
Architecture
Your token is never
stored by HCMToolkit.
Your bearer token is held in your browser’s session storage — scoped to your tab and cleared the moment you close it.
Because SuccessFactors enforces CORS restrictions on direct browser requests, API calls are relayed through a stateless proxy (/api/sf-proxy). The proxy receives your token, forwards the request to your SF instance, returns the response, and writes nothing. No database, no logs, no session state. Open DevTools → Network and you’ll see every call go out to your tenant URL after passing through the relay.
No user accounts. No data retention. No analytics scripts. Nothing here is collecting information about you or your tenant.
Philosophy
Four things this project
will not compromise on.
Get started
Enough context.
Time to use the tools.
No account. No install. Paste your credentials and you’ll have your first result in under sixty seconds.
Start with Value SearchOr browse all eleven tools on the homepage.